Mentioned on DWN

Heh, I have been mentioned on Debian Weekly News for my very first time :-) . Still, I must make a correction and admit I didn't do a full install due to #407702.

In spite of that, installs over PPPoE have been confirmed and are working properly (with ppp-udeb 2.4.4rel-5) by appending modules=ppp-udeb to the D-I boot command.

Installation guide text proposal is tracked by bug #408340.

pppoe testers needed (ppp-udeb) - take 2

I am renewing my call for testing installations over PPPoE, after fixing an issue reported on both my blog's comments section and also on debian-boot. Thanks for those tests.

So please, make the same tests I asked previously, but with the new image:

http://users.alioth.debian.org/~eddyp-guest/ppp-2.4.4rel-5/mini-with-ppp-udeb-20070124-1.iso


(This image is also signed and the md5sums file is updated and signed, too.)

pppoe testers needed (ppp-udeb)

(Stop the tests for now, it seems I made a mistake. Will fix it tonight and make an update.)

I have been working recently on an update to the ppp-udeb package (responsible for configuring PPPoE networking in D-I and the target system).

I think I have finished fixing the last bad bits from the ppp-udeb package[*], but currently I am unable to do a test of a complete installation due to bug #407702 in qemu. Still, I am confident it should just work.

So I am asking if there are people interested in testing the image I have prepared with the new ppp-udeb package. The image can be downloaded from:



http://users.alioth.debian.org/~eddyp-guest/ppp-2.4.4rel-5/mini-with-ppp-udeb-20070124.iso



(Security concerned people can check the signature and md5sums and go on, if they trust me :-) )

How to test

In order to test, just boot the image (no boot parameters are needed) and try to do a basic installation via PPPoE.

What should be (or would be nice to be :-) ) checked:

• in D-I environment
• bad/good login should be detected (good logins are silent)
• transitory problems when trying to do the initial connection (cable unplugged or PPPoE server down) should be detected
• in the installed system:
• target system boots fine with the PPPoE connection set up correctly
• hosts file and host name are set correctly
• permissions are set correctly on the network configuration files and the ppp configuration files (an output of "ls -lR /etc/ppp" in the target would be appreciated)
• loopback interface is configured correctly

Please respond as soon as possible (eddy.petrisor at_sign gmail.com).

[*] I did some tests myself but I can't test everything due to bug #407702 in qemu; some screen shots I made in qemu can be found at http://users.alioth.debian.org/~eddyp-guest/ppp-2.4.4rel-5/screen%20shots/


Update: thanks to some people that did the test, I found out that I made some wrong assumptions in my code. I will make another image tonight and make another call. This will hopefully fix the issue.

Is bad ...

...when you promote bad attitudes. Is worse if you make it visible. Even worse if you are proud of your bad attitude.

... and it works from D-I like a charm!

Yes, I started D-I with "install modules=ppp-udeb" and it detected the concentrator, I gave the user name and the password and it connected! Yippee!

For non-belivers or voyeurists:
http://users.alioth.debian.org/~eddyp-guest/pppoe_tests_with_qemu.png

HOWTO test PPPoE without having PPPoE (long)

I don't have an ISP which uses PPPoE or more than a laptop on my desk, but still, thanks to free software, I can test PPPoE installations (to some degree).

I have set up with qemu machines a virtual LAN that is made totally in user space via a TCP socket on port 1234. I needed this in order to test the changes I am working on for the ppp-udeb Debian installer module that supports (or should I say, should support) configuration of PPPoE connections.

These are the tools whose authors and maintainers deserve kudos:

• Debian Installer
• qemu (upstream page here)- for allowing me to create a server, a client machine and a Debian installer machine to test things
• qemu-launcher - for being such a good interface for qemu and allowing quick selection of virtual machines
• pppoe - because it contains the pppoe-server command
• the upstream/source package rp-pppoe because it contains the /etc/ppp/pppoe-server-options
• the pppd package because of the pppd, pon and plog commands
• last, but not least, zim, for allowing me to put some order into my thoughts
  

This is the tutorial I followed to configure the PPPoE server http://www.freeantennas.com/PPPoE-Server-HOWTO.html, but until then I had to make the network.

In case someone is interested, here's how I did it (these are Debian centric instructions, but I don't see anything that would stop someone to do the same even on a windows machine).

• create a i386 virtual machine in qemu-launcher; name it "Debian Test ppp-udeb server i386" or something like that - don't forget to save; is useful to add some comments about it; the configuration of the machine:
  
• small hard-drive - 1-2GB (use the qemu format, it will grow as needed) - this drive is about 903 MB while the client's (see below) is about 760MB
  
• user mode networking
• make it boot from CD (you will need at least a Debian Installer buisinesscard iso image and choose the D-I image to boot from) - I took an old daily I had since I already had it on my disk - if you have a real CD you can use that too.
  
• check the option to provide a control panel for the image, is really useful (don't forget to install qemuctl and set the path to in in qemu-launcher - not set by default, but I made small and trivial patch)
• install a basic Debian Etch system on the machine; optionally you could install ssh (both the server and the client) as they might prove useful later
  
• after installation, stop the machine properly and make a copy the hard disk image file - this will the the hard disk of a client machine and will help to make sure the server is working properly - I only needed this temporary, so I could erase that image now that I am sure the pppoe server machine works and is configured properly
• create another machine in qemu-launcher starting from the server machine configuration - will modify later the network interface type now to be TCP socket already opened - this would allow communicating with the server machine without root privileges; now change the hard disk image to point to the copy just made and start this machine; install pppoeconf on it and stop it when done
• start the server again and install pppoe package and get its source, too - will need some files from there which are not in the binary; stop it when done
  
• reconfigure both the server machine and the client machine to use TCP socket - "Open a listening TCP socket" and "Use an already open TCP socket", respectively
• start both machines (always start the client after the server) and configure each of the machine with a static IP (I used 10.0.2.10 and 10.0.2.20) and check the machines see each other - ping or ssh; if it doesn't work make sure to restart them so that the client is started after the server
• now you have two machines that are in a network and you can start to follow the PPPoE-Server-HOWTO

I won't repeat that tutorial, but now I can create a virtual machine (well, I'll use an existing virtual machine) and test my custom D-I images and test the changes done in ppp-udeb.

Rock on!

RC bugs, what about important ones?

I was wondering if is right to our users that we are following only the RC bugs before a release. I think not. Don't get me wrong, I don't want important bugs count to be 0, or something similar; that would be insane to have as a goal.

I am thinking that we should (during the freeze) poke more of those important bugs that our and/or others' packages have. If you are like me, you will feel that you can't do anything/too much to improve the quality of the release during the freeze since some of the RC bugs are corner cases, not reproducible on your arch, already taken or you don't have the knowledge to fix them.

Many of the important bugs are broken functionalities that affect the users on a daily basis, and living 2 years with the same set of bugs is a pain. I don't know how that would feel, but I can imagine. I used Woody for only a half an year and after 2 months I started using backports. After 3, I started pulling things from Sarge (at the time it was testing). At the end of that half of year I was using mostly Sarge stuff and decided to go entirely into testing.


So, what do I propose? Maybe we should make some pages in the style of the RC bugs count pages which follow the important bugs.

As a bonus we might see some interesting things like bugs which were downgraded from RC - the RC graph would go down, while the important graph would rise. Of course, that wouldn't mean too much since that would be the product of badly assigned severities or downgraded and judged as non-RC bugs, but it would interesting to follow such tendencies.

disable the pcspkr - hacks

I blogged 5 days ago about the annoying beeper and different methods that were supposed to turn it off.

I asked for a clean solution, but I received suggestions for some hacks. Now I decided to make a new post since there was a comment added today and I remembered about a possible hack (dpkg-divert) I was thinking about.

Now here are some of those hacks and the reason behind rejecting them.

• I thought at some point of using dpkg-divert, as opposed to deleting the module, but this is suboptimal. And I am not sure dpkg-divert would work for such a whacked "use case"
  
• Using a hardware method is also suboptimal, for several reasons:
• I will hear the beep if I don't plug in the dummy jack
• the same goes when I am using a headset - the volume is loud and seems to not be affected by the general sound volume, so it would be disruptive and annoying while listening music and typing the wrong command;
• the Intel HDA sound driver lacks headset jack detection in the current Debian kernel. This means there is no effect if I plug such a jack
  
• The default beeping should be disabled by default, still, that would partly solve my problem. I could set that in my .inputrc file or system wide, still, that would mean a beep on some occasions (like gdm log in) - not sure if this would mean it would be more scarier, since it happens rarely or not :-)

Still, the question remains, why don't the originally proposed methods work, especially blacklisting?

Update: the headphones jack works with some small changes, bug submitted (#407252)

sleep schedule

Currrently I am having trouble with my sleep schedule. Is really messed up; recently I ended up going to sleep at 3, 4 or even 5 in the morning and waking up around 11. That is not good.

This affects everything: job, RL, my energy level during the day, Debian releated work, social life etc.

So I asked my GF to call me when she wakes up, so I can repair my sleep schedule. Today the phone rang at 8:00am sharp. 45 minutes later I was up. Not too bad for the first attempt.

qemu and non-i386 arches

Junichi, the Debian vesion of qemu doesn't work for ppc.

TDebs - some hours later

... and some brainstorming to think/rethink/remember ideas discussed in Extremadura, and now there is another proposal for tdeb implemenation on the wiki.

Comments, ideas are welcome.

Now I am off to bed.

TDebs - why we need them

First to answer why we need TDebs:

localepurge: Disk space freed in /usr/share/locale: 256828K
localepurge: Disk space freed in /usr/share/man: 4496K

Total disk space freed by localepurge: 261324K

Second, I will write my tdebs implementation proposal after posting this (although Aigars made a really good sythesis of the discutions we had in Extremadura and there is almost no room for improvement :-). I have posponed long enough.

how to disable the pcspkr in Etch?

The new laptop I just bought had the bad habit of using the pc speaker at a loud level. It was deranging the coleagues at work when autocompletion yelded more than one result or none (it also scared me a few times during the last nights when I was configuring and testing the laptop).

So I unloaded the module (pcspkr) by hand and wanted to make the system not load it anymore.

So I thought that blacklisting it would do the trick. Probably some people know already that adding al line like:

blacklist pcspkr

in /etc/modprobe.d/blacklist doesn't work. The rest of you find out now. I found out at the next reboot, when I heard again the beep.

Ok, I googled a bit and found some info about restricting ipv6 modules being loaded so I though I could do the same for pcspkr. So I tried:

to change the line from /etc/modprobe.d/pnp-hotplug:

alias pnp:dPNP0800 pcspkr

into

alias pnp:dPNP0800 off

That didn't work either.

So, at this point I googled more and found some outdated information about update-modules.

That brought me to modprobe.conf(5) which pointed to the "right" solution.Write the following in some file in /etc/modprobe.d/ (I added it in blacklist, since it seemed the right place)

install pcspkr true

Which seems to do what I want.



Still something tells me that either:

1) there is a cleaner solution I am not thinking about

or

2) I could have told udev not to load the module... And I feel this solution should have to do something with these lines and "ACTION":

eddy@bounty /etc/udev $ grep -r pcspkr *
persistent-input.rules:DRIVERS=="pcspkr", ENV{ID_CLASS}="spkr"
rules.d/z20_persistent-input.rules:DRIVERS=="pcspkr", ENV{ID_CLASS}="spkr"



A clean solution would be appreciated.

bts-utils, nice, but...

Enrico, nice idea, but, please, may I have the luxury of configuring the cache in ~/var/cache/bts-utils or even ~/.bts-utils/cache?

I don't want cache directories all over the place.

New laptop #4 (I have decided the model)

The race had 3 finalists:
- HP nx6235 (in Romanian) - incredible low price, fully works (with some patches and except the fingerprint reader) (thanks Marc)
- Dell Inspiron 6400 (aka E1505)
- ASUS F3T-AP008

I have decided against the 64bits AMDs and in favour of long life batteries and Centrino Core 2 Duo architecture.

HP nx6235 failed to meet my criteria of design, reliability (I have heard that local HP service has problems with HP products; waranty is 1 year). The shared video memory was a concern regarding overall system performance.

Dell, well... Dell 32 bit arch... I would have been nice to jump into the 64bit wagon, but I guess that will have to wait for now. Design is nice, the hard disk is bigger by 20GB (we all know disk storage is never enough ;-), Centrino tehnology (Intel seems to be OS friendly and drivers seem to exist for all the components), battery time (I can wait to test the real battery time), has some video memory of its own (HyperMemory - some kind of video cache)

ASUS - the selling points over the Dell were the AMD Turion 64 x2 processor(s), the design (looks nicer than Dell, IMHO), the nVidia video card (which was also a concern due to the proprietary driver and its security holes - sorry, no link), and the not yet working built-in webcam. There was also an bonus: a bag and a mouse, but that almost never works for me. And I had to wait for at least a week for it.

The winner is the Dell Inspirion, they also have it on stock, I already placed the order and I will pick it up after I finnish this entry ;-) .

I can't wait to fire up Debian Installer on this baby.

Update: when I said I'll skip he 64 bit wagon I was thinking (for some reason) that the amd64 bit port does not perform well on the Intel Core 2 Duo processors and I would be forced to use the i386 arch. Thanks for correcting me.
Update: it seems eMag was using false information in their advertising regarding Dell, the system is NOT using Centrino technology since it has a Broadcom wireless lan.

New laptop #2

A new laptop means more things than just new hardware.

1. I will no longer have a PowerPC machine; it has been fine, I have been spoiled by Apple hardware and design, but I also had my share of bitterness (like it or not flash is ubiquitous, wlan works on i386 hardware via ndiswrapper, wine is good enough when no free alternatives are around)
2. my father will use my current laptop in OS X; as sad as it may sound I am glad I will not have to administer the machine that much, and, like it or not, the OS X is better suited for him since he is not "that" skilled with computers
3. I can't work on powerpc/bigendian specific issues, thus, the long pending and incomplete glest big-endian support patch will have to find a new person to take care of and finish it. BTW, the glest project needs developers, the current ones are busy and can hardly do maintainance. Is a pitty, the game has incredible graphics.
4. I will be able to test the Debian Games Team's games... and I will be able to play again cursively Oolite. (BTW, Oolite should autobuild now, but it seems it hasn't been autobuilt, just the upload architecture is on version 1.65-4)
   

New laptop #1

I am in search of a new laptop and this is difficult.

What I (know I) want:

• 1 GB of RAM (I am tired of not enough resources issues)
• battery life, the longer the better (I expect at least 3.5h - real, not advertised - in coding, reading style)
• at least 100GB storage
• functional sleep and/or hibernation (I was spoiled by my current PowerBook G4)
• a video card that is supported in Debian (I'd choose Intel, Nvidia, Ati, in this order) since I want to be able to play the games we package
• working wlan (open drivers are a plus), bluetooth, and LAN
• a dual core processor (Intel or AMD)
  

What I don't know for sure aka "help lazyweb":

• the video memory should be dedicated (does this affect performance that much these days? even on Intel Centrino sytems?)
• AMD Turion 64x2 (TL-35), that means amd64 arch (are they worth the money saved in comparison with the Intel Core Duo? 3.5h battery time on AMD compared to 5h on Intel would mean, no)

Dear lazyweb question:

• Does a 32bit wlan ndiswrapped works on amd64 system running in 64 bits mode?
• What real battery times do people have on their Turion 64x2 and Intel Core Duo respectively?
• What brands should I avoid?
  

New laptop #3 (hardware compatibility - mandatory rant)

I am deeply missing a real wiki.debian.org/Hardware page. The current one is a joke. It would be nice to have something in the style of the Gentoo hardware page with nice pages which show what works and what doesn't.

I know about the Debian GNU/Linux device driver check page which is a good start, but:

• in most places (installation reports in and out of Debian) you will not see lspci -n output
• there is more to it than lspci (think lsusb, think stuff behind new/strange/uncommon buses - like the sound chips on some Apple ppc based machines)
• you need a running linux system (a live CD can be used for the test), but:
• Debian's live CD is in its infancy (I know, Knoppix should do fine)
• most live CD-s are i386 only (it doesn't matter that much, since amd64 machine should work with i386 live CDs)
  
• most places where you can buy hardware from:
• either they don't have the hardware in stock,
• either want an answer immediately,
• or they don't allow you to access the machine
• (I think) the database is outdated and people are not adding stuff to it
  
• there is no way to make a search based on the product name of the whole system and/or the component

Current situation (bad stuff)

wiki.debian.org/Hardware is a joke. For example, I was expecting to see a Network compatibility list, but instead I see some useless info.

What annoys me the most in this matter are dead links or links to dead/inactive projects.

Information is scattered all over the place (redirects and directories can help), is mixed/ungroupped, or is outdated.

Current situation (good stuff)

The information partly exists. Probably, in time, the wiki will be cleaned up, but until then you have to dig for the information.

There are plenty of sites and pages with information, but, still, you need to weed out the old/irrelevant stuff.

What to do about it

Before you say anything, no, there is no need for yet another Linux compatibility list project.

Ideas:

• contribute to the wiki
• add a wiki page for every machine you installed under Hardware/Compatibility/{Laptop,Desktop,Misc}/$PRODUCTNAME (would it make sense to have it under Hardware/Compatibility/{Laptop,Desktop,Misc}/$PRODUCTNAME/$DIST ?); link your page to the installation-report (you did fill an installation report for every installation you did, didn't you?)
  
• reorganize pages with directories (as proposed above)
  
• remove dead llinks
• add redirects for pages that just say "See foo"
  
• unify pages that contain almost the same information
  
• automatically make a wiki page for each (successful and unsuccessful) Debian installation-report based on the machine type (would need some logic to weed out the home made systems) - but only select the success/fail rate based on strictly hardware issues
• help Kenshi with his efforts for better hardware support

Update: Justin told me about the Ubuntu Laptop Testing Team project which is kind of nice. There is also a scraper script which was supposed to help making queries like "info about laptop X" and "which laptops have these features", but that script didn't work for me.

What's eating my time

Since always I almost never have been able to organize properly my time. On top of that I tend to be
excited about various new things and keep on adding to my "sometime in the future" todo list. When I
decide is time to use the GTD technique, things start to improve. Sadly, I am not able to stick with
GTD 24/7.

first post!

Hello!

I decided is time to start blogging... so here is a first post.

Future topics: Debian, Romanian l10n, i18n and real life.