[12:08] <amu> mdz: working with the liveCD causes brain decrease, i have probably forgotten to say it :)
[12:31] <seb128> mdz: new ncb available, should fix the device busy issue .. if you can confirm it :)
[12:32] <sjoerd> seb128: did you also change the g_file_test from _EXIST to _EXECUTABLE (or something like that)
[12:32] <seb128> sjoerd: no, why ?
[12:33] <sjoerd> seb128: so it uses umount instead of pumount when the user isn't in group plugdev
[12:33] <seb128> why ?
[12:33] <seb128> is returns the first known entry
[12:34] <seb128> which is pumount
[12:34] <seb128> so it uses pumount
[12:34] <sjoerd> seb128: yeah, but the user might not be able to run that
[12:34] <seb128> and ?
[12:34] <sjoerd> seb128: while if you check if it's executable it returns the first entry the user can actually run
[12:35] <seb128> if an user not in plugdev runs pumount, what happens ?
[12:35] <sjoerd> he can't run pumount, drive isn't unmounted, same problem stays
[12:35] <seb128> sjoerd: you could have mentionned it before dude, I've just commited to the SVN, runned a pbuilder, build & uploaded 2 packages
[12:35] <sjoerd> if it would fallback on umount and there is an fstab entry (which is normal in debian) stuff still works
[12:36] <sjoerd> seb128: sorry, i just remembered it 5 minutes ago
[12:36] <seb128> I thought than pumount was falling back to umount
[12:36] <sjoerd> yeah, but if pumount isn't executable for the user then that doesn't help
[12:38] <mdz> seb128: pumount does fall back to umount
[12:38] <sjoerd> mdz: it uses umount when there is an fstab entry afaik 
[12:39] <mdz> hmm, perhaps
[12:40] <seb128> sjoerd: ok, feel free to update the Debian side so :p
[12:41] <seb128> I've commited the changes on the SVN, you just have to update the patch,commit, build and upload :)
[12:41] <sjoerd> seb128: i don't have commit rights in pkg-gnome remember :)
[12:42] <seb128> sjoerd: wait a min
[12:42] <seb128> that's easy to fix
[12:42] <seb128> :p
[12:42] <seb128> bah, I'll do that tomorrow, I'm too tired now to restart the pbuilder, etc
[12:43] <sjoerd> haha
[12:43] <seb128> next time try to think *before* :p
[12:44] <sjoerd> seb128: at least i thought about it before somebody filed a bug :)
[12:44] <seb128> ah ah
[12:45] <seb128> I'm not even the Debian maintainer for ncb, I should kick ross :p
[12:45] <sjoerd> oh it's not a team package ?
[12:45] <seb128> yes, it is
[12:46] <seb128> but team is an uploader, not the maintainer :)
[12:46] <sjoerd> ah
[12:46] <seb128> sjoerd: so we have the same bug in gnome-vfs ?
[12:47] <seb128> libgnomevfs/gnome-vfs-volume-ops.c:             if (g_file_test (known_locations [i] , G_FILE_TEST_EXISTS))
[12:47] <sjoerd> seb128: the patch i put in the debian bts checked it for being executable
[12:47] <seb128> sjoerd: which one ?
[12:47] <sjoerd> the one that also adds pumount to the list
[12:48] <sjoerd> -               if (g_file_test (known_locations [i] , G_FILE_TEST_EXISTS))
[12:48] <sjoerd> +               if (g_file_test (known_locations [i] , G_FILE_TEST_IS_EXECUTABLE)
[12:48] <seb128> right
[12:48] <seb128> all right, I'll fix it now so that's done
[12:49] <seb128> have you send this upstream ?
[12:49] <sjoerd> nope
[12:49] <seb128> bad guy
[12:49] <sjoerd> i'm leaving that to the debian maintainer to decide ?
[12:50] <sjoerd> it's not really usefull upstream though, unless they also add pumount
[12:50] <seb128> right
[12:50] <seb128> I'll push all that upstream
[12:50] <seb128> and I'm not the gnome-vfs maintainer neither :p
[12:51] <seb128> s/neither/either/
[12:51] <sjoerd> hehe
[12:51] <sjoerd> seb128: the pumount bit too ?
[12:51] <seb128> yep
[12:51] <seb128> doesn't hurt
[12:51] <sjoerd> right
[12:52] <sjoerd> but it's quite debian/ubuntu specific currently so
[12:52] <seb128> BrowserDescription possible_browsers[]  = {
[12:52] <seb128>         { N_("Debian Sensible Browser"),        "sensible-browser",     "sensible-browser %s", FALSE, FALSE },
[12:52] <seb128> 
[12:52] <seb128> that's in the control-center upstream code too :p
[12:52] <sjoerd> hehe
[12:52] <sjoerd> go seb :)
[12:53] <sjoerd> most of the time i just put a bug in the bts and leave it up to the maintainer to sent it upstream if he thinks it's okay
[12:54] <sjoerd> (and i really don't like putting patches in bugzilla)
[12:55] <seb128> bah :p
[01:12] <Nafallo> hi there everyone! I have a suggestion for a keybinding change, but I don't know what package to touch.
[01:14] <Nafallo> volume up and down does atm change master volume, for laptops (and maybe stationed puters too) it would be great to let it control headphone volume aswell.
[01:31] <lamont> moof
[01:32] <jamesh> Nafallo: if you have your mixer settings set up correctly, you should only need to adjust the master volume.
[01:33] <jamesh> Nafallo: ie. you adjust the input volumes so that each input is read at approximately the same level, and do similar for the output volumes
[01:33] <jamesh> Nafallo: then you just need to adjust the master volume, and mute/unmute individual channels.
[01:34] <Nafallo> jamesh: in what way will that make master master even when headphones is plugged in?
[01:35] <jamesh> Nafallo: everything gets mixed by the master volume.
[01:35] <jamesh> that's why it is called the master volume.
[01:36] <Nafallo> jamesh: I just muted master. music still playing in my headphones
[01:36] <Nafallo> jamesh: i.e. if headphones is plugged in; s/master/headphones/g
[01:37] <jamesh> Nafallo: that sounds quite surprising
[01:37] <Nafallo> jamesh: it was ;-)
[01:37] <jamesh> Nafallo: the idea is that all sound is adjusted by the "master" volume settings, then adjusted by the volume settings for the particular output channel.
[01:38] <Nafallo> jamesh: I know. but when headphones is plugged master becomes irrelevant. could this be an alsa-driver bug?
[01:38] <jamesh> Nafallo: quite possibly.
[01:39] <Nafallo> snd_via82xx, I should try to google :-P
[01:46] <Nafallo> I sign a bug @ the alsa-driver project.
[01:47] <Nafallo> s/driver\ //
[02:07] <lamont> mania
[02:07] <lamont> sigh
[02:10] <zul> hey
[02:25] <lamont> keybuk: diff missing for howl... (4548).  Thoughts?
[02:26] <lamont> doh. nm
[02:35] <zul> lamont: is mono-mcs still failing?
[02:44] <zul> lamont: nm...did some digging around
[02:46] <lamont> zul: there's a buildlog for the failure
[02:50] <lamont> zul: so once they upload the fixed mcs package, all should be bootstrappable?
[02:51] <lamont> firecall
[03:14] <jdub> mdz: OOo2 pre-release doesn't get a great review in lwn
[03:27] <mdz> jdub: if it doesn't come together, it doesn't, but if it does, ROCK
[03:38] <mdz> whoa, 2.6.10 has online ext3 resize
[03:38] <mdz> didn't know that
[03:38] <mdz> rad
[03:39] <mdz> one less reason to use ricerfs
[03:41] <mdz> smurfix: someone has been testing on Ubuntu and uploading to Debian, hmm? :-)
[03:41] <mdz> (#288873)
[03:55] <sivang> mdz: couldn't you use lvm and resieze an XFS or reiser part?
[04:03] <mdz> sivang: <mdz> one less reason to use ricerfs
[04:06] <sivang> mdz: I saw that,  I was wondering if the same effect couldn't be achived via using reiserfs under lvm, as if the new rad feature was not so rad. :-) or is reicerfs != reiserfs ?
[04:06] <aj> hrm, is elmo around atm?
[04:07] <lamont> aj: he's been very silent for the last hour or 2
[04:07] <lamont> which is to say, I don't think so.
[04:08] <aj> well, it's 3am or something in the UK, so that's fair enough
[04:08] <lamont> yeah
[04:08] <aj> but he's not on vacation or irc free or anything?
[04:08] <lamont> should be around if he's awake.
[04:08] <lamont> hasn't said he's on vacation
[04:10] <mdz> sivang: ricerfs = reiserfs
[04:10] <mdz> sivang: reiserfs is online resizable; ext3 wasn't (until now) without kernel patches
[04:10] <mdz> lamont: you heard from him 2 hours ago? I haven't seen him all (my) day
[04:11] <sivang> mdz: wooa, so if I partition my hd only using reiserfs I do really need an lvm...cool.
[04:11] <sivang> mdz:*don't
[04:11] <lamont> mdz: I was gone for quite a while before that.
[04:12] <mdz> sivang: no, you've misunderstood
[04:12] <lamont> haven't heard from him since ~9AM your time
[04:12] <lamont> although ISTR he dropped something on me about 3AM my time
[04:12] <mdz> sivang: if you read a good FAQ about LVM or EVMS, it will be clear
[04:12] <sivang> mdz: ok, I will. tnx.
[04:13] <lamont> I take that back.  17:54 yesterday
[04:33] <lamont> anybody with locale!=*US* wanna test something for me?
[04:35] <lamont> sivang: ??
[04:36] <lamont> getting to be fall-in-bed time here.
[04:36] <lamont> busy day
[04:42] <lamont> mdz: 42 unassigned merge bugs
[04:42] <mdz> lamont: nice
[04:42] <lamont> I'll do a bunch more tomorrow
[04:42] <lamont> then I'll run out of excuses and have to review the patches.
[04:42] <lamont> :-)
[04:43] <lamont> I think that's actually the right priority order, given that the merges affect the review
[04:45] <lamont> I also plan to do a very targeted debian upload of postfix, which will contain only fixes for the ubuntu bugs, then another one that has additional fixes.  that way I can easily merge the first over to hoary
[04:45] <lamont> but that's wearing both my hats.
[04:45] <lamont> I'll even make sure that I run it through the process before I upload the hoary package with the new debian version number :-)
[04:45] <lamont> anyway, off to bed I fear.
[05:02] <mdz> where is my new rootskel...GRR
[05:02] <mdz> lamont: are you really gone?
[05:03] <mdz> the source is there, but no binaries and no build logs and it's been there for hours
[05:22] <sivang> lamont: yes? :)
[05:22] <lamont> well, I was.
[05:22] <lamont> sivang: have a hoary box to test something on?
[05:23] <sivang> lamont: sure am ! :)
[05:23] <lamont> http://people.ubuntu.com/~lamont/libpaper1_1.1.14ubuntu6_i386.deb
[05:23] <lamont> download that
[05:23] <sivang> lamont: downlaoding...
[05:23] <lamont> dpkg --purge --force-depends libpaper1; dpkg -i libpaper1_1.1.14ubuntu6_i386.deb
[05:24] <lamont> then tell me what's in /etc/papersize
[05:24] <sivang> ok, copying and pasting and execing.
[05:24] <sivang> lamont: in a sec.
[05:24] <lamont> mdz: 1.11ubuntu1?
[05:24] <lamont> or newer than tat?
[05:25] <sivang> lamont: ok, lemme see what's in /etc/papersize
[05:26] <sivang> lamont: "a4" that's all
[05:26] <sivang> lamont: is that ok?
[05:26] <lamont> woot!
[05:26] <sivang> lamont: ;-) Glad to be of service 
[05:26] <mdz> lamont: ubuntu2
[05:26] <sivang> lamont: does that mean that I can now print on a4 paper? couldn't I before?
[05:27] <mdz> lamont: http://archive.ubuntu.com/ubuntu/pool/main/r/rootskel/rootskel_1.11ubuntu2.dsc
[05:27] <mdz> (that one)
[05:27] <lamont> mdz: for whatever reason, it doesn't appear to have shown up in wanna-build
[05:27] <lamont> sivang: it will now default to a4.  Note that cupsys takes it's default from that file (at install time), etc, etc.
[05:28] <sivang> lamont: cool :) and with that optimistic end to my day (night) I'll say g'night.
[05:28] <lamont> thanks again
[05:28] <sivang> lamont: no, prob, always ask if you have anything to test :)
[05:28] <sivang> mdz: night
[05:29] <lamont> mdz: sanae is down
[05:29] <lamont> or appears to be down.
[05:30] <mdz> lamont: does that mean all builds are broken?
[05:30] <lamont> since about 0200 london time
[05:30] <lamont> sanae would be our critical piece of infrastructure for uploads getting signed...
[05:30] <lamont> and buildlog publishing
[05:31] <lamont> I could shove rootskel through, but probably better to get someone to kick sanae, and all will just flow.
[05:31] <lamont> bbiam
[05:35] <lamont> b
[05:38] <lamont> mdz: the builds are all happening, they're just not getting uploaded, and the log files are queueing up in the mail queue for delivery once sanae is back up
[05:39] <mdz> lamont: ok
[05:39] <mdz> I can use localudebs for now
[05:39] <lamont> and as a side effect, the buildLogs web tree isn't updating, since that's fed from the received mail as well...
[05:42] <lamont> kicking the machine needs to be high on someone's list for tomorrow morning london time
[05:42] <lamont> if there's something that _needs_ to go in, say before the daily CD build, I can push it, but I'd rather not - tired, etc.
[05:44] <lamont> anything more before I go fall into bed?
[06:17] <mdz> daniels: here?
[06:30] <mdz> let me rephrase
[06:30] <mdz> daniels: WHERE ARE YOU
[06:45] <bob2> mako: any news about the Missing Cds of Doom?
[06:47] <mako> bob2: not yet
[06:48] <fabbione> morning
[06:48] <fabbione> daniels: xorg is GO
[06:56] <lifeless> mdz: want me to ring him ?
[06:58] <fabbione> mdz: he has been around until a few hours ago (6/7)
[07:12] <mdz> fabbione: good morning
[07:12] <mdz> fabbione: I was about to make some changes to the kernel udebs
[07:12] <mdz> though now I am not sure if it is the right approach
[07:13] <mdz> basically, I need psmouse and mousedev for the live CD
[07:13] <mdz> either they need to go in a udeb, or we should package a full set of modules in the live fs
[07:16] <lifeless> mdz: so do you want me to ring him ?
[07:17] <mdz> lifeless: it's 1700 or something over there, yes?
[07:17] <mdz> no, earlier
[07:17] <lifeless> 1717
[07:17] <mdz> ok
[07:17] <mdz> yes
[07:18] <mdz> thanks
[07:19] <lifeless> his phone is off or out of range
[07:20] <fabbione> mdz: i can do that easily...
[07:20] <mdz> fabbione: well, at first I thought that obviously they should be added to a udeb
[07:20] <fabbione> mdz: what modules do you need exaclty in which udeb
[07:21] <mdz> but then I started to wonder, how many other modules are there which are not present in any udeb at all?
[07:21] <mdz> the live CD should have all modules available
[07:21] <fabbione> tons
[07:21] <fabbione> well the live CD should have a kernel installed
[07:21] <fabbione> all of it
[07:21] <fabbione> not just bits
[07:21] <mdz> yes, that is what I am thinking
[07:22] <mdz> I am going to hack around it for the moment, but long-term, the fs that lamont builds should have a kernel installed
[07:22] <mdz> the actual kernel image will be a waste because it will never be used
[07:22] <mdz> but at least all the modules will be there
[07:22] <mdz> I am going to hack in mousedev and psmouse just to get things going
[07:22] <mdz> and then the last thing remaining is X config
[07:22] <mdz> which is why I was hunting daniels
[07:23] <fabbione> mdz: he has the bug assigned
[07:23] <fabbione> mdz: the only thing he needs is someway to know if X is running on livecd or not
[07:23] <mdz> hmm?
[07:23] <fabbione> and somehow trigger a reconfig..
[07:23] <mdz> I just need to know what command to run to get a working X config
[07:24] <fabbione> mdz: there is none that does what you need at the moment
[07:24] <fabbione> probably..
[07:24] <fabbione> you can try with:
[07:25] <fabbione> export XORGFORCEPROBE=yes
[07:25] <mdz> haha, cron.daily just started running on the live CD
[07:25] <lifeless> rotfl
[07:25] <fabbione> dpkg-reconfigure -pnoninteractive xserver-xorg
[07:26] <fabbione> mdz: in anycase.. for simple tests.. since you are at the beginning.. just don't write any config file
[07:26] <mdz> fabbione: should I move xorg.conf out of the way if it exists?
[07:26] <mdz> or does it not matter?
[07:26] <fabbione> xorg should be able to autoconfigure itself in a good bunch of cases
[07:26] <mdz> hmm
[07:26] <mdz> so just delete the file?
[07:26] <mdz> (it already exists from xserver-xorg being installed)
[07:27] <mdz> what will it use for a mouse device by default?
[07:27] <fabbione> mdz: if you are using the dpkg-reconfigure approc just be sure that md5sum /etc/X11/xorg.conf will match /var/lib/xfree86/xorg.conf.md5sum or something like that
[07:27] <fabbione> if you want to use the second approch kill /etc/X11/xorg.conf
[07:27] <mdz> just tried with no config file; it doesn't work
[07:28] <fabbione> mdz: yeah it's not that perfect.. but a look at the logs would be nice
[07:28] <fabbione> it should try the ps2 mouse by default
[07:28] <fabbione> definetely it will never probe serial mices
[07:28] <mdz> sent
[07:29] <fabbione> mdz: well i meant.. you can look yourself ;)
[07:29] <fabbione> Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
[07:30] <mdz> I looked; I don't know why it isn't working
[07:30] <mdz> it seemed to recognize that it needed ati
[07:30] <fabbione> but i think it got almost all the config
[07:30] <mdz> but then it tried to use vesa instead
[07:30] <mdz> and then complained about framebuffer
[07:30] <fabbione> because it did load the fb extension
[07:30] <fabbione> not knowning the config it has to probe everything
[07:31] <fabbione> (II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
[07:31] <fabbione> (II) FBDEV(1): using default device
[07:31] <fabbione> (--) Assigning device section with no busID to primary device
[07:31] <fabbione> it's like it finds 2 video cards
[07:31] <fabbione> that's why is confused
[07:33] <mdz> hmm
[07:33] <mdz> dpkg-reconfigure -fnoninteractive didn't quite work
[07:33] <mdz> I think because it used values from the debconf db
[07:33] <mdz> which came from some other machine
[07:33] <mdz> I need for it to start empty
[07:35] <fabbione> hmm yes it does..
[07:35] <fabbione> use the debconf values...
[07:39] <fabbione> mdz: but i was thinking.. the kernel unpacked is not that big.
[07:39] <fabbione> at the end is only the bzImage that you don't use
[07:39] <mdz> it will waste about 1M
[07:40] <fabbione> and that's the minimal part compared to the modules
[07:40] <fabbione> yeah
[07:40] <mdz> I guess the modules which are in udebs are also waste
[07:40] <fabbione> in that case yes...
[07:40] <fabbione> or we can create a big fat all-in-one.modules.udeb
[07:40] <fabbione> and you don't install the kernel 
[07:41] <fabbione> but it would be probably more waste in this way
[07:41] <fabbione> since d-i still needs the modules in different little chunks
[07:44] <jdub> mdz: i think the d-i based livecd idea is really clever.
[07:44] <jdub> :-)
[07:44] <mdz> jdub: want to try it out?
[07:44] <jdub> sure! but depends on download size, really
[07:44] <mdz> it boots up nicely, and gdm thrashes about trying to start X
[07:45] <mdz> and then you can login on the console
[07:45] <mdz> it's full-sized
[07:45] <mdz> and will take me hours to upload
[07:45] <jdub> ahr
[07:45] <jdub> heh
[07:45] <mdz> but I intend to start an upload when I go to sleep tonight
[07:45] <jdub> what's your upstream?
[07:45] <jdub> what's the problem starting X?
[07:46] <mdz> 256k
[07:46] <jdub> ah, this is why you're hammer-pinging daniels?
[07:46] <mdz> yes
[07:46] <mdz> the problem starting X is that it needs a config
[07:46] <jdub> ugh, same as my upstream -> sucks :|
[07:47] <mdz> we should be able to move to building these at the data center quite soon
[07:48] <jdub> these won't be usefully rsyncable either, will they?
[07:49] <fabbione> hey pitti
[07:49] <pitti> Hi fabbione 
[07:49] <mdz> I don't imagine so
[07:49] <mdz> it's possible that someone could work the rsyncable magic on the cloop compression tool
[07:49] <fabbione> pitti: should we enable the strip translation on the buildd?
[07:49] <pitti> fabbione, mdz: since the last cap patch was wrong, I think we should go with the "compile in" approach
[07:49] <jdub> heh, that would be cool
[07:50] <mdz> it basically uses zlib
[07:50] <pitti> fabbione: on sparc?
[07:50] <mdz> and compresses fixed-size blocks
[07:50] <fabbione> pitti: i am preparing the new patch now..
[07:50] <fabbione> pitti: there was only one extra commit to bk
[07:50] <jdub> mdz: do we have a non-bounty cool hacks page?
[07:50] <pitti> fabbione: ah, okay. so it was correct in principle, but not complete?
[07:50] <fabbione> pitti: yes.. for sparc. did lamont already enable it for *?
[07:50] <pitti> fabbione: I don't think so
[07:51] <fabbione> pitti: the commit to dummy.c was wrong in bk. nothing to blame to us :-)
[07:51] <pitti> fabbione: otherwise we would lose all translations for newly uploaded packages
[07:51] <fabbione> pitti: ok.
[07:51] <pitti> fabbione: carlos promised me to mass-import hoary soon
[07:51] <pitti> fabbione: and I will work on the automatic deb generation in the meantime
[07:51] <fabbione> pitti: so i am going to cook up a patch today and send it out
[07:51] <pitti> fabbione: but I think all in all this will take another week
[07:51] <jdub> oh man
[07:52] <mdz> fabbione: hah, it turns out that the fs that amu gave me already had a kernel on it
[07:52] <jdub> we so need an /etc/alsatab or something
[07:52] <mdz> it is just half-installed
[07:52] <mdz> jdub: #1293?
[07:52] <mdz> jdub: what sort of cool hacks?
[07:52] <jdub> mdz: rsyncable cloop
[07:52] <jdub> stuff like that
[07:52] <fabbione> mdz: ah...
[07:53] <jdub> vfat sync
[07:53] <mdz> it failed to create the initrd
[07:53] <mdz> probably because it was done in a chroot
[07:53] <jdub> mdz: (yes re: bug)
[07:53] <fabbione> mdz: mostlikely
[07:53] <mdz> we need to make that work, for lamont's build process
[07:53] <mdz> it doesn't even need an initrd
[07:53] <fabbione> mdz: there is the need of /proc and a sane /dev
[07:53] <fabbione> mdz: that's all is required...
[07:53] <fabbione> to install the kernel properly i mean
[07:54] <fabbione> i remember fixing that several times in chroots
[07:55] <mdz> I am doing one more burn to test my busybox changes, and then I will upload the last change to the archive
[07:55] <mdz> except d-i, of course
[07:55] <fabbione> mdz: is there any kernel change you need or you have done?
[07:55] <mdz> I don't think any kernel change is necessary now
[07:55] <fabbione> ok
[07:55] <mdz> the #1 pending issue is X
[07:55] <fabbione> i don't plan to upload anything before 2/3 days anyway
[07:56] <mdz> fabbione: did you see my IRQ / sound bug?
[07:56] <fabbione> since yesterday was a fucked up day...
[07:56] <mdz> it seems like a 2.6.10 regression
[07:56] <fabbione> checking the bugs now...
[07:57] <mdz> I found one similar bug on bugzilla.kernel.org
[07:59] <fabbione> mdz: did it work with -2 as well?
[07:59] <fabbione> i remember you showed me the same message with 2.6.9 and 2.6.10
[07:59] <fabbione> or just 2.6.10
[07:59] <mdz> I am unsure about 2.6.9
[07:59] <mdz> but it definitely did not happen with 2.6.8.1
[07:59] <mdz> I only ran 2.6.9 for a very short time on this machine
[07:59] <fabbione> did you try to boot with the irqpoll stuff?
[07:59] <mdz> because you released 2.6.10 shortly after I started upgrading it again
[07:59] <mdz> I did not
[08:00] <fabbione> please do.. so i can report to alan
[08:00] <fabbione> the problem is not device driver dependent.. like audio or usb
[08:00] <fabbione> it is a general irq routing problem
[08:03] <mdz> right
[08:08] <fabbione> point is that there is no fix around yet
[08:09] <crimsun> those alsa issues are complicated
[08:09] <crimsun> most people seem to prefer onboard sound over usb headsets, for instance
[08:09] <crimsun> and most people prefer a sblive over onboard sound
[08:13] <zenrox> crimsun,  or a autolgy 2
[08:13] <zenrox> over sblive
[08:14] <crimsun> thomas's proposal of using hal sounds promising
[08:21] <mdz> I think readahead would speed up the live CD a hell of a lot, given sufficient ram
[08:21] <mdz> it spends all its time seeking
[08:23] <mdz> this is going to be so sweet when it works
[08:25] <mdz> daniels wasn't planning to work on the X stuff until next week, but this went more smoothly than I anticipated
[08:25] <mdz> and I am ready for those bits
[08:26] <pitti> elmo: please sync pmount from sid. TIA
[08:27] <fabbione> pitti: i am puzzled...
[08:27] <pitti> fabbione: what about?
[08:28] <fabbione> pitti: of that stuff that has been committed to bk
[08:28] <pitti> fabbione: it doesn't make sense?
[08:28] <fabbione> no
[08:28] <fabbione> but that's because bk is sick
[08:28] <fabbione> ChangeSet don't have a unique number for the same piece of patch
[08:29] <pitti> ugh
[08:29] <fabbione> and the changes between what i saw and what is in are different
[08:29] <pitti> security patch fuzzy-o-matic?
[08:29] <fabbione> pitti: ENOCLUE
[08:30] <fabbione> try for example to grab the .log files for bk7 and bk8
[08:30] <fabbione> and diff them
[08:30] <fabbione> you will see that a lot of changeset have been renumbered
[08:30] <fabbione> and there is no sign of changes in security/capability.c
[08:30] <fabbione> while there was in the patch i did send you yesterday!
[08:31] <pitti> hmm, that's odd. Was there something about this on lkml?
[08:31] <pitti> did they revert a patch or something like that?
[08:31] <fabbione> apparently...
[08:31] <fabbione> i am going to check with a manual diff
[08:41] <mdz> jdub: http://people.ubuntu.com/~mdz/ubuntu-live/hoary-live-i386-alpha1.iso
[08:41] <mdz> should be up in about 3 minutes
[08:44] <fabbione> pitti: well.. manual diff confirms that they didn't change capability.c, but only dummy.c
[08:44] <fabbione> pitti: i am preparing the final patch, but it will be a good idea to test it before uploading.. just to be sure i didn't fuck up anything
[08:45] <pitti> fabbione: can you prepare an unofficial kernel image deb for testing?
[08:46] <fabbione> pitti: yes that's what i am doing already
[08:46] <fabbione> i really need some help with the kernel
[08:46] <fabbione> it's just too much to do
[08:47] <mdz> jdub: yeah, I know I said it would take hours, but I am just so goddamn clever today and so I copied amu's image there and then rsynced mine up (they use the same compressed filesystem inside)
[08:50] <fabbione> I GET IT!
[08:50] <fabbione> i know why bk renumber the changesets!
[08:50] <fabbione> this is sooooo sick
[08:51] <pitti> fabbione: why? does it make sense eventually?
[08:51] <fabbione> pitti: example:
[08:51] <fabbione> head ----
[08:51] <fabbione> somebody creates branch a
[08:51] <fabbione> somebody creates branch b
[08:52] <fabbione> branch a start developing foo at rev 10
[08:52] <fabbione> branch b fixes bar at rev 9
[08:52] <plovs> does the ubuntu kernel have posic acl's?
[08:52] <fabbione> head is at let say 20
[08:52] <fabbione> i merge branch a and i get 21
[08:53] <fabbione> when i merge b
[08:53] <pitti> okay, I could follow so far
[08:53] <crimsun> plovs: grep POSIX_ACL=y /boot/config-`uname -r`
[08:53] <fabbione> than bk assumes that a is newer than b
[08:53] <fabbione> so basically it tries to sort by date
[08:53] <plovs> crimsun: even better then yes or no, thanks
[08:53] <crimsun> plovs: np
[08:53] <fabbione> and once the conflicts are resolved
[08:54] <fabbione> all the changeset are rediffed and recommitted again
[08:54] <fabbione> so changing numbers
[08:54] <fabbione> even if the original one is preserved
[08:54] <pitti> ah, I see
[08:54] <fabbione> this is sick.. trust me
[08:54] <pitti> so originally you looked at the fixed _branch_
[08:54] <pitti> and now you look at the fix committed to the mainline?
[08:54] <pitti> this would make sense
[08:55] <pitti> fabbione: this is exactly how arch's star-merge works, isn't it?
[08:56] <fabbione> pitti: i dunno...
[08:56] <fabbione> but it was all on the same branch
[08:56] <fabbione> that's why is scary
[08:57] <pitti> fabbione: oh, but your example involved three branches (head, a, b)
[08:57] <pitti> fabbione: I understand your example, it makes sense
[08:57] <fabbione> pitti: yes.. but the renumbering happens on head
[08:57] <pitti> fabbione: but I don't see how it works with just one branch
[08:57] <fabbione> that's what i was looking
[08:57] <fabbione> pitti: it doesn't on one branch
[08:58] <fabbione> they merged bits from different branches into head
[08:58] <fabbione> and the renumbering took place in head
[08:58] <fabbione> i did never tracked the branches
[08:58] <pitti> but that makes perfect sense
[08:58] <fabbione> pitti: uh?
[08:58] <pitti> but the very first patch was not from head, but from a branch?
[08:58] <fabbione> pitti: it was already merged in branch
[08:58] <fabbione> ehm
[08:58] <fabbione> in head
[08:58] <fabbione> and took a number
[08:59] <pitti> hmm, then I don't understand it either
[08:59] <fabbione> head----20
[08:59] <fabbione> i merge 10
[08:59] <fabbione> i get 21
[08:59] <fabbione> i merge 9
[08:59] <fabbione> what do i get?
[08:59] <pitti> I don't understand, you can merge head---10 into head---20?
[08:59] <pitti> shouldn't it already be in there?
[08:59] <fabbione> let me explain again
[08:59] <fabbione> head----20
[09:00] <fabbione> that's where i am now
[09:00] <fabbione> i merge branch--a--10 date: 2005-01-01
[09:00] <fabbione> head goes to 21
[09:00] <fabbione> ok?
[09:00] <pitti> ok
[09:00] <fabbione> i merge branch--b--9 date: 2004-12-31
[09:00] <fabbione> head goes to 22
[09:00] <fabbione> but
[09:01] <fabbione> you expect that head--21 is the merge of branch--a--10 date: 2005-01-01
[09:01] <fabbione> right?
[09:01] <pitti> right, so I would expect in arch
[09:01] <fabbione> in bk that doesn't happen
[09:01] <pitti> but bk renumbers it to keep chronologically?
[09:01] <fabbione> 21 becomes the merge of branch-b
[09:01] <fabbione> because of the commit date
[09:01] <pitti> D'oh
[09:02] <pitti> bk changes commit history then?
[09:02] <fabbione> and 22 becomes the merge of branch-a rediffed on top of 21
[09:02] <pitti> you are right, THAT's scary
[09:02] <fabbione> it doesn't really.. it just rename the changeset references
[09:02] <fabbione> and recalculate them 
[09:02] <fabbione> assigning different numbers
[09:02] <fabbione> that is scary
[09:02] <pitti> but that means I can't say to somebody "please merge 21 to fix it"
[09:02] <pitti> because 21 might not be 21 any more in a week?
[09:03] <pitti> buhuuuu
[09:03] <fabbione> pitti: no.. you can't.. you need to give it the new ChangeSet
[09:03] <fabbione> but i think bk is clever enough to reassign with logic
[09:03] <pitti> fabbione: hmm, in arch I can say, 'hey, please merge foo--main--21' and this will always stay the same cset
[09:03] <fabbione> i didn't dig too much or i will be sued for reverse engineering
[09:04] <pitti> *laugh*
[09:04] <fabbione> no shit...
[09:04] <fabbione> Larry is on me
[09:04] <fabbione> I am scared!
[09:04] <fabbione> ahaha
[09:12] <fabbione> ehhe
[09:27] <fabbione> ogra, mvo: ping
[09:28] <fabbione> mvo_: hey
[09:29] <fabbione> http://people.ubuntulinux.org/~fabbione/mIDSN.tar
[09:29] <fabbione> mvo_: there are 2 modules you want from there.. one is the fritz and i think mISDNcore
[09:29] <fabbione> since i wasn't sure about the second one i included all of them
[09:29] <fabbione> they have some more debugging stuff compiled in
[09:31] <mvo_> fabbione: thanks
[09:31] <mvo_> I will test them now in my isdn test machine
[09:32] <fabbione> they are for 686 kernels
[09:32] <fabbione> remember
[09:32] <enrico> Hello.  Could someone point me to where I can get the "About Ubuntu" page?  (described here: http://wiki.ubuntu.com/AboutUbuntuPage)
[09:32] <fabbione> and they will not fix anything.. just more debugging output
[09:32] <mvo_> fabbione: ok. luckily my test-machine is a 686 :)
[09:32] <fabbione> mvo_: good
[09:36] <pitti> Hey mvo
[09:38] <mvo_> hi pitti 
[09:38] <crimsun> I would love to test the -hardened 686-smp, but it uses XFS :/
[09:39] <pitti> crimsun: I try to sort that out
[09:39] <crimsun> pitti: many thanks
[09:39] <pitti> crimsun: it's a missing symbol somewhere at bootup, I've got no idea about that
[09:39] <pitti> crimsun: I have some higher-priority things to do, but I will try to look into this asap
[09:39] <fabbione> pitti: it's probably just missing a MODULE_EXPORT_SYMBOL or something like that
[09:40] <pitti> fabbione: hmm, but -hardened does not build any additional modules
[09:40] <pitti> fabbione: and otherwise I use the standard kernel config (I just disabled SELinux)
[09:41] <pitti> fabbione: the dmesg error is "xfs: Unknown symbol protection_map"
[09:41] <pitti> fabbione: however, I deal with that later
[09:42] <fabbione> pitti: it's not question of extra modules
[09:42] <fabbione> check the pax patch if it touches XFS
[09:42] <pitti> fabbione: it certainly does to implement the grsec hooks
[09:43] <fabbione> and what file has the protecion_map function.. in the latter add the EXPORTSYMBOL(protecion_map) thingy
[09:43] <fabbione> that should be enough
[09:43] <pitti> fabbione: thanks for that hint
[09:43] <pitti> fabbione: I just checked
[09:43] <pitti> fabbione: the patch only touches fs/xfs/linux-2.6/xfs_file.c
[09:44] <pitti> fabbione: and only inserts two lines of code
[09:44] <pitti> fabbione: it's pretty unintrusive
[09:44] <pitti> fabbione: but it uses this very function (protection_map)
[09:44] <fabbione> pitti: well if the symbol is not exported, the other code can't see it
[09:44] <pitti> fabbione: right
[09:46] <pitti> fabbione: odd, protection_map is used all over the place
[09:46] <fabbione> pitti: a missing include?
[09:47] <pitti> fabbione: I doubt; the symbol is already used in the unpatched xfs_file.c file
[09:47] <fabbione> weird...
[09:47] <pitti> fabbione: oh wait, this was the patched version
[09:47] <fabbione> hmmm is it used in other modules too?
[09:50] <pitti> fabbione: the unpatched version of xfs_file.c does not contain protection_map
[09:50] <pitti> fabbione: so it could be a missing include
[09:50] <pitti> however, I grepped the whole (patched) source for protection_map, this should have caught EXPORTSYMBOL(pm)
[09:50] <pitti> however, it didn't
[09:51] <pitti> fabbione: this is defined in mm/mmap.c
[09:51] <enrico> Hello.  Is there something running Hoary? :)  I need a copy of the HTML file that shows up when you click on "About Ubuntu".  Could someone either mail it to me or tell me in which package I can find it?
[09:52] <fabbione> pitti: hmmmmm
[09:52] <fabbione> pitti: check the patch if it adds includes here and there
[09:53] <fabbione> pitti: for something related to mmap
[09:53] <pitti> fabbione: I think it could help to include linux/mmap.h
[09:53] <pitti> sorry, linux/mm.h
[09:53] <fabbione> pitti: just check the patch...
[09:53] <pitti> this file defines protection_map
[09:53] <fabbione> yeah..
[09:53] <fabbione> enrico: gnome-panel?
[09:54] <fabbione> file:///usr/share/ubuntu-artwork/home/index.html
[09:54] <enrico> so, the ubuntu-artwork package.  I'm getting it, thanks!
[09:56] <fabbione> Kamion: you around?
[09:56] <fabbione> mdz: if you are still alive.. do you agree in start spreading the 2.6.10 love a bit more around (considering it will be the default kernel)?
[10:04] <cartman> lamont: about http://people.ubuntulinux.org/~lamont/buildLogs/k/kdebase/4:3.3.1-2/ . You need libxinerama-dev
[10:09] <ogra> fabbione: sorry, you will have to wait until tonight.....cant test earlier.....modules grabbed...
[10:10] <fabbione> ogra: fine for me
[10:10] <ogra> good :)
[10:13] <ogra> pitti: hwfu is an awsome work.....not very much left to do....thank you :)
[10:14] <pitti> ogra: oh, there is still lots to do
[10:14] <ogra> pitti: yeah, but the upcoming stuff is quite easy with this nice infrastructure ;)
[10:15] <pitti> ogra: yes, I hope so
[10:15] <pitti> ogra: but all the backends are still missing
[10:15] <pitti> ogra: I think we might need to change the infrastructure too
[10:15] <ogra> pitti: huh ?
[10:15] <ogra> pitti: why that ?
[10:15] <pitti> ogra: e. g. if pci detector adds a new node
[10:16] <pitti> ogra: and another backend wants to add attributes to an already existing PCI node
[10:16] <pitti> ogra: there is currently no way to do that
[10:16] <ogra> hmm
[10:16] <pitti> ogra: you somehow need to identify and address the node you wnat to change
[10:16] <ogra> ok, i'll think about it
[10:16] <pitti> ogra: currently you need to put all backend programs which touch a common node into a single detector module
[10:16] <pitti> this should even work
[10:16] <pitti> but it is not that nce
[10:16] <pitti> nice, evne
[10:16] <pitti> even, even :-/
[10:17] <ogra> heh
[10:53] <Kamion> mdz: what's the rootskel change about?
[10:53] <Kamion> mdz: please do '# CONFIG_BLOCKDEV is not set' in busybox, rather than 'CONFIG_BLOCKDEV=n'; the test suite looks for the former style
[10:54] <Kamion> mdz: blockdev should use busybox's getopt stuff before being submitted to busybox upstream
[10:57] <Kamion> fabbione: ?
[10:59] <fabbione> Kamion: any plan to switch d-i to 2.6.10 ?
[10:59] <Kamion> fabbione: only when it's the default kernel
[11:00] <Kamion> or committed to becoming the default kernel
[11:00] <fabbione> Kamion: ok. than i will bugger mdz again since we agreed to have 2.6.10 as default
[11:00] <fabbione> Kamion: no rush
[11:00] <Kamion> what does mdz need to do?
[11:00] <fabbione> approve it again?
[11:01] <fabbione> and probably stick it somewhere in the seeds?
[11:01] <fabbione> or via ubuntu-meta...
[11:01] <fabbione> can't really remember
[11:03] <Kamion> if it's committed to being the default kernel for hoary, I'm happy to change d-i
[11:03] <Kamion> but the 2.6.10 udebs need to be in main first
[11:03] <fabbione> Kamion: it can wait one day
[11:03] <fabbione> that's what i mean
[11:07] <amu> moins 
[11:07] <fabbione> morning amu
[11:08] <amu> fabbione: moin fabbione ... s/dance/love ;-)
[11:12] <fabbione> no no.. dance
[11:14] <fabbione> pitti: you were asking about posix acl.. yes we compile them
[11:14] <pitti> fabbione: I didn't ask :-)
[11:14] <crimsun> fabbione: that was plovs. I answered him.
[11:14] <fabbione> ah ok
[11:14] <fabbione> sorry...
[11:15] <fabbione> pitti: btw.. you got mail
[11:16] <pitti> fabbione: cool patch, thanks
[11:17] <fabbione> dude.. it's not like i did it.. you know that.. don't you?
[11:18] <pitti> fabbione: I know
[11:18] <fabbione> ok
[11:18] <pitti> fabbione: however, thanks for the work of digging it out :-)
[11:19] <fabbione> no problem man
[11:23] <fabbione> lamont: those hppa might even have 8GB of ram, but they suck at disk I/O
[11:23] <fabbione> tar takes 99% of one CPU
[11:27] <thom> jdub: ack
[11:29] <fabbione> hey thom
[11:29] <thom> morning
[11:30] <pitti> hi thom 
[11:30] <fabbione> hmmm
[11:30] <fabbione> why my background doesn't change anymore?
[11:32] <smurfix> fabbione: I had that yesterday night too. Kill nautilus, it'll work afterwards.
[11:33] <fabbione> smurfix: thanks will do. also tahnks for signing the key. i will look at your pic asair
[11:35] <pitti> Hi seb128 
[11:36] <seb128> hey
[11:39] <fabbione> lamont: 15 minutes it unpacked only 24MB...
[11:39] <fabbione> i think it's time to ask ggg to look at it :-)
[11:47] <smurfix> fabbione: no prob. NB, just rereading the BK discussion ... changesets do have constand identifiers, they're just somewhat more complicated. (What happens in Arch when two people independently decide to name their branch --test-- ?)
[11:47] <fabbione> smurfix: well... i did a test on bk
[11:48] <fabbione> yesterday changeset 1.2097 was a patch for some driver
[11:48] <fabbione> today is the gtk2.4 fix
[11:48] <fabbione> so they get renamed somehow
[11:48] <smurfix> BK inherited those numbers from SCCS.
[11:49] <smurfix> In a distributed system, one of them HAS to be renamed when you're merging.
[11:49] <smurfix> BK decides to consistently renumber (not rename...sorry) the one that's checked in later.
[11:49] <fabbione> smurfix: i don't disagree for the reasons.. it's just more complicate to track them
[11:50] <smurfix> The nice property of that is if two people have the same changes, no matter how they arrived there, the numbers end up the same too.
[11:50] <smurfix> bk 
[11:50] <smurfix> oops
[11:58] <Kamion> smurfix: "What happens in Arch"> don't try to identify arch branches purely by category--branch--version then; archive/category--branch--version is unique even if two people pick --test--
[11:59] <smurfix> Kamion: But what happens after a merge? Then they end up in the same archive.
[12:01] <Kamion> yes, with new patch numbers
[12:01] <smurfix> Ah.
[12:01] <Kamion> the merge is a new change that happens to list the merged change in its merged-patches header (whatever it's called, I forget)
[12:02] <lifeless> smurfix: they end up in the same tree, as patch logs.
[12:02] <lifeless> smurfix: but the archive is part of the patch id.
[12:02] <Kamion> which makes sense since you might have to munge the change to make it apply
[12:02] <lifeless> Kamion: 'new-patches'
[12:02] <Kamion> thanks
[12:05] <smurfix> Hmm, are the patches you merge in still separate? That is, if you merge version 1..20 from some remote branch B, can you still easily get --B--15?
[12:07] <Kamion> they're not separated in the merged change you commit, but getting them from the remote branch doesn't get any harder
[12:07] <Kamion> if you want to be able to get them in the merged-to archive, merge the changes one at a time rather than all at once
[12:10] <smurfix> Ah. This is simpler in bitkeeper then; bk allows you to locally roll back to any change whatsoever. That's very helpful for automated "find the exact change that introduced bug X" testing.
[12:14] <Kamion> smurfix: what if each of those merged changes requires resolution in order to work when merged? how can bk know how to separate out the resolutions if you commit them all at once?
[12:16] <Kamion> I'm assuming that bk does not write your code for you :-)
[12:23] <lifeless> smurfix: tla can roll back equally
[12:24] <lifeless> AFAIK in both systems there is a minimum granularity. in tla thats per-file-hunk, if you want to drill in that far.
[12:29] <gicmo> hi everybode ..
[12:29] <gicmo> sladen, hi and happy new year ... any news on the uslpash front?
[12:30] <seb128> hey gicmo 
[12:30] <cartman> [OT]  http://arstechnica.com/columns/linux/linux-20050102.ars/1
[12:30] <gicmo> jo seb128 :) .. 
[12:30] <cartman> Ubuntu won "Best Distro" and "Best Community"
[12:31] <cartman> and also "Best newcomer to the community"
[12:31] <gicmo_> re .. damn dsl reconnect ..
[12:31] <seb128> jdub: what's going on exactly with usplash exactly ? gicmo is still interested to help on this but seems nobody is really replying to good willing people on this :/
[12:32] <jdub> seb128: mdz and sladen know about it
[12:32] <seb128> mdz: sleeping at this time I guess ? :)
[12:34] <robtaylor> gicmo: http://81.113.230.186/kalatlug/phpwiki/index.php/UsplashHowDoesItWork
[12:36] <robtaylor> seb128: there's been some activity on debian-desktop about it. 
[12:37] <seb128> right
[12:37] <robtaylor> gicmo: may be worth you joining in on the thread there
[12:37] <gicmo_> robtaylor, thanks ..
[12:38] <seb128> gicmo_: http://lists.debian.org/debian-desktop/2005/01/msg00004.html
[12:38] <gicmo_> seb128, and thank you of course
[12:38] <seb128> np :)
[12:39] <seb128> sorry you don't get more reply on this, I'll ping mdz when he'll be awake
[12:39] <jdub> seb128: (what's it doing on debian-desktop...?)
[12:39] <robtaylor> jdub: heh, there may be threads on other ml's too ;)
[12:39] <seb128> jdub: debian guys interested to get a splash too
[12:40] <jdub> seb128: mmm, but no thread on u-d... kinda whacked
[12:40] <seb128> jdub: no, but when people try to ping on the ubuntu side they are ignored for months ...
[12:41] <seb128> jdub: gicmo is trying to help for like 3 months
[12:44] <smurfix> Kamion: In BK, rolling back to a change beyond a merge implies throwing away everything on the "other" branches. You reproduce the whole tree exactly as it was at the time, so there's nothing you might need to resolve.
[12:44] <Kamion> that's not what I meant
[12:45] <jdub> seb128: well yeah, if there's no thread on the ubuntu list, then of course people are going to wonder :)
[12:45] <jdub> seb128: that's precisely the point :-)
[12:45] <Kamion> but I think I thought you were claiming much more about BK than you actually were, so never mind
[12:46] <seb128> jdub: yeah, right
[01:01] <jdub> http://www.leftontheweb.com/archive/2005/01/05/bertie_and_ubuntu
[01:02] <robtaylor> jdub: fancy posting a post on u-d pointing to the thread on d-desktop? =) 
[01:05] <jdub> perhaps in the morning, or you can
[01:05] <jdub> it's very much bed time here
[01:16] <fabbione> hey stub
[01:16] <stub> yo
[01:17] <fabbione> amu was reporting a similar problem for the ipw2200
[01:17] <fabbione> and the fail seems to be related to the firmware load
[01:17] <fabbione> i need you to test a few things for me
[01:17] <fabbione> do you have a standard 2.6.10 from ubuntu or did you compile it yourself?
[01:18] <stub> From ubuntu
[01:18] <fabbione> ok
[01:18] <fabbione> edit /etc/hotplug/firmware.agent
[01:18] <fabbione> and uncomment this line:
[01:18] <fabbione> # DEBUG=yes export DEBUG
[01:18] <fabbione> this will produce some extra noise in syslog
[01:19] <fabbione> now.. after you have done that
[01:19] <fabbione> i need to know what happens if you unload and reload the ipw2200 module
[01:19] <stub> You will need to tell me the magic commands to do that
[01:20] <fabbione> i think the easiest way is to reboot
[01:20] <fabbione> but if you cannot reboot you need to do:
[01:20] <fabbione> ifdown <interface>
[01:20] <fabbione> rmmod ipw2200
[01:20] <fabbione> hem sorry
[01:20] <fabbione> modprobe -r ipw2200
[01:21] <fabbione> wait a few secs that everything is quite
[01:21] <fabbione> modprobe ipw2200
[01:21] <fabbione> this will reload the stuff
[01:21] <fabbione> and check what happens in syslog
[01:21] <fabbione> after that
[01:21] <fabbione> ifup <interface>
[01:21] <stub> k. I'll give that a go and reboot if necessary
[01:21] <fabbione> stub: well if you can reboot it will be much simpler
[01:22] <fabbione> up to you
[01:22] <stub> k
[01:22] <fabbione> eitherway i need to know what happens in syslog
[01:29] <stub> fabbione: There should be debug stuff in /var/log/syslog or /var/log/debug? Can't see anything interesting.
[01:29] <fabbione> syslog
[01:30] <fabbione> iirc each entry should have something like firmare.agent: blabla
[01:30] <fabbione> try a grep for firmware
[01:32] <fabbione> i am sure 100% it saves the stuff in syslog..
[01:32] <fabbione> or grep for hotplug
[01:32] <stub> fabbione: Can't see anything... 
[01:32] <fabbione> hem no..
[01:32] <fabbione> it should be in /var/log/syslog
[01:33] <gicmo> hehe
[01:33] <fabbione> did you remember to uncomment that line in /etc/hotplug/firmware.agent?
[01:33] <fabbione> otherwise just send me the syslog via mail
[01:35] <stub> I can email it, but it isn't very exciting. I can see the messages that dmesg gave me before in the syslog, right near the end. Just nothing new.
[01:35] <fabbione> or try kern.log?
[01:35] <fabbione> it has to be there....
[01:37] <jordi> faaaaaaabio!
[01:37] <fabbione> hem
[01:37] <jordi> fabbione: can you hint me on how to use xdebconfigurator?
[01:37] <fabbione> stub: .. i am on crack...
[01:37] <fabbione> the line was correct
[01:37] <fabbione> but it's missing the proper debug_* functions all over
[01:38] <fabbione> hey jordi 
[01:38] <fabbione> no because that is sooooo worng
[01:38] <fabbione> wrong even
[01:41] <fabbione> stub: please grub http://people.ubuntu.com/~fabbione/firmware.agent
[01:41] <fabbione> and use it in place of the one you have
[01:42] <fabbione> and yeah.. either you reboot or do the module stuff
[01:44] <stub> ok - much more now
[01:45] <fabbione> ok.. can you paste it in pvt please?
[01:45] <fabbione> there should be a bunch of lines.. probably 5/6
[01:46] <fabbione> congratulation stub :-)
[01:58] <Kamion> MMM, baguette + farmhouse/mushroom pt + Austrian smoked cheese + paprika salami
[01:59] <fabbione> slurp!
[02:00] <fabbione> lamont: 2 hours and 35 minutes to unpack the kernel on that hppa....
[02:01] <fabbione> i wonder when i am going to copy it 4 times to test the build...
[02:02] <fabbione> no even better... the N times required to create the patches!
[02:04] <fabbione> stub
[02:04] <fabbione> ops
[02:07] <Kinnison> ;-)
[02:08] <Treenaks> Kinnison: sounds like death in a bag ;)
[02:09] <jdub> www.apple.com/xsan/
[02:10] <Treenaks> how is this done in Linux?
[02:11] <jdub> gfs
[02:11] <jdub> recently b(r)ought back from the brink of irrelevance by red hat
[02:13] <Treenaks> jdub: didn't they open it up? (besides selling it for $much-a-piece)
[02:15] <thom> linux doesn't have shiny xserve-raid boxen, though
[02:15] <jdub> Treenaks: yes, they bought sistina
[02:16] <Treenaks> thom: let the hardware vendors take care of that
[02:23] <amu> fabbione: if you need still some help with the ipw2200, letme know  
[02:26] <fabbione> amu: i will
[02:27] <fabbione> i am trying to understand 2 problems here
[02:27] <fabbione> one is HOW can the card work without the firmware
[02:27] <fabbione> and HOW can the card load the firmware WITHOUT /sys entries.....
[02:27] <fabbione> because the first can't happen without the latter
[02:28] <amu> fabbione: without firmware ? 
[02:28] <fabbione> ah hold on a sec...
[02:28] <fabbione> lamont: i need you to talk with ggg about those hppa man...
[02:28] <fabbione> lamont: 2 hours and 45 minutes to dpkg-source -x the kernel
[02:28] <amu> ok
[02:29] <fabbione> amu: cd /sys/class/firmware && ls
[02:29] <fabbione> what do you have there?
[02:29] <amu> amu@amu:/sys/class/firmware $ ls
[02:29] <amu> timeout
[02:29] <fabbione> ook
[02:30] <fabbione> now.. cd /proc/class/firmware/ && ls
[02:30] <amu> fabbione: should i reboot with your kernel? 
[02:30] <fabbione> amu no need to
[02:30] <amu> ok
[02:30] <fabbione> i will ask stub to do the last test for me
[02:31] <fabbione> if he will still be awake...
[02:31] <amu> amu@amu:~ $ cd /proc/class/firmware/ && ls
[02:31] <amu> -bash: cd: /proc/class/firmware/: Datei oder Verzeichnis nicht gefunden
[02:32] <fabbione> eh?
[02:32] <amu> nothing found :) 
[02:32] <fabbione> ok
[02:32] <fabbione> cat /proc/mounts | grep sysfs
[02:33] <amu> amu@amu:~ $ cat /proc/mounts | grep sysf
[02:33] <amu> sysfs /sys sysfs rw 0 0
[02:35] <pitti> seb128: here?
[02:35] <fabbione> ok i found the problem
[02:35] <fabbione> amu, stub: go and get some better hardware
[02:36] <fabbione> the Fatal Error is not realted to the firmware
[02:36] <seb128> pitti: yes
[02:36] <fabbione> but an irq error of somekind
[02:36] <lamont> fabbione: I know there are other people using that machine sometimes - dunno what the load average is.
[02:36] <fabbione> the firmware is loaded properly even if i don't know how (yet)
[02:36] <pitti> seb128: I just stumbled over a similar bug that mdz recently saw
[02:36] <fabbione> lamont: it was only me and dave....
[02:36] <fabbione> lamont: load is 2 now...
[02:36] <pitti> seb128: I tried to shutdown, the dialog appears, I click on restart and click enter
[02:37] <fabbione> lamont: there is something wrong with disk I/O there
[02:37] <pitti> seb128: but it doesn't shutdown, my terminals hang (I cannot type into them any more)
[02:37] <lamont> I'll mention it to him.
[02:37] <pitti> seb128: but other apps (xchat, ffox) run okay
[02:37] <pitti> seb128: and I can't click on the menu
[02:37] <seb128> pitti: weird. Is that reproducible ? 
[02:37] <fabbione> lamont: thanks
[02:37] <pitti> seb128: neither I can click in the bottom bar
[02:38] <pitti> seb128: there is a fourth window (a error dialog, I suppose), but I cannot click on the button to see it
[02:38] <fabbione> lamont: btw.. the patch applied almost without any problem.. only a couple of offsets here and there
[02:38] <pitti> seb128: oh wait
[02:38] <pitti> seb128: alt+tab does the trick
[02:38] <seb128> pitti: looks like the dialog is modal
[02:38] <lamont> fabbione: cool
[02:38] <seb128> and you have to close that first
[02:38] <seb128> to click anywhere else
[02:38] <pitti> seb128: I see a window list which shows apps that don't support setting save
[02:38] <fabbione> lamont: yeah.. i didn't take pa6 because according to cvs there is a FTBFS
[02:38] <pitti> seb128: however, I did not choose to save my session
[02:39] <fabbione> lamont: also.. we are going to build 32 and 64.. do we need anything more than that?
[02:39] <fabbione> lamont: like all the other flavours that cvs build?
[02:39] <lamont> {32,64}{,-smp}
[02:40] <elmo> anyone know why my win key is now mapped to Super_L and how I ask gnome nicely for it not to be?
[02:40] <elmo> well, s/win/apple/, but YKWIM
[02:40] <Kinnison> elmo: keyboard properties thingy probably
[02:41] <elmo> yeah, there's nothing obvious in there - unless I'm missing some terminology confusion
[02:41] <amu> fabbione: yeah using most time a extern pcmica-wlan, i'm wondered about what i'll do, if i meet once a time the guy who developed such stupid hardware/software like the ipw2200 .... my next laptop will be a non-intel hardware. 
[02:41] <lamont> back in an hour or so
[02:42] <lamont> fabbione: that's 4 kernels :-)
[02:42] <Treenaks> amu: avoid apple as well then, their broadcom chip isn't supported very well either (or at all)
[02:43] <pitti> seb128: okay, that worked :-)
[02:43] <pitti> seb128: so I see two bugs here:
[02:43] <pitti> seb128: first, the modal dialog should be at the top
[02:43] <seb128> yeah, this is going to be fixed
[02:43] <pitti> seb128: second, I did not choose to save my session, why did it try?
[02:44] <seb128> I'm working with upstream on the top level issue
[02:44] <pitti> crimsun: I have xfs working on my -hardened kernel :-)
[02:44] <pitti> seb128: okay, thanks!
[02:44] <pitti> fabbione: the EXPORT_SYMBOL(protection_map) trick works perfectly, thanks!
[02:44] <seb128> pitti: system -> preferences -> session
[02:44] <seb128> pitti: do you have the autosave set here ?
[02:44] <pitti> seb128: no, I don't
[02:45] <seb128> ok, so that's weird
[02:45] <pitti> seb128: and I don't want it :-)
[02:45] <seb128> really
[02:45] <seb128> let me know if you get this again
[02:45] <pitti> sure
[02:45] <seb128> any chance you messed up with a keybinding to check the save option ?
[02:45] <amu> Treenaks: already done, but apple do it in a better way, there's null support for it, with intel you feel like you'll be their beta-hardware-tester,  spend too much time in order that it works fine. 
[02:45] <fabbione> lamont: yeah 4 kernels...
[02:45] <fabbione> amu: well i just read all the code for the ipw2200
[02:46] <amu> fabbione: firmware ....   
[02:46] <fabbione> amu: the module fails badly if it cannot create the /sys entries and if it cannot load the firmware
[02:46] <Treenaks> fabbione: ah that's the Smell of Undeadness
[02:46] <pitti> lamont: can you please have a look why my tiff security update for warty does not build?
[02:46] <fabbione> amu: the driver still can load, but it won't work
[02:47] <fabbione> amu: so basically what i am saying is that the "Fatal error" you and stub can see is not related to the firmware but to an irq problem on your machine
[02:47] <pitti> seb128: I use ctrl+alt+delete as a shortcut for shutting down
[02:47] <fabbione> pitti: no problem.. :-)
[02:48] <pitti> seb128: however, I installed this keybinding just before the shutdown
[02:48] <seb128> oh
[02:48] <seb128> you set ctrl/alt/delete for logout ?
[02:49] <seb128> that may be an issue, there is some bug about such configs
[02:49] <pitti> seb128: well, c+a+d doesn't do anything under X otherwise...
[02:49] <pitti> seb128: shall I try with another keybinding?
[02:49] <amu> fabbione: .. the other problem, the card just automatically switch off, if the signal is too low, it happens every 15-20 sec.   
[02:50] <pitti> seb128: did mdz use a keybinding? or the menu?
[02:51] <seb128> pitti: I've not asked, I assumed that he was using the menu
[02:51] <seb128> almost nobody use a keybinding for this
[02:51] <lamont> pitti: known issue, being dealt with (build is fine)
[02:51] <pitti> okay
[02:51] <pitti> seb128: but it is actually nice to have one...
[02:52] <seb128> there is a patch for cc/metaticy upstream to open the logout dialog on ctrl-alt-del
[02:52] <pitti> seb128: is the particular key combination the problem or the assignment of a shortcut to logout?
[02:52] <seb128> there was a thread on ubuntu-devel (or user ?) some time ago about this 
[02:52] <pitti> hmm, okay
[02:53] <seb128> seems to work fine here with Ctrl-Alt-l
[02:53] <seb128> lemme try c-a-d
[02:54] <seb128> pitti: I'm not going to kill my xorg by doing this, right ? :p
[02:54] <pitti> seb128: no, it doesn't do anything normally
[02:54] <pitti> seb128: x.org is control-alt-backspace :-)
[02:55] <seb128> works fine here
[02:55] <pitti> hmm
[02:55] <seb128> at least it opens the dialog and the save is not checked
[02:55] <pitti> seb128: I try to reproduce it the next time I shut down
[02:55] <pitti> seb128: it was not checked for me either
[02:55] <pitti> seb128: but after I clicked ok, the session dialog appeared in the bg
[02:55] <pitti> seb128: you actually have to shutdown to try it, sorry :-/
[02:55] <seb128> ok
[02:56] <seb128> I don't want to close my session now
[02:56] <seb128> will try later
[02:56] <pitti> np
[02:56] <pitti> thanks
[02:56] <seb128> np
[03:01] <fabbione> amu: is that with the upstream driver?
[03:01] <fabbione> or only with the kernel one?
[03:01] <fabbione> (our kernel i mean)
[03:02] <amu> generally
[03:04] <fabbione> ok
[03:05] <pitti> trulux: hi
[03:06] <trulux> pitti, hey!
[03:54] <lamont> ,ppf
[03:54] <lamont> moof, even
[03:58] <cartman> lamont: got my message about kdelibs compile error?
[04:00] <amu> fabbione: same problem ( ipw2200 ) with the liveCD ( d-i ) and the 2.6.9 i386 kernel, hotplug detect there's a wlan-card, dhcp runs without success 
[04:00] <seb128_> elmo_away: here ?
[04:04] <gicmo> Kamion, I have been told that you might know how to help me .. how do I "correct" langugage and country settings after the installation .. is there a clean way?
[04:04] <gicmo> or anybody else?
[04:04] <pitti> gicmo: sudo dpkg-reconfigure locales
[04:04] <seb128> "sudo dpkg-reconfigure locales" for the default locale
[04:05] <pitti> gicmo: well, that doesn't correct your country, but the language at least
[04:05] <pitti> gicmo: otherwise you might try rerunning base-config
[04:05] <Kamion> re-running base-config wouldn't do anything useful.
[04:05] <pitti> no, base-config doesn't do that, sorry
[04:05] <Kamion> about the only things that the country option is used for are (a) the locale and (b) /etc/apt/sources.list
[04:05] <gicmo> pitti, the problem is I wanna have english as default lang but have paper size, units, date formats usw in german style
[04:06] <Kamion> gicmo: man 7 locale
[04:06] <Kamion> you can set LC_<stuff> separately in your environment
[04:06] <pitti> gicmo: set this up in /etc/environment
[04:06] <seb128> /etc/environment by hand ? or is it an UI for that ?
[04:06] <Kamion> so LC_TIME=de_DE.UTF-8
[04:06] <gicmo> Kamion, ahh thanks .. thats what I thought to do .. but I wanted to know if there is a debian way of doing that ..
[04:06] <Kamion> why use /etc/environment? shell startup scripts much easier
[04:06] <pitti> seb128: vi :-)
[04:07] <Kamion> and this is a user-specific thing so doing it system-wide is probably not what you really want
[04:07] <seb128> pitti: that's what I call "by hand" :p
[04:07] <gicmo> yeah thats totally "by hand"
[04:07] <pitti> seb128: just kidding :-)
[04:07] <Kamion> maybe the default shell startup scripts etc. should source ~/.environment or something, and there could be a user-level UI to change that
[04:08] <gicmo> thanks anyways
[04:08] <Kamion> nice and per-user
[04:08] <Treenaks> gicmo: I do: LANG=nl_NL and LC_MESSAGES=en_US
[04:08] <Treenaks> gicmo: works great
[04:08] <gicmo> yeah thats what I searched for ..
[04:19] <seb128> Keybuk: that's the intended behaviour for the desktop file ...
[04:19] <Keybuk> seb128: ah, I may have misunderstood.  I thought desktop files had to be made executable first
[04:19] <seb128> no, that's what the guy would like to get
[04:20] <Keybuk> right, I misunderstood the thread then :p
[04:20] <seb128> you can say that you didn't read it :p
[04:20] <Keybuk> I read it
[04:21] <lamont> how do I get screen to actually _EXIT_?
[04:21] <Keybuk> I think I just lost context
[04:21] <seb128> there is a potential security issue in fact, but I've no real idea on how to fix it
[04:21] <seb128> lamont: ctrl-D ?
[04:21] <lamont> seb128: that doesn't just get passed through to the remote?
[04:21] <Keybuk> .desktop files should definietly require +x
[04:22] <Keybuk> as they're basically an arbitrary single-line shell script
[04:22] <seb128> Keybuk: that would not make a big difference
[04:22] <Keybuk> I'm just thinking of an interesting caveat
[04:22] <seb128> you don't expect to get a question when you click on a panel launcher
[04:23] <fabbione> amu: in 2.6.9 there were no ipw2200 updates
[04:23] <Keybuk> "a question" ?
[04:23] <seb128> "do you want to run or see this ..."
[04:23] <Keybuk> anything in the panel or menus should be made +x by the panel/menu surely?
[04:23] <seb128> you got that when you click on a +x file
[04:23] <Keybuk> so here's an interesting other problem
[04:23] <seb128> yeah, and what about my desktop_is_home ?
[04:23] <Keybuk> a user sticks a .desktop file in their home directory, designed to look like a file
[04:24] <Keybuk> and asks another user or even root to read that
[04:24] <Keybuk> they double-click it, and it wipes their home directory
[04:24] <Keybuk> should you be able to run .desktop files owned by other users?
[04:25] <seb128> hum
[04:25] <Keybuk> hell, you could make it look like a folder
[04:25] <Keybuk> "in my shared directory, you'll find..."
[04:25] <seb128> there is no interest to run a .desktop owned by somebody else
[04:25] <lamont> unless they ask you to look at it...
[04:25] <seb128> yeah, that need some thought ... but I fear it'll not be easy to change
[04:28] <Keybuk> http://descent.netsplit.com/~scott/kill-root.desktop
[04:28] <Keybuk> there's *no way* of knowing that's not a folder
[04:31] <Keybuk> drop one of those in a gnome-user-share too
[04:31] <seb128> yeah, any suggestion ? Putting an emblem on all the desktop files ?
[04:31] <Keybuk> I don't think that's sufficient, you'd first need to train what the emblem means
[04:31] <seb128> the executable or not issue doesn't change the result on a drive
[04:31] <thom> seb128: what are we going to do about typeaheadfind in ephy?
[04:32] <seb128> thom: that's a firefox bug
[04:32] <Keybuk> I think it's better to make .desktop files only work if you own them, or they're attached to thinks like the panel etc.
[04:32] <seb128> chpe said than a firefox guy was working on fixing the typeahed in firefox
[04:32] <Keybuk> otherwise they'd show up as just a text/desktop file
[04:32] <lamont> is this a nautilus thing, or what's executing the desktop file?
[04:32] <seb128> and if that's not done by GNOME 2.10 time he'll try to fix it
[04:32] <Keybuk> lamont: nautilus thing
[04:32] <thom> seb128: has he heard any more? oh, right
[04:33] <thom> or a graphical mail client
[04:33] <seb128> thom: and somebody is working on a epiphany-extension like the firefox search stuff IIRC
[04:33] <Keybuk> gnome-vfs sees them as .desktop files (in Open/Save etc.)
[04:33] <thom> seb128: righty
[04:34] <lamont> thom: ditto
[04:38] <lamont> uploads are working again, logs are still pending
[04:39] <__daniel> hai everyone
[04:41] <__daniel> is already some lang-pack stuff going on in hoary? i was curious why anjuta failed to work and when i straced it, it gave me loads of messages like "stat("/usr/share/locale-langpack/de/LC_MESSAGES/anjuta.mo", 0x7fbffff300) = -1 ENOENT (No such file or directory)" - before it segfaulted
[04:41] <__daniel> does anyone have an idea?
[04:42] <fabbione> the stat shouldn't be fatal
[04:42] <mvo_> __daniel: there is some langpack stuff going on 
[04:42] <pitti> __daniel: yes
[04:42] <mvo_> but it shouldn't segfault :)
[04:42] <pitti> __daniel: our new libc6 already supports the alternative gettext tree
[04:43] <fabbione> pitti: so did we enable the pkgtranslation stripping on the buildd?
[04:43] <pitti> __daniel: right, is the segfault related to this?
[04:43] <pitti> fabbione: no, at least I don't know about it
[04:43] <fabbione> lamont: ?
[04:43] <pitti> fabbione: this new libc6 is in hoary since Matar
[04:43] <fabbione> yeah i know that...
[04:44] <fabbione> bbl
[04:45] <__daniel> pitti: i cannot tell, if it really is
[04:45] <pitti> __daniel: the ENOENT result is natural, there are no files there (yet)
[04:45] <cartman> lamont: ping
[04:45] <__daniel> pitti: i see
[04:45] <pitti> __daniel: however, it should now behave exactly like Debian's libc6
[04:45] <pitti> __daniel: try Debian's libc6
[04:46] <pitti> __daniel: btw, would you be oppopsed to support my -hardened kernel in your next X.org upload?
[04:46] <__daniel> pitti: i tried to learn gvim the last 2 hours, but i got stomach ache after trying too hard ;-)
[04:46] <__daniel> pitti: erm... i'm not daniels :-)
[04:46] <pitti> __daniel: why, what's wrong about it? (I use console vim)
[04:47] <pitti> __daniel: oops, sorry :-)
[04:47] <__daniel> pitti: no problem :-)
[04:47] <cartman> daniels supposed to upload a new X.org yesterday
[04:47] <cartman> hrhr
[04:47] <__daniel> pitti: maybe i just need that vim mug :-)
[04:52] <lamont> fabbione: I still need to understand what needs to be done on the buildds to enable it... thought pitti was sending me some mail
[04:52] <lamont> cartman: yo
[04:52] <cartman> lamont: any way I could help with Ubuntu kde packs?
[04:53] <lamont> cartman: patches for the outstanding bugs there would be good...
[04:53] <pitti> lamont: you need to install pkgstriptranslations in the build chroot and enable it in /etc/pkgstriptranslations.conf
[04:53] <pitti> lamont: that's all, debhelper will automatically use it
[04:53] <cartman> lamont: where would I see the outstanding bugs? Is there a list?
[04:53] <lamont> cartman: but then, I'm not managing the kde side of things
[04:53] <lamont> build logs are under http://people.ubuntu.com/~lamont/buildLogs/
[04:54] <__daniel> bye *wave*
[04:54] <lamont> and the status of builds is at .../Lists
[04:54] <cartman> lamont: yesh you need to install libxinerama-dev
[04:54] <cartman> I checked error log
[04:54] <pitti> lamont: the earlier we enable it, the less packages we have to rebuild before the release, but we will lose all translations until rosetta has the necessary export support
[04:54] <lamont> pitti: that's step 1... where do I put the extracted files? are they in the build directory? (that gets nuked after the build, you see...), etc, etc.
[04:55] <pitti> lamont: the files are just deleted, don't worry about them
[04:55] <pitti> lamont: as I said, install the package, enable it in the conffile, kthxbye
[04:55] <cartman> lamont: so who is the person organising KDE side?
[04:55] <pitti> lamont: we cannot use the extracted mo files for various reasons, so we throw them away
[04:55] <lamont> pitti: E: Couldn't find package pkgstriptranslations
[04:56] <pitti> $ apt-cache show pkgstriptranslations
[04:56] <pitti> Package: pkgstriptranslations
[04:56] <pitti> Priority: extra
[04:56] <pitti> Section: universe/devel
[04:56] <pitti> Installed-Size: 64
[04:56] <pitti> Maintainer: Martin Pitt <martin.pitt@canonical.com>
[04:56] <thom> pitti: you're far too polite to pull off KTHXBYE :-)
[04:56] <pitti> lamont: I updated the seeds yesterday, they might not have been updated since then
[04:56] <lamont> pitti: meaning universe?
[04:56] <lamont> ok
[04:57] <pitti> lamont: do you know when the seeds are recomputed?
[04:57] <pitti> lamont: I updated the arch tree yesterday morning
[04:57] <lamont> pitti: there's a manual step involved before it actually affects the archive
[04:58] <pitti> lamont: I was asked to make it configurable
[04:58] <pitti> lamont: so if users install it it won't break their source builds
[04:58] <pitti> lamont: is the config default "off" a problem?
[05:03] <lamont> pitti: 10/12 done, other 2 quiescing
[05:03] <lamont> quiesceing
[05:04] <lamont> given that it's installed in the chroot forever, no issue at all.
[05:04] <lamont> the next question is, should it be in hoary.buildd, or not.
[05:04] <pitti> lamont: what did you quiesce?
[05:04] <lamont> buildds
[05:04] <pitti> lamont: personally I'd say we can live with losing translations for some time
[05:05] <pitti> lamont: but I think mdz should decide this
[05:05] <lamont> pitti: at your request, I just enabled it in 10 buildds
[05:05] <pitti> lamont: you mean you isntalled the package on 10 out of 12 buildds?
[05:05] <lamont> now you're not sure???
[05:05] <lamont> installed and enabled
[05:05] <lamont> as you requested
[05:06] <lamont> config file only cares about the 'enable: (true|false)' line, yes?
[05:06] <pitti> lamont: yes
[05:06] <lamont> and we do want it enabled everywhere starting now?
[05:06] <pitti> lamont: ahem - you asked me what is _required_ to enable it, not wheter I actually wanted to enable it right now...
[05:07] <lamont> ah, so I shouldn't do that then?
[05:07] <pitti> lamont: I'd ask mdz before pulling the trigger
[05:07] <pitti> lamont: he should be awake soon, I hope
[05:11] <lamont> seb128: eta on a new vte?
[05:12] <seb128> upstream or debian/ubuntu ?
[05:12] <Keybuk> hmm, ACPI hotplug support
[05:12] <lamont> ubuntu, python2.4
[05:12] <lamont> specifically, #5139
[05:12] <seb128> upstream dunno but a patch sent a heavy patched package on the gtk-gnome list, I've planned to review/use it
[05:12] <seb128> oh, that
[05:12] <seb128> is there any hurry ?
[05:12] <seb128> I would say tomorrow if there is no hurry
[05:13] <lamont> yeah - officially? no
[05:13] <pitti> lamont: hmm, now tiff was built on amd64, but not on the other arches...
[05:13] <lamont> if this week, I'm happy.  If it'd be next week, I'd volunteer to deal with it while I'm walking through everything
[05:14] <lamont> pitti: it's possible that I missed some in my cleanup - let me check
 (04/11/11 1.2044)
[05:16] <Keybuk>    [ACPI]  CPU hotplug, use kobject_hotplug(), kobject_register()
[05:16] <Keybuk> sladen: that should be useful for u :p
[05:18] <lamont> pitti: i386 should arrive in about 20 minutes, ppc may actually finish building (damn kernel bugs)
[05:18] <pitti> okay, thanks
[05:39] <mdz> pitti: hmm?
[05:39] <pitti> mdz: morning
[05:40] <pitti> mdz: we discussed a bit about whether we should enable gettext stripping on the buildds now
[05:40] <pitti> mdz: rosetta support for langpacks will still last a week or so
[05:40] <pitti> mdz: but the earlier we enable it, the fewer packages we have to rebuild before the release
[05:41] <pitti> mdz: so if we enable it now, we will gradually lose translations as packages are uploaded
[05:41] <pitti> mdz: lamont installed pkgstriptranslations in the buildds, but did not yet enable it so far
[05:42] <mdz> pitti: now that upstream version freeze has happened (I assume), it doesn't really matter, since the pace of builds will have dropped to nearly zero
[05:42] <mdz> pitti: if it is easier to wait, then wait
[05:42] <mdz> Kamion: the rootskel change is in order to reload init
[05:42] <mdz> fabbione: I see no reason not to move to 2.6.10 as default; the IRQ routing thing will be fixed
[05:43] <Kamion> mdz: reload init when?
[05:43] <pitti> mdz: well, its as easy to do it now as at any other time
[05:43] <Kamion> huh, where did mdz's base-config changes disappear to?
[05:43] <pitti> mdz: the question is whether we can temporary live with missing translations
[05:44] <pitti> mdz: (in hoary)
[05:44] <mdz> pitti: it will break the translations for all users until the language packs are caught up, no?
[05:44] <mdz> Kamion: what base-config changes?
[05:44] <mdz> Kamion: reload init to get from the busybox init to the real sysvinit
[05:44] <mdz> Kamion: if you try out the live CD I posted to -devel about, it'll be clear
[05:45] <Kamion> mdz: ubuntu7 and ubuntu8 haven't made it to archive.u.c yet
[05:45] <Kamion> and I want to upload ubuntu9 :)
[05:46] <Kamion> mdz: oh, damn, I'm stupid, busybox-cvs got mapped to base-config in my brain, sorry
[05:46] <Kamion> mdz: you mean on SIGUSR1?
[05:46] <pitti> mdz: newly uploaded packages will not have translations any more until we supply langpacks, right
[05:46] <mdz> Kamion: according to lamont, part of the build infrastructure is fucked
[05:46] <mdz> Kamion: correct
[05:46] <mdz> has elmo turned up yet?
[05:47] <Kamion> he was around earlier, fighting with GNOME
[05:47] <mdz> god dammit, we inherited the broken version of flac
[05:47] <mdz> upstream version freeze was supposed to happen yesterday
[05:47] <mdz> has anyone heard from elmo?  is he dead?
[05:47] <lamont> mdz: that was fixed this am
[05:48] <lamont> if any are missing, holler
[05:48] <mdz> oh, that was base-config/busybox-cvs confusion
[05:48] <lamont> mdz: when I chatted with elmo ~3 hours ago, he estimated 4 hours for him to be in london.
[05:48] <Kamion> yeah
[05:48] <mdz> Kamion: thanks for looking over my busybox mangling; I was fairly certain it was not ideal
[05:48] <lamont> so I expect that he's on the road
[05:49] <Kamion> mdz: I can probably do the getopt conversion; I'd actually started on it but you beat me to the upload :)
[05:49] <lamont> Kamion: which package were you questioning?
[05:49] <Kamion> lamont: it was PEBKAC, don't worry about it
[05:49] <mdz> Kamion: I did?  I thought you were in deep sleep
[05:49] <lamont> ok.
[05:49] <lamont> mdz: you're bouncing really large files, if you didn't know..
[05:50] <Kamion> mdz: I started shortly before finishing work, but left at about 8pm and only got back this morning
[05:50] <seb128> Kamion: any problem with GNOME ?
[05:50] <Kamion> seb128: no idea
[05:51] <mdz> lamont: yes, over 10M I think, but who would send me such things via email?
[05:51] <lamont> sarti
[05:51] <mdz> Kamion: my config/local now has zero EXTRAFILES in it :-)
[05:52] <Kamion> mdz: cool!
[05:52] <Kamion> how much in localudebs?
[05:52] <mdz> only one
[05:53] <mdz> (casper)
[05:53] <Kamion> casper?
[05:53] <mdz> the tentative name for the magical bit
[05:53] <Kamion> mdz: oh, what do you think about that cryptsetup thing on u-d?
[05:53] <Kamion> the encrypted-swap-by-default proposal
[05:54] <mdz> if it can get done by featurefreeze, sure
[05:54] <mdz> though, someone else reported a bug that the bit which is supposed to configure it at boot had a bug
[05:54] <mdz> and looking at it, it's insane
[05:55] <mdz>                                 if test -e "$key" ; then
[05:55] <mdz>                                         MODE=`ls -l $key | sed 's/^....\(......\).*/\1/'`
[05:55] <mdz>                                         OWNER=`ls -l $key | sed 's/^[^ ] * *[^ ] * *\([^ ] *\).*/\1/'`
[05:55] <Kamion> ick
[05:56] <Kamion> ok, I'll work with him to see what we can get into partman, if possible
[05:57] <pitti> Kamion: FWIW, if it is supportable, having cryptsetup in main would rock
[05:58] <mdz> only two followups regarding live CD testing while I slept :'-(
[05:58] <mdz> did anyone here try it?
[05:58] <Kamion> mdz: is that cryptsetup code?
[05:58] <mdz> Kamion: yes, that's from cryptsetup
[05:58] <Kamion> my pipe is currently full of two weeks' worth of Ubuntu archive re-mirroring
[05:59] <Kamion> the local mirror's been busted for a while ...
[05:59] <mdz> lamont: where do we stand on the desktop fs builds?
[05:59] <thom> i'm currently laptop only, and so no cd capability
[05:59] <mdz> thom: you bastards and your X40s
[05:59] <mvo_> mdz: I tried the one from amu at 2005-01-03 and it bootet for me
[05:59] <mdz> mvo_: this is completely different
[05:59] <thom> mdz: *g*
[06:00] <mvo_> mdz: ok, I'll get the new one then 
[06:00] <mdz> it's looking pretty sweet
[06:00] <mdz> it already works unmodified on both ATA CD-ROMs and USB ones
[06:01] <mdz> Kamion: do you have any idea why the console is messed up until I switch VCs?
[06:01] <mdz> Kamion: does bterm or whatever not clean up when it's killed?
[06:02] <mdz> it happens at a very awkward time, so I think I'd prefer to fix the cause rather than add some code to switch VCs or otherwise work around it
[06:02] <lamont> mdz: looking at that today, actually
[06:02] <Kamion> TBH it would surprise me if it cleaned up properly ...
[06:02] <mdz> lamont: only new item is that it must include a kernel
[06:02] <sladen> keybuk: interesting, we'll see.   I'm currently considering fetching the detection code from speedstep-lib, but even that falls back to checking the alphanumeric name at some points
[06:02] <mdz> lamont: so, debootstrap + task: ubuntu-desktop (or metapackage ubuntu-desktop) + linux-foo
[06:03] <lamont> ok
[06:03] <lamont> for what value of foo, I wonder...
[06:03] <mdz> Kamion: is there some way that lamont can easily borrow the kernel logic from base-installer?
[06:03] <mdz> (I think it's base-installer)
[06:03] <lamont> mdz: I think I just wind up populating a kernel or 3 (ppc) into the file system, and then it's the boot system's pain, not mine...
[06:03] <lamont> no?
[06:04] <lamont> because the buildd has no clue what machine you'll be booting on...
[06:04] <mdz> lamont: the only bit which matters at all is /lib/modules
[06:04] <mdz> lamont: anything else is a (tolerable) waste of space
[06:04] <mdz> lamont: the kernel is already loaded by the time we get anywhere near that filesystem
[06:04] <Kamion> mdz: base-installer/kernel/README documents the API ...
[06:04] <lamont> so a non-tuned i468 kernel, for example
[06:04] <Kamion> mdz: I'm not convinced the logic is appropriate though?
[06:05] <mdz> yeah, I suppose it's overkill
[06:05] <Kamion> don't we just want to hardcode an appropriate kernel for each arch? base-installer tries to pick the closest one to the hardware, which is different
[06:05] <mdz> what we want is: i386 -> linux-386, powerpc -> all of them, I suppose, amd64 -> amd64-generic
[06:05] <Kamion> the build machine's hardware will often be better than the machine the CD's running on
[06:06] <Kamion> agreed
[06:06] <lamont> mdz: do you want the vmlinux left present, or removed?
[06:06] <mdz> lamont: if we get tight on space, I might ask you to terminate it with prejudice, but in the name of simplicity, let's leave it alone for now
[06:06] <mdz> likewise for the initrds
[06:07] <lamont> ;k
[06:07] <mdz> hmm, speaking of which, won't that be a problem on powerpc?
[06:07] <mdz> will it be able to generate all of the initrds properly?
[06:07] <lamont> what? space?
[06:07] <mdz> we might need to add some kernel-package magic to tell it not to worry about all that initrd business
[06:07] <Kamion> (note that ext2 is not built into the powerpc kernels)
[06:07] <lamont> do the initrd's come from the cloopfs?
[06:07] <mdz> if there is'nt such an option buried there already
[06:07] <Kamion> don't see why it wouldn't be able to generate all the initrds?
[06:08] <mdz> lamont: the system is booted using a kernel an initrd on the CD, like on the install CDs
[06:08] <lamont> Kamion: which fstype should we use for ppc then?
[06:08] <mdz> lamont: so the only thing of importance in the cloop fs is the modules
[06:08] <lamont> mdz: right.  so you're just worried about install?
[06:08] <lamont> install into the cloopfs, that is
[06:08] <Kamion> lamont: actually ext2 could be loaded by the live CD infrastructure
[06:08] <Kamion> so pretend I didn't say anything :)
[06:08] <mdz> lamont: yeah, I'm pre-worrynig about problems you might run into, basically
[06:08] <lamont> Kamion: heh
[06:08] <mdz> Kamion: as long as ext2 is available in udeb form, we're OK
[06:08] <Kamion> it is, d-i wouldn't work otherwise
[06:09] <lamont> Kamion: if there's a better format for it, it's no problme to use that on ppc
[06:09] <Kamion> nah, cramfs for a filesystem the size of the live CD's would suck, I expect
[06:09] <mdz> ext2 is a natural choice
[06:09] <Kamion> mdz: make sure to depend on ext2-modules
[06:09] <lamont> Kamion: right.
[06:09] <mdz> cramfs is no good; it needs to be writable
[06:09] <mdz> Kamion: I'm thinking it might be best if you wrangled the d-i stuff, to be honest
[06:10] <lamont> mdz: does it need to be created with extra space, or will that just magically show up in the course of things?
[06:10] <Kamion> ok, I'm willing to do the administrivia on that front
[06:10] <mdz> I have a feeling it would take me all day, and you a trivial amount of time
[06:10] <mdz> lamont: make it big
[06:10] <mdz> say 3G
[06:10] <mdz> the slack will compress out
[06:10] <Kamion> mdz: send me hacked packages with all the live-CD-specific logic, and I'll put it together?
[06:12] <mdz> there's basically one udeb
[06:12] <mdz> which I am sending to you
[06:12] <mako> does someone know how i can get to the old wiki?
[06:12] <mdz> Kamion: you already have the diff from amu, which is basically what I was using
[06:12] <mdz> with two modifications:
[06:12] <amu> mdz: the livecd-script ? 
[06:12] <mdz> amu: we're talking about the d-i changes
[06:12] <Kamion> mdz: what I'd like, actually, is to have a tiny udeb in the initrd which decides whether it's turning on live-CD functionality, and arranges for the appropriate udeb to be installed; the idea there is that we can use the same initrds for both install and live CDs
[06:12] <mdz> casper is used instead of livecd-script
[06:13] <amu> mdz: 
[06:13] <Kamion> so the install CD would have a tiny extra bit of overhead which looks basically like rescue-check does
[06:13] <mdz> Kamion: hmm, that'd be nice
 there's basically one udeb? 
[06:13] <mdz> Kamion: I can have casper build an extra udeb for that, I suppose
[06:13] <Kamion> mdz: look at the rescue source
[06:13] <mdz> E: Unable to find a source package for rescue
[06:14] <smurfix> mako: seems to be a server-side redirect => ENFW
[06:14] <Kamion> svn://svn.debian.org/d-i/trunk/packages/rescue
[06:14] <mdz> hmm
[06:14] <mdz> subversion is still at python2.3?
[06:14] <Kamion> subversion depends on python?!
[06:14] <Kamion> subversion-tools, yeah ...
[06:16] <mdz> Kamion: I'm also not so clear on which udebs should be pulled in by casper dependencies, and which should be in the pkg-lists lists
[06:16] <mdz> probably casper should depend on dmsetup-udeb
[06:16] <mdz> and cloop-modules
[06:17] <mdz> er, loop-modules
[06:17] <Kamion> mako: https://www.ubuntu.com/FrontPage
[06:17] <mdz> and cdrom-detect
[06:17] <Kamion> mdz: if we were going for same-initrd-for-both, then everything that isn't already in pkg-lists should be depended on by casper
[06:18] <mdz> I think that's all that we added
[06:18] <mdz> but we had to remove a bunch of stuff
[06:18] <Kamion> cdrom-detect will be needed to load casper anyway, if it's not in the initrd
[06:18] <mdz> how are we going to handle that if we use the same initrd?
[06:18] <Kamion> what had to be removed?
[06:18] <mdz> basically everything from partman onward
[06:18] <mdz> so I don't need to depend on cdrom-detect, right?
[06:18] <Kamion> that's not in pkg-lists, except for monolithic
[06:18] <mdz> Depends: dmsetup-udeb, loop-modules
[06:18] <mdz> ext2-modules?
[06:19] <Kamion> hm, best depend on cdrom-detect anyway, it would be possible to netboot into casper
[06:19] <Kamion> ext2-modules, yeah
[06:19] <mdz> all kinds of fun things become possible :-)
[06:19] <mako> Kamion: i would *never* have guessed that :)
[06:20] <Kamion> basically the initrds other than monolithic are only supposed to contain enough stuff to retrieve more udebs
[06:20] <Kamion> mako: I found it by way of a bug
[06:20] <mdz> right
[06:20] <mdz> Kamion: I can assume that busybox will be present, right?
[06:20] <mdz> trying to think what else I use
[06:21] <Kamion> mdz: absolutely
[06:21] <mdz> I think that's it
[06:21] <Kamion> mako: go to http://www.ubuntu.com/wiki/, and then try logging in ...
[06:21] <Kamion> note how after you enter username and password it drops you into the old wiki :)
[06:21] <Kamion> mdz: busybox is used for /sbin/init
[06:22] <mdz> Kamion: what sequence number should I use for the d-i-startup.d script?
[06:22] <mako> Kamion: ahhh.. 
[06:22] <Kamion> mdz: anything from 50 or so onward should be fine
[06:23] <mdz> Kamion: is it inappropriate to name it casper-udeb, since it's essentially d-i-specific maybe it should have a name like rescue-mode?
[06:24] <cartman> vorbis-tools needs to be built against updated libflac
[06:24] <Kamion> I only call stuff -udeb when it has a non-udeb equivalent
[06:24] <Kamion> maybe just casper?
[06:24] <mdz> there is likely to be a casper-utils or similar which is a normal deb
[06:24] <Kamion> or casper-<whatever-it-does>
[06:24] <mdz> to be installed in the target fs
[06:24] <Kamion> casper-pivot?
[06:24] <mdz> it's sort of a casper-mode
[06:25] <mdz> cartman: more accurately, flac is just broken
[06:25] <mdz> what we need is ELMO
[06:25] <cartman> mdz: or that yes
[06:25] <Kamion> I pondered calling rescue-mode rescue-shell actually, can't remember why I picked rescue-mode
[06:25] <cartman> but looks l
[06:25] <cartman> like library version is updated
[06:26] <mdz> cartman: the library version was updated, but not the package name
[06:26] <cartman> mdz: I see. my system sounds will be borked for some time :/
[06:26] <mdz> that package was inadvertently uploaded by the moron maintainer
[06:26] <mdz> followed shortly by a fixed version
[06:27] <mdz> which has been helpfully sitting in Debian queue/new for 2 days
[06:27] <cartman> guess archieve is not yet updated?
[06:28] <mdz> Kamion: what does the .isinstallable bit do?
[06:28] <mdz> cartman: it's waiting in queue/new
[06:28] <cartman> mdz: ok, thanks
[06:28] <Kamion> mdz: helps out monolithic images
[06:28] <mdz> Kamion: should I have one?
[06:28] <Kamion> mdz: in normal images, rescue-mode won't even be installed; in monolithic images you can't stop it being installed because it's in the initrd, but the .isinstallable file stops it doing anything
[06:29] <Kamion> mdz: yeah, I'd recommend similar structure
[06:29] <Kamion> it's cheap and you'll appreciate it later :)
[06:30] <mdz> ok, I've cloned rescue-check onto casper
[06:31] <mdz> now what?
[06:31] <Kamion> put casper-check in the cdrom-live initrd
[06:31] <Kamion> put casper-<whatever> on your CD and in the Packages file
[06:31] <Kamion> make sure 'anna-install casper-<whatever>' is in casper-check's debian-installer-startup.d
[06:31] <mdz> so at this point I need to endure debian-cd
[06:32] <Kamion> marvel as it automatically pulls in casper-<whatever>
[06:32] <mdz> [ "$RET" = true ]  && anna-install casper-udeb
[06:32] <Kamion> oh, and include appropriate debconf variable setting in your bootloader config
[06:32] <mdz> Kamion: how should we go about getting the big filesystem blob onto the CD?
[06:32] <Kamion> mdz: personally I just take an existing CD and hack it ...
[06:33] <mdz> Kamion: I mean on an automated basis
[06:33] <Kamion> 17:31 < mdz> so at this point I need to endure debian-cd
[06:33] <Kamion> I was replying to that, order aside
[06:33] <Kamion> mdz: give me a place to pull the blob from and a location on the CD to put it, and I can make debian-cd copy it in
[06:33] <mdz> Kamion: casper is currently at menu-item: 22
[06:34] <Kamion> somewhere on the LAN would be good
[06:34] <mdz> is that still OK?
[06:34] <mdz> Kamion: the blob is inside the .iso on rookery, if you have loop-mount capability
[06:34] <Kamion> won't work with netboot
[06:34] <Kamion> I can't loop-mount stuff on little
[06:35] <Kamion> mdz: don't you want disk detection?
[06:35] <mdz> I don't know how to get it to you without uploading a 500M file
[06:35] <mdz> Kamion: detection, yes
[06:35] <Kamion> presumably it'll be built on the LAN soon enough
[06:35] <mdz> but I seem to get that already for free, from hotplug
[06:35] <Kamion> disk detection runs at 35
[06:35] <Kamion> hmm, not on all macs as yet
[06:35] <mdz> ok
[06:35] <mdz> just tell me what number I ought to use
[06:35] <mdz> and I'll change it
[06:35] <Kamion> I'd use 40 I think
[06:36] <Kamion> if you need to disable questions, I'd be inclined to make casper-check set whatever debconf questions are needed to make the questions go away
[06:36] <mdz> the only one that has been a problem so far is the hostname
[06:37] <mdz> the behaviour I want is that if it gets a hostname from dhcp, great, use it without questions, otherwise, use a default without questions
[06:37] <Kamion> ok, sec
[06:38] <mdz> perhaps lamont will have a new blob ready soon, and you can use that rather than me trying to upload mine
[06:38] <mdz> though, with a little rsync magic I could make it fast to upload
[06:39] <mdz> I need to work out how to test these changes now, though
[06:40] <Kamion> perhaps: db_fset netcfg/dhcp_options seen true; db_set netcfg/get_hostname some-default-hostname; db_fset netcfg/get_hostname seen true
[06:40] <mdz> get_hostname won't already be populated with a default?
[06:40] <mdz> disk detection won't ask any questions at default priority, right?
[06:40] <Kamion> yeah, it will, 'ubuntu', so leave that bit out
[06:40] <mdz> I'll do a test here with the new setup, and then see about questions
[06:40] <mdz> I think I need to walk through this in my head
[06:41] <Kamion> disk detection> nope
[06:41] <mdz> when does debian-installer-startup.d run?
[06:41] <Kamion> it's equivalent to rcS
[06:41] <mdz> ok, so casper-check runs
[06:41] <Kamion> the flow is init -> debian-installer-startup.d -> for (;;) { debian-installer.d }
[06:41] <mdz> it gets a value from debconf, which should be preseeded from the command line or a file
[06:42] <Kamion> default to false
[06:42] <mdz> yes, though that makes my testing more difficult
[06:42] <mdz> if set, it anna-installs casper-udeb and its deps
[06:42] <Kamion> default to true for testing purposes is fine too :)
[06:42] <Kamion> (anna-install automatically follows deps)
[06:42] <mdz> right
[06:43] <Kamion> anna-install won't take effect immediately, it queues until anna runs
[06:43] <mdz> will there be more udebs installed by the time casper runs, than there would have been before?
[06:43] <mdz> or are the new ones mostly after casper in order?
[06:43] <mdz> s/installed/run/ I suppose
[06:44] <Kamion> hw-detect-full is not generally in the initrd, for example
[06:44] <mdz> casper has this gross hack where it removes some of the bits from prebaseconfig.d and base-installer.d, and then does run-parts on them
[06:44] <Kamion> and it would (in my theory) run before casper
[06:44] <Kamion> I think you should present the live CD with a custom Packages file that does not include partman, base-installer, prebaseconfig, etc.
[06:44] <mdz> so if there is any other stuff that I need to remove there, I can make those changes now
[06:45] <mdz> (if you know of any off the top of your head)
[06:45] <Kamion> are you currently installing base-installer and prebaseconfig
[06:45] <Kamion> ?
[06:45] <mdz> I am not
[06:45] <mdz> (in the monolithic config)
[06:45] <Kamion> ok, good
[06:46] <mdz> but ideally, casper ought to cope
[06:46] <mdz> to allow for a combo live/install DVD
[06:46] <Kamion> yeah, I've been pondering that
[06:46] <mdz> basically, anything after casper never gets a chance, if it runs
[06:46] <Kamion> we could always have another tree of Packages files analogous to dists/hoary/main/debian-installer/
[06:46] <Kamion> and use that instead
[06:46] <mdz> because everything running on the initrd gets killed
[06:47] <Kamion> the "debian-installer" bit there is hardcoded in the various *-retriever packages
[06:47] <Kamion> it could be made customisable, and then a combo DVD would be easy
[06:48] <mdz> alternatively, we could preseed hints to modify the "standard" selection
[06:48] <Kamion> of course, that would be hard for netboot without archive cooperation
[06:48] <Kamion> or require a particular OK-For-Live-CD: field
[06:48] <mdz> what's my next step to test this out?
[06:49] <Kamion> run with a custom Packages file with just the bits you need, IMO
[06:49] <mdz> so pull down a hoary daily install CD
[06:49] <Kamion> that approach is good enough for a first release
[06:49] <mdz> add casper-udeb and casper-check to it
[06:49] <mdz> mangle the Packages file
[06:49] <mdz> copy the live fs in
[06:49] <mdz> re-mkisofs
[06:49] <Kamion> update Packages.gz and Release
[06:49] <Kamion> you'll have to add casper-check to the initrd on the CD
[06:49] <Kamion> (or copy in a completely new initrd)
[06:50] <Kamion> make sure casper-udeb is Priority: standard
[06:50] <Kamion> >=
[06:50] <Kamion> actually, no, forget that last
[06:50] <Kamion> (I'm stupid)
[06:50] <mdz> ETA 40 minutes for a CD download
[06:51] <Kamion> if nothing after casper gets a chance to run, of course, removing later stuff from the Packages file is not important
[06:51] <mdz> casper-check standard, casper-udeb optional, is what I have now
[06:51] <Kamion> ok, good
[06:51] <mdz> tihs is starting to sound very painful for iterative testing
[06:51] <Kamion> rescue works that way, you can include it on a standard image completely safely
[06:51] <mdz> hopefully casper-check won't be buggy :-)
[06:51] <mdz> do you have a script to sync up the Packages/Release stuff?
[06:52] <Kamion> this approach is basically how I test d-i changes, you get into the habit of it
[06:52] <Kamion> finger macros :)
[06:52] <Kamion> sudo sh -c 'gzip -c Packages' > Packages.gz; cd ../..; apt-ftparchive release .; copy changes into Release
[06:52] <Kamion> I should come up with an apt-ftparchive line that matches what debian-cd spits out
[06:53] <Kamion> mdz: if you can make netboot work ...
[06:53] <Kamion> this is one reason I'm suggesting generic d-i-like approaches, they take a little longer but adapting them to netboot etc. should be trivial
[06:54] <Kamion> or even USB boot
[06:55] <ogra> mdz: x configuration on your live cd is very weird....dpkg-reconfigure defaulted to ati (on a toshiba laptop with trident card which i selected then) and wrote a xorg.conf with nvidia in it....
[06:56] <ogra> mdz: oh, no, stop...it didnt even touch the xorg.conf it seems.... hmm
[07:00] <fabbione> mdz: ok. i am quite busy now.. mind to do the honours?
[07:00] <fabbione> lamont: sorry.. i lost my scrollback..
[07:00] <fabbione> lamont: did you enable the pkgstriptranslation on the buildd?
[07:04] <fabbione> lamont: please msg me about it... i have logs enabled this time :-)
[07:05] <pitti> fabbione: I think he installed pkgstriptranslations, but did not activated it by now
[07:06] <lamont> pitti: installed, enabled, disabled, waiting for someone to decide that they really, really, really want it enabled
[07:07] <Kamion> hmm, kickstart has an 'auth --enablecache' command which enables nscd, but we don't support that
[07:07] <Kamion> what's the right answer? support nscd? bomb out?
[07:07] <pitti> mdz, lamont: personally I can live with fading translations for a while, but I think mdz should have the final word about it
[07:08] <pitti> mdz, lamont: OTOH waiting for another week does not make much of a difference
[07:09] <mdz> ogra: it has an nvidia xorg.conf on it, from amu's system I think
[07:09] <mdz> fabbione: ok
[07:10] <ogra> mdz: unfortunately its handeditet, so dpkg-reconfigure wont touch it anymore.....that makes X useless on this cd unless you know about the md5sum thing
[07:10] <mdz> Kamion: should we give the user broken crap if they ask for it?
[07:10] <mdz> ogra: ah
[07:11] <Kamion> mdz: kickstart also supports NIS, LDAP, hesiod; if you're using any of those I can see why you might want to use nscd
[07:12] <mdz> Kamion: yeah, because you're already out of your mind
[07:13] <Kamion> :-)
[07:13] <Kamion> or you're a sysadmin with existing machines to support that are already configured
[07:13] <Kamion> and you want to integrate Ubuntu with that setup
[07:14] <Kamion> this is the kickstart target market, remember ...
[07:15] <mdz> Kamion: did you get this?
[07:15] <mdz> Jan 05 12:43:51 <mdz>   Kamion: is there an easy way to skip the first CD scan? I'm curious as to whether it is actually pessimizing things
[07:15] <Kamion> mdz: comment it out in /var/lib/dpkg/info/cdrom-detect.postinst before it runs
[07:15] <trukulo> anyone using pbuilder on ubuntu?
[07:15] <trukulo> sorry
[07:15] <trukulo> think i was on #ubuntu
[07:17] <mdz> Kamion: what do you think is a reasonable spot on the CD to keep the cloop image?
[07:17] <mdz> perhaps /casper/filesystem.cloop
[07:20] <Kamion> fine by me
[07:22] <kent> Since Ubuntu is changing to UTF in Hoary, and the weather applet seems to have problems with that in Hoary (http://leviatan.kicks-ass.org/dump.png), should i report it as a bug?
[07:22] <lamont> rm: cannot remove directory `chroot-test/tmp/dir.zVOlMH': Device or resource busy
[07:23] <mdz> kent: yes
[07:24] <mdz> lamont: once you have the ext2 image, you'll want to install cloop-utils and use create_compressed_fs <file> 65536 > <file>.cloop
[07:24] <seb128> kent: don't forget to provide details on your environment, the applet works fine here with utf-8
[07:24] <mdz> as always :-)
[07:25] <seb128> kent: ie, output of "locales", /etc/environment, what locale is picked in gdm, etc
[07:25] <seb128> locale even
[07:25] <lamont> mdz: yeah
[07:27] <kent> seb128, will do that. I have to study tonight, so il take the time to write a report tomorrow. It might be my fault, but i think i followed the information about how to upgrade to Hoary step by step, so perhaps its a bug..  i fill know tomorow then.
[07:32] <kent> seb128, the locale picked up by gdm,  is it the one in $LANG ?  gedit and other programs default to UTF when i save files, and $LANG is set to utf when i check in gnome-terminal. And locale, /etc/environment is also set to utf.
[07:32] <mdz> yay pitti
[07:33] <mdz> Kamion: what's the magic mkisofs command I need?
[07:35] <seb128> kent: if you alt-F2 and "locale | zenity --text-info" here
[07:35] <seb128> what is the locale ?
[07:37] <seb128> kent: hum ok, you're right. There is a problem with the locations, but the rest of the string is fine. Please file a bug, just put the screenshot in it, that's fine 
[07:37] <seb128> time to dinner now, bbl
[07:42] <mdz> Kamion: and do I need to fudge Release.gpg or no?
[07:46] <pitti> mdz: live cd boots fine for me
[07:46] <pitti> mdz: is "FATAL: Module This not found." a known bug?
[07:46] <mdz> Kamion: mkisofs -r -V 'Ubuntu 4.10 i386 Bin-1' -o warty-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table <dir>
[07:46] <mdz> Kamion: is what I found in scrollback, hope that's right
[07:46] <pitti> mdz: I chose German locale in the installer, still I have POSIX
[07:46] <mdz> pitti: yeah, it's a powernowd bug I believe
[07:46] <mdz> pitti: ok, good to know.  I think I need to do some manual work to carry that over
[07:46] <pitti> mdz: this "This" modules sounds like a parsing bug of /etc/modules
[07:47] <mdz> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=5138
[07:48] <mdz> it's already fixed; the snapshot is a week old
[07:48] <lamont> sigh.  how do I force debconf to go non-interactive?
[07:48] <sivang> life cd :)
[07:48] <sivang> anybody know if there are the d-i po files already in rosetta?
[07:49] <pitti> mdz: but I did not investigate this
[07:49] <pitti> fine
[07:49] <pitti> mdz: dpkg-reconfigure -plow xserver-xorg does not ask me for resolutions, but I guess it's a bit too early for X stuff :-)
[07:51] <pitti> lamont: DEBIAN_FRONTEND=noninteractive?
[07:53] <ogra> pitti: woah, i'm trying it since 1/2 hr
[07:53] <pitti> mdz: do you have an idea why there is no /dev/input/mice on the life cd?
[07:53] <mdz> pitti: yes, after copying in a working xorg.conf from my hard drive, it works quite nicely
[07:53] <mdz> pitti: no, I don't, I would be forever grateful if you would inventigate
[07:53] <mdz> it appears if you unload and reload mousedev
[07:53] <pitti> mdz: usbhid is loaded and found my mouse
[07:54] <pitti> yeah, now it's here
[07:54] <pitti> cool, X with mouse and ubuntu desktop
[07:55] <mdz> pitti: can you try to find out why it doesn't appear initially?
[07:55] <mdz> mousedev is loaded via /etc/modules in the normal way
[07:55] <pitti> mdz: I try
[07:56] <mdz> I don't see why it should not appear until the second time it is loaded
[07:56] <pitti> mdz: btw, my usb stick does nothing either
[07:56] <pitti> mdz: maybe a general USB problem
[07:56] <lamont> hrm.. there are some things that are done at install time that we really want to defer until boot time for the livecd...
[07:56] <pitti> mdz: the lamp on it is not even enabled
[07:57] <ogra> yay, got it !!#
[07:58] <ogra> pitti, does your panel work ? its absolutely unresponsive here
[07:59] <pitti> mdz, ogra: well, sort of
[07:59] <pitti> mdz, ogra: I just tried to shutdown, clicked okay in the idalog, now everything hangs
[07:59] <pitti> no, just the panel is hanging
[07:59] <ogra> at least your menu responses
[07:59] <ogra> i cant even open it :)
[08:00] <mdz> pitti: odd, shutdown worked perfectly for me
[08:00] <pitti> I reboot now to investigate the mouse and other issues
[08:00] <pitti> but before I need some dinner, cya later
[08:03] <ogra> heh, the nautilus tree view has 72px folder icons....funny
[08:03] <amu> mdz: what's about sound? works also  
[08:04] <amu> +?
[08:04] <mdz> amu: I haven't tested yet
[08:04] <mdz> amu: I am building a new non-monolithic CD image to test
[08:05] <ogra> doesnt work here :(
[08:06] <amu> mdz: downloaded just your iso, it's different than mine? 
[08:06] <mdz> amu: yes, entirely different except for the /live-fs
[08:06] <mdz> you should be able to rsync it against yours and save a lot of download, since the live-fs is large
[08:07] <amu> ogra: with my i810x sound works also 
[08:07] <ogra> hah, with /etc/init.d/gdm start my panel works, with startx it doesnt
[08:07] <ogra> amu: i'm looking at it now...
[08:08] <ogra> ARGH !
[08:09] <mdz> ogra: then use gdm :-)
[08:09] <mdz> that's what the final version will do
[08:09] <ogra> please please please blacklist snd_intel810m by default !
[08:09] <ogra> thats blocking my sound devices....again
[08:10] <mdz> ogra: did you add your comments to the bug?
[08:10] <sladen> mjg59: http://function.linuxpower.ca/patches/patch-netconsole ; would if it'd be worth modifying this and providing a central server to capture the panic.  When a users machine dies repeated, they can be told 'type this and enter a user-id, the next time your machine crashes, goto  panic.ubuntu.com/user-id  and the trace will be there
[08:10] <amu> mdz: sound should be initalized by hotplug? atm it's done by the old alsa-autoconfig  
[08:11] <mdz> amu: on my CD it is done by hotplug and alsa-base
[08:11] <amu> mdz: which soundcard? 
[08:11] <mdz> i810
[08:11] <ogra> i8x0
[08:11] <ogra> sorry
[08:11] <mdz> amu: your filesystem has saved mixer settings for a different sound card
[08:11] <ogra> -> m
[08:11] <mdz> so the init script prints an error
[08:13] <ogra> hmm, and you should delete bash.history ;)
[08:13] <mdz> ogra: lamont is working on autobuilding new images
[08:13] <mdz> elmo lives
[08:14] <mdz> whoa
[08:14] <mdz> Kamion: what prints "E: Unimplemented function"
[08:14] <mdz> Kamion: (context: d-i initrd)
[08:16] <mdz> seems to be in libdebconf
[08:16] <cartman> mdz: any idea when will new flac packs will make it to archieve?
[08:16] <mdz> cartman: no
[08:16] <cartman> mdz: ok
[08:17] <mdz> I sent email via bugzilla to elmo
[08:17] <Kamion> mdz: that mkisofs command is fine; no, you don't need to fudge Release.gpg (yet)
[08:17] <cartman> mdz: ok
[08:18] <mdz> Kamion: I uncompressed and loop-mounted the initrd, udpkg --unpack'd casper-check onto it, recompressed it and booted it in qemu
[08:18] <Kamion> mdz: yes, sounds like _confmodule_process() returned NULL
[08:18] <mdz> and all hell broke loose
[08:18] <Kamion> maybe the status file is screwed?
[08:19] <mdz> it seems to be during casper-udeb.postinst
[08:19] <mdz> the only change I made to it was to add: 
[08:19] <mdz> . /usr/share/debconf/confmodule
[08:19] <mdz> # Be nice to monolithic users.
[08:19] <mdz> db_get casper/enable
[08:19] <mdz> [ "$RET" = true ]  || exit 0
[08:19] <mdz> at the top
[08:20] <mdz> wait, hmm
[08:20] <Kamion> did the .templates file get unpacked?
[08:20] <mdz> it seems to be running much earlier than it should be
[08:20] <mdz> hmm, no it didn't
[08:21] <mdz> does udpkg --unpack not do that?
[08:21] <Kamion> note that all /var/lib/dpkg/info/*.templates get removed early on in the boot process, to save memory; they get merged into /var/lib/cdebconf/templates.dat
[08:21] <Kamion> the d-i initrd build process uses dpkg --unpack rather than udpkg ...
[08:21] <mdz> I loop-mounted the initrd and it is not there
[08:22] <mdz> Kamion: dpkg --root=/mnt ?
[08:22] <mdz> hmm, no, that does'nt work
[08:22] <mdz> dpkg: cannot scan updates directory `/mnt/var/lib/dpkg/updates/': No such file or directory
[08:22] <Kamion> dpkg --force-overwrite --root=/mnt --unpack $udeb
[08:22] <Kamion> you have to mkdir /var/lib/dpkg/updates and touch /var/lib/dpkg/available first
[08:22] <Kamion>         # Only dpkg needs this stuff, so it can be removed later.
[08:22] <Kamion>         mkdir -p $(DPKGDIR)/updates/
[08:22] <Kamion>         touch $(DPKGDIR)/available
[08:22] <mdz> guh
[08:23] <Kamion> any reason you aren't just rebuilding the initrd?
[08:24] <mdz> because I was waiting on you to do the wrangling :-)
[08:24] <Kamion> udpkg calls debconf-loadtemplate directly rather than unpacking the .templates into /var/lib/dpkg/info
[08:24] <mdz> though I suppose all that's needed now is to add casper-check to cdrom?
[08:24] <Kamion> I don't have mail from you; am I supposed to have?
[08:24] <mdz> you were supposed to have, but it's obsolete now
[08:24] <mdz> since I've reworked casper to use -check and such
[08:25] <mdz> it's still fucked
[08:25] <Kamion> (hm, should I update the installer to 2.6.10 now?)
[08:25] <mdz> yes
[08:25] <mdz> let me take a screenshot of this
[08:25] <mdz> and maybe you can tell what is going on
[08:27] <mdz> seb128: is it expected that gnome-panel-screenshot --window --delay=N does not work?
[08:28] <mdz> Kamion: http://dijkstra.csh.rit.edu/~mdz/temp/boom.png
[08:29] <mdz> Kamion: that happens immediately after "Waiting for /dev/fb/0 to appear" or whatever
[08:29] <seb128> mdz: hum, the --delay= seems to be broken :/
[08:29] <seb128> mdz: but you have a keybinding to capture the current window
[08:29] <mdz> seb128: oh, what is it?
[08:29] <mdz> by default
[08:29] <seb128> yep
[08:29] <mdz> ah, shift+print
[08:29] <seb128> should be that
[08:30] <Kamion> guh, that looks very broken
[08:30] <seb128> I was looking for it, I've changed mine
[08:30] <mdz> Kamion: it's as if something is running twice which shouldn't be
[08:30] <Kamion> why should mounting sysfs fail?
[08:30] <Kamion> can you put the initrd somewhere?
[08:30] <mdz> it's like debian-installer-startup.d is restarting
[08:30] <mdz> it already mounted it once
[08:30] <mdz> and loaded the acpi modules
[08:30] <mdz> yes
[08:31] <ogra> mdz: any reason why i got a fam running ?
[08:31] <crimsun> pitti: great news! thanks. :)
[08:31] <mdz> Kamion: http://dijkstra.csh.rit.edu/~mdz/temp/initrd.gz
[08:31] <mdz> Kamion: will take a few minutes to upload
[08:33] <cartman> anyone is able enter unicode text and delete them properly using backspace at login prompt?
[08:34] <cartman> here entering works but can't delete them
[08:34] <crimsun> cartman: using bash?
[08:34] <mdz> Kamion: initrd is up
[08:34] <cartman> crimsun: tty console login
[08:34] <crimsun> cartman: there are reports of certain other shells not working properly with it, like zsh.
[08:34] <mdz> cartman: works fine with bash, known buggy with zsh
[08:34] <cartman> mdz, crimsun I am talking about initial login prompt at tty1
[08:35] <Kamion> try 'unicode_start'
[08:35] <cartman> Kamion: in an init script?
[08:35] <cartman> - :)
[08:35] <Kamion> no at the command line
[08:35] <Kamion> experimentally
[08:36] <cartman> hmm but  when I login I can use unicode fine
[08:36] <cartman> and delete them
[08:37] <Kamion> mdz: uh. are you sure that's the right initrd?
[08:37] <Kamion> there is no /sbin/debian-installer-startup there
[08:37] <Kamion> oh, never mind, PEBKAC
[08:38] <Kamion> ah, I see
[08:38] <Kamion> mdz: make S60casper-check executable
[08:39] <Kamion> mdz: non-executable files in debian-installer-startup.d are sourced, and that makes very bad things happen when /usr/share/debconf/confmodule is sourced and re-execs the whole thing
[08:39] <mdz> guh
[08:39] <Kamion> executable files in debian-installer-startup.d are executed instead
[08:39] <mdz> it would make me so much happier if it did the same thing as init
[08:39] <mdz> .sh rather than non-exec
[08:40] <mxpxpod> jdub: ping
[08:40] <Kamion> that would work too, could try for that upstream post-sarge
[08:40] <cartman> guess the bug is in /bin/login
[08:42] <mdz> Kamion: once I get this working, I'd like for you to eyeball casper before I upload it
[08:42] <Kamion> ok
[08:42] <Kamion> I'll be out this evening, expect to be back at least briefly in a few hours
[08:43] <mdz> when do you leave?
[08:44] <Kamion> about 15 minutes
[08:44] <kent> seb128, http://leviatan.kicks-ass.org/dump2.png   <- the output of the command you wrote.   
[08:44] <Kamion> I can phone ahead and be later if need be
[08:45] <seb128> kent: have you read what I said after ? :)
[08:45] <seb128> but thanks :)
[08:45] <mdz> Kamion: nah, don't let me delay you
[08:46] <kent> seb128, now i did, sorry about that :)  Should i edit the screendumps with gimp to make them smaller when i attach the picture? (cut out unneeded stuff?) 
[08:46] <seb128> kent: yeah, just the panel area with the string is fine
[08:48] <mdz> Kamion: is there an anna-remove?  that seems like it would be a nice way for casper to get rid of partman
[08:49] <mdz> hmm, doesn't seem to be
[08:51] <mdz> hmm, this is doomed to fail
[08:51] <mdz> no dmsetup-udeb on the CD
[08:51] <mdz> oh, yes there is
[08:53] <Kamion> no anna-remove
[08:53] <Kamion> surely just reboot after casper is done
[08:53] <Kamion> that's what rescue-mode does, works fine
[08:54] <mdz> Kamion: I mean avoiding unpacking it at all
[08:54] <mdz> it's a waste of time
[08:54] <Kamion> well, umount stuff and reboot
[08:54] <mdz> the shutdown process for casper is just a normal system shutdown :-)
[08:54] <mdz> by the time it's finished, d-i is gone
[08:54] <Kamion> it might be better to invent a way to tell anna not to install standard-priority packages
[08:55] <mdz> gah, need a newer busybox on this CD
[08:55] <mdz> I guess my busybox-cvs upload was too late for the daily CD
[08:55] <mdz> or else delayed by the build mess
[08:55] <Kamion> busybox-cvs uploads need new daily-installer-* which need BYHAND
[08:55] <mdz> probably rootskel, too, then
[08:55] <Kamion> could you file a bug on anna about the standard-priority thing and assign it to me?
[08:56] <mdz> those both need to go in the initrd, yes?
[08:56] <Kamion> yes
[08:56] <mdz> ok
[08:56] <Kamion> those two are totally foundational :)
[08:57] <Kamion> anna/manual_only or something, maybe
[09:06] <ogra_casper> mdz: is working suspend expected for this cd ?
[09:07] <ogra_casper> s/for/from/
[09:07] <amu> ogra_casper: i guess no, i've to implement this first :) with very very low prio  
[09:08] <ogra_casper> ah, k
[09:10] <amu> ogra_casper: if it works, that would be pure coincidence, or mdz is faster than light
[09:11] <ogra_casper> nope, doesnt work....
[09:12] <ogra_casper> and my panels+nautilus just dissapeared without any action from my side :-/
[09:13] <amu> ogra_casper: that's normal pannel fun ;) *runsaway* 
[09:13] <ogra_casper> oh....ps -ax input/output error.....
[09:13] <ogra_casper> hmm, suspend seems to work.....half way *g*
[09:14] <ogra_casper> my disk is absolutely sleeping....but funnily xchat still works from mem
[09:14] <abelli> ogra?
[09:14] <amu> ogra_casper: how much ram you have? 
[09:14] <abelli> amu: how is it?
[09:14] <ogra_casper> 384M
[09:15] <ogra_casper> its a laptop
[09:15] <amu> abelli: thx fine& happy new .... 
[09:15] <abelli> blah blah blah... 
[09:15] <abelli> thank you
[09:15] <ogra_casper> heh
[09:15] <amu> ogra_casper: any maschine with 64mb left? 
[09:15] <abelli> amu: is the live cd up ?
[09:16] <sivang> ogra_casper: what's that casper thing? :)
[09:16] <ogra_casper> nope, but i can set one up (not before the weekend...sorry)
[09:16] <amu> abelli: see u-devel, mdz announced last night, i woundert why you didnt tested it yet  
[09:16] <abelli> i wasnt in my home.. sorry
[09:16] <abelli> s/home/...
[09:16] <mdz> ogra_casper: I've no idea; did you try it?
[09:16] <ogra_casper> sivang: dunno, ask someone enlightened, xchat had casper_user in it....so i modified it
[09:17] <mdz> ogra_casper: I wouldn't expect to need to do any extra work to get that to happen
[09:17] <mdz> if the kernel bits work on your hardware, it should work
[09:17] <abelli> amu: wowowwoowww
[09:17] <ogra_casper> mdz: i tried it....but did only work half way it seems
[09:18] <ogra_casper> abelli: yep, it seems to get very fine.....for an alpha this is awsome..... (kudos to amu and mdz)
[09:19] <ogra_casper> abelli: (i'm using it currently)
[09:19] <abelli> im going to try it with the xbox's bios thing we're working on...
[09:20] <ogra_casper> amu: did you get X -configure sorted ?
[09:21] <amu> nope, takes too long time, daniels is working on a xconfig, make no sense if i wast too many hours with it. 
[09:21] <ogra_casper> i experienced a weird prob here....
[09:22] <ogra_casper> did you ever edit the xorg.conf in your chroot by hand ?
[09:22] <amu> yep
[09:22] <ogra_casper> so thats your prob then i guess
[09:22] <ogra_casper> (read the header of the xorg.conf)
[09:23] <amu> no, do you have one ? 
[09:23] <mdz> X -configure didn't seem to generate a working config for my laptop
[09:23] <ogra_casper> X -configure doesnt even write a file if the original doesnt match the md5sum
[09:24] <amu> ogra_casper: hehe, converted from XF86 ... 
[09:24] <pitti> mdz: do you have this mouse /dev/input/mice problem as well?
[09:24] <pitti> mdz: I spent some time debugging it, but somehow the whole USB system seems to be screwed up
[09:24] <ogra_casper> its written in the header of the file :)
[09:25] <ogra_casper> hal-device-manager seems broken
[09:25] <pitti> mdz: my net connection keeps failing this evening; did you get my question "<pitti> mdz: do you have this mouse /dev/input/mice problem as well?"
[09:25] <mdz> pitti: yes, I do
[09:25] <mdz> it is not specific to usb
[09:26] <pitti> mdz: I tried to stop hotplug and usb, unload all modules
[09:26] <mdz> mousedev itself should cause that module to appear
[09:26] <pitti> mdz: then started udev, module-init-tools and hotplug again
[09:26] <mdz> s/that module/that device node/
[09:26] <ogra> amu:  md5sum /etc/X11/xorg.conf >/var/lib/xfree86/xorg.conf.md5sum
[09:26] <pitti> however, after this my mouse was not recognized at all any more
[09:26] <mdz> ogra_casper: X -configure writes a file for me
[09:26] <mdz> it just isn't a very good one
[09:27] <ogra_casper> mdz: where does it write it ?
[09:27] <mdz> /root/xorg.conf
[09:27] <mdz> as it says in the output
[09:27] <ogra_casper> mdz: ah, ok
[09:27] <mdz> /root/xorg.conf.new tha tis
[09:27] <ogra_casper> yup
[09:28] <pitti> mdz: since I cannot restart the system I cannot play around with different /etc/modules versions :-(
[09:28] <mdz> pitti: what do you mean?
[09:28] <pitti> mdz: I suspected that usbhid must be loaded before mousedev, but actually this _should_ not be necessary
[09:28] <mdz> no, usbhid is not necessary at all
[09:28] <pitti> mdz: for me it is
[09:28] <pitti> without usbhid I don't have a mouse
[09:29] <pitti> however, it should not matter with /dev/input/mice, right
[09:35] <lamont> mdz: actually, it's starting to look like just giving you lib/modules is going to be the easier route.
[09:37] <lamont> mdz: how do you feel about doing dpkg --configure -a after mounting /?
[09:37] <ogra> hmm.... * cannot execute "/sbin/shutdown"
[09:39] <mdz> lamont: er, what?
[09:40] <mdz> pitti: oh, I confused usbhid and usbkbd/usbmouse
[09:40] <mdz> pitti: anyway, I am using psmouse
[09:41] <mdz> usbhid should not be necessary to get /dev/input/mice
[09:41] <mdz> it should appear as soon as mousedev is loaded
[09:41] <mdz> even though there are no mice
[09:41] <mdz> and that is not happening for some reason
[09:41] <mdz> ogra: you have fam because it was in amu's image for some reason :-)
[09:41] <lamont> mdz: turns out I appear to be stuck installing udev (which likes to mount things at install time, etc...
[09:41] <pitti> mdz: hmm, drivers/input/mousedev.c creates the sysfs device unconditionally
[09:41] <pitti> mdz: is it possible that udev does not yet run properly at the time mousedev is loaded?
[09:41] <mdz> lamont: we might need to subvert it, then
[09:42] <lamont> but actually installing the kernel seems to leave root/dev busy, etc.  and needs /proc mounted, and, and...
[09:42] <pitti> mdz: right, so says the source
[09:42] <pitti> mdz: however, the module creates the sysfs entry, so maybe this is an udev race
[09:42] <mdz> lamont: in fact, I recommend you don't run any init scripts at all
[09:42] <mdz> lamont: put in a dummy invoke-rc.d or whatever
[09:42] <lamont> makes sense
[09:43] <mdz> lamont: I don't think you'll be able to avoid mounting /proc, though. mkinitrd will need it
[09:44] <lamont> why do I need to run mkinitrd in my filesystem?
[09:44] <mdz> lamont: if you can avoid it, great, but generally the kernel postinst will run it
[09:45] <lamont> figured I'd just unpack the kernel, and leave it at that... thoughts?
[09:45] <mdz> I don't like that, because it'll cause problems when you try to install packages later
[09:45] <mdz> if you want to fake mkinitrd, fine
[09:45] <mdz> but all packages should be fully installed
[09:45] <lamont> do you want the real mkinitrd on the final filesystem?
[09:45] <mdz> mv mkinitrd mkinitrd.real; ln -s true mkinitrd; etc.
[09:46] <mdz> yes
[09:46] <lamont> right.
[09:46] <mdz> any hackery like that (invoke-rc.d, mkinitrd) needs to be undone for the final image
[09:46] <lamont> more inclined to dpkg-divert it during the install then.
[09:46] <mdz> basically the same way debootstrap works, with start-stop-daemon etc.
[09:46] <mdz> fine by me
[09:46] <mdz> if everything you need to divert is installed by debootstrap, that should work fine
[09:47] <mdz> if you need to tweak something installed with the desktop, that's tricker
[09:47] <mdz> trickier
[09:58] <mdz> lamont: does console-tools end up in your image?
[10:02] <pitti> fabbione: here?
[10:03] <lamont> mdz: yes
[10:03] <lamont> == base
[10:04] <mdz> for some reason, localechooser tries to install it
[10:04] <mdz> lamont: also console-data and console-common?
[10:04] <lamont> right between bzip2 and cpio
[10:04] <lamont> :-)  that's a yes
[10:14] <opi> anyone can tell me more about Rosetta status?
[10:14] <opi> some polish user ask me why we double gnome.pl effort in translation
[10:15] <lamont> mdz: how close are you to wanting this image?
[10:16] <mdz> lamont: it's not blocking me, but it's on the critical path
[10:16] <lamont> right.
[10:16] <lamont> it's ahead of merges today
[10:16] <mdz> opi: you can ask on #rosetta
[10:16] <opi> mdz: ok
[10:17] <opi> mdz: because some translations are mostly ready, so we're wasting time on things that are already here
[10:18] <lamont> opi: if the translations are available somewhere, I would hope that rosetta would just import them
[10:18] <opi> lamont: yeah, I hope that, too
[10:18] <lamont> brb
[10:18] <opi> lamont: I wasn't Gnome guy before Ubuntu, so I wasn't aware of Gnome.pl efforts
[10:19] <mvo__> hmmm ... the live-cd hangs here with "/dev/vc/1" does not exist
[10:24] <mdz> lamont: the fact that the current image has a half-installed kernel on it is causing problems
[10:25] <mdz> lamont: so sooner rather than later
[10:26] <mdz> seb128: how much work would it be to create a small GNOME applet with a progress bar in it?
[10:26] <azeem> progress bars are patented in Europe
[10:27] <seb128> mdz: really easy to do
[10:27] <mdz> seb128: is there some example code I could steal?
[10:27] <opi> seb128: I'll attach /var/log in regards of #5147 bug
[10:27] <mdz> preferably in python if that's possible
[10:28] <opi> mdz: seen it somewhere in Pythong/GTK related examples
[10:28] <seb128> yeah
[10:28] <seb128> a sec
[10:29] <seb128> opi: /var/log/XFree86.0.log
[10:29] <opi> seb128: ok, I need to leave office first ;)
[10:29] <seb128> mdz: /usr/lib/python2.3/site-packages/gtk-2.0/gnome/applet.py
[10:29] <seb128> hum nop
[10:29] <seb128> mdz: /usr/share/doc/python2.3-gnome2-extras/examples/applet/applet.py
[10:30] <mdz> in which package?
[10:30] <seb128> mdz: you have just a label here, but changing it for a progress bar would be easy
[10:30] <mdz> oh, python2.x-gnome2-extras
[10:30] <seb128> yep
[10:31] <seb128> the instructions are in the README in the dir
[10:31] <pitti> daniels: ping
[10:31] <mdz> whoa, that is easy
[10:31] <seb128> yep
[10:31] <seb128> pygtk rocks :)
[10:32] <two-face> hi
[10:32] <seb128> hey two-face 
[10:32] <two-face> hello seb128 
[10:32] <mdz> what is the 3rd argument to bonobo_factory?
[10:32] <mdz> ("hello")
[10:33] <two-face> i guess i'll find people using tla in here :)
[10:33] <mdz> what I want to do is create an applet which will poll a file containing some numbers, and display them as a progress bar
[10:33] <mdz> so it needs to refresh periodically
[10:33] <seb128> the description
[10:34] <pitti> two-face: close, baz :-) But I still know tla
[10:34] <mdz> do I need to run a thread?
[10:34] <seb128> mdz: perhaps you can read that http://www.pygtk.org/articles/applets_arturogf/
[10:34] <mdz> ok, thanks
[10:34] <seb128> http://www.pygtk.org/articles/applets_arturogf/x134.html 
[10:34] <seb128> 5.3. Optional timeout callback method
[10:34] <seb128> for the update
[10:34] <seb128> with a timeout
[10:34] <seb128> no need to thread
[10:35] <two-face> pitti: with what key do you sing your archive?
[10:35] <two-face> pitti: sign :)
[10:35] <pitti> two-face: ? my normal GPG key?
[10:35] <pitti> two-face: however, usually I don't sign my own archives
[10:35] <pitti> I should probably, though
[10:36] <two-face> pitti: i'm pondering generating a dedicated key signed by my main gpg key
[10:36] <two-face> pitti: i don't know if it's worth it
[10:36] <pitti> two-face: what should be the benefit of this?
[10:37] <two-face> pitti: for instance, avoiding having one main key on one's laptop
[10:37] <pitti> two-face: I already have three subkeys for my different roles (Debian, Ubuntu, private), I don't need any more
[10:37] <pitti> two-face: however, it might be worth having some project-specific keys
[10:37] <two-face> pitti: ha, subeys
[10:37] <two-face> subkeys
[10:38] <two-face> pitti: it might be what i need
[10:38] <pitti> two-face: I don't have any GPG key on my laptop
[10:39] <pitti> two-face: if I need it, I ssh on my server
[10:40] <two-face> pitti: ok, I guess I can easily find docs on subkeys in the web
[10:40] <pitti> two-face: well, I don't know whether subkeys is right
[10:40] <pitti> two-face: in fact I think it's wrong
[10:40] <pitti> two-face: I have different IDs
[10:40] <pitti> but it's actually the same key
[10:40] <two-face> ah?
[10:41] <two-face> Ho different is it?
[10:41] <two-face> How
[10:41] <pitti> no idea
[10:42] <two-face> hmm
[10:42] <lamont> dbus. postinst. must. change.
[10:42] <two-face> pitti: but how did you generate them, then?
[10:43] <pitti> two-face: the different IDs?
[10:44] <two-face> pitti: yep
[10:44] <pitti> two-face: gpg --edit <key>
[10:44] <pitti> adduid
[10:44] <two-face> ah, ok, I see
[10:44] <pitti> tehre is also "addkey", this might be the one for subkeys
[10:45] <two-face> pew
[10:45] <two-face> I need to spend some time reading docs
[10:45] <two-face> in the meantine I won't sign at all
[10:47] <two-face> pitti: thanks
[10:47] <pitti> no problem
[10:48] <two-face> still maintaing postgresql?
[10:48] <pitti> yes
[10:48] <pitti> I spend 95% of my Debian time on it... :-/
[10:48] <two-face> heh
[10:48] <two-face> i think it is worth it
[10:48] <pitti> after every upload (that ususally closes 10 bugs) I think "yes, that's the Sarge version"
[10:48] <pitti> and after this I get 5 new bugs...
[10:49] <pitti> yes, me too
[10:49] <pitti> it is fun
[10:49] <two-face> :-P
[10:49] <pitti> most of the time
[10:49] <two-face> it is fun because it is an interesting piece of soft
[10:49] <pitti> two-face: indeed
[10:49] <pitti> two-face: the only problem is that the original packaging was totally screwed up
[10:49] <two-face> oh, does it feature redundancy?
[10:50] <pitti> two-face: what do you mean by that?
[10:50] <two-face> database redundancy between servers
[10:50] <pitti> two-face: ah, replication?
[10:50] <pitti> two-face: not right now
[10:50] <two-face> pitti: yep
[10:50] <lamont> must run to get kids. back about 1630 MST
[10:50] <pitti> somebody should find the time to package slony-1
[10:50] <two-face> pitti: which is?
[10:51] <pitti> two-face: this is the replication system of choice currently
[10:51] <two-face> ah
[10:51] <two-face> nifty
[10:51] <pitti> two-face: however, I spent my current time in stabilizing postgresql proper
[10:51] <pitti> so I did not find any time for it
[10:51] <two-face> two-face: i see
[10:51] <pitti> two-face: I also have to work on the complete repackaging of PostgreSQL 8
[10:52] <two-face> pitti: good
[10:52] <pitti> two-face: brb, I test my new -hardened kernel :-)
[10:52] <two-face> with oliver?
[10:52] <pitti> off to reboot
[10:52] <pitti> two-face: yes
[10:52] <two-face> ok
[10:59] <jinty> Is there someone who can go and kick debpartial-mirror?
[10:59] <jinty> It is currently uninstallable because of a dependency on python 2.3
[10:59] <gsuveg> re
[10:59] <jinty> whcih a simple re-build without changes should fix.
[11:00] <mvo__> jinty: I can take a look
[11:00] <jinty> In fact I have done so and tested on my local machine.
[11:00] <pitti> two-face: back
[11:01] <jinty> Thanks muchly
[11:02] <two-face> pitti: are you hardened? :)
[11:02] <pitti> two-face: I am hardened all the time :-), but this was a new build
[11:02] <two-face> pitti: heh
[11:21] <mdz> lamont: how goes the build adventure?
[11:21] <lamont> somewhere in the course of things, invoke-rc.d seems to get overwritten with the real version, which is most annoying.
[11:22] <lamont> dbus-1 directly invokes /etc/init.d/dbus-1, so I'm temporarily diverting that too...
[11:22] <lamont> because once you have tac-nukes, everything starts to look like a small city
[11:23] <lamont> the bitch is that the test cycle is now up to several minutes
[11:24] <lamont> 623 packages installed by apt-get install ubuntu-desktop linux-386
[11:24] <mdz> lamont: I think the dbus thing is deserving of a patch + bug report
[11:24] <lamont> mkinitrd was fun to divert.  /bin/true didn't cut it.
[11:24] <lamont> yes
[11:24] <lamont> will file that when I'm done
[11:25] <lamont> doh
[11:28] <mako> mdz: yo!
[11:28] <mdz> mako: what is up my brother
[11:28] <mdz> mako: what is happening in your hood?
[11:28] <mako> mdz: so your suggestion about the HEADER.html for the releases page.. what happened to it?
[11:29] <mdz> mako: I think nobody got around to putting the files in the right place
[11:29] <mako> mdz: lets do it..
[11:29] <mdz> mako: yes, let's
[11:29] <mako> thom: but us, i mean you
[11:29] <mdz> mako: and by let's, I mean you do it :-)
[11:29] <mako> hah
[11:29] <mako> right i'll do it
[11:29] <mako> and by i, i mean thom
[11:30] <lamont> mdz: dbus bug is ubuntu-specific
[11:30] <mako> mdz: i'll send mail to admins and then follow up on it
[11:31] <mako> mdz: i get mail every few days from people who are confused, and i liked the idea
[11:31] <mdz> lamont: because we patched it that way, or because we're behind on merges?
[11:31] <mdz> I'm guessing the latter
[11:32] <lamont> mdz: my bad.  debian has the bug, and I can't read.
[11:33] <lamont> mdz: debian has 0.22-4, we have 0.22+cvs.200412122010-0ubuntu4
[11:34] <mako> i think we should futher clarify the amd64 thing.. people think *allthetime* that they need amd64 for their athlon xp, etc
[11:34] <mdz> mako: yes
[11:35] <lamont> actually, not all that diff... we migrated it from 20 -> 12.
[11:36] <mjt> anyone know how to build certain file in glibc?
[11:40] <mjt> i want to experiment with that grep slowness with utf-8, to find the real cause of the problem.. but glibc build stuff is quite.. complex... ;)
[11:41] <pitti> mjt: what do you want to do?
[11:41] <pitti> mjt: I also touched glibc a while ago, but the build system is relatively easy
[11:41] <pitti> mjt: it just takes a while :-/
[11:41] <mjt> heh.. i tought i explained that a line above... ;)
[11:41] <pitti> mjt: what is "a certain file"?
[11:42] <mjt> i want to get some files (modified( off it and build either a static or shared (to pre-load) lib
[11:42] <mjt> so i will not need to reinstall glibc while doing some expiriments
[11:43] <azeem> messing with the glibc build system is not for the faint of the heart, AFAIK
[11:43] <mjt> nod
[11:43] <pitti> azeem: it's dpatch, nothing fancy
[11:43] <pitti> mjt: it has several build-tree directories
[11:43] <azeem> pitti: upstream build system
[11:43] <pitti> mjt: just build it once, then you can go into the build-tree, make your changes
[11:43] <pitti> mjt: ah
[11:44] <mjt> that's what i do now (it's compiling right now)
[11:44] <pitti> mjt: I thought you wanted to deal with the Ubunut/Debian source pacakge
[11:44] <mjt> in particular i want mbrtowc.c
[11:44] <pitti> mjt: believe me, that's much easier
[11:44] <mjt> it's irrelevant really
[11:44] <mjt> in fact i grabbed glibc-2.3.2.ds1-20
[11:45] <pitti> mjt: debuild -us -uc once to build everything
[11:45] <pitti> mjt: then you can go into one build-tree, make your changes, type make
[11:45] <pitti> mjt: and can LD_PRELOAD the resulting library in the build-tree
[11:45] <pitti> for experiments
[11:45] <pitti> mjt: above worked fine for me
[11:45] <mjt> ughrrrr...
[11:46] <mjt> /stage/build/glibc/glibc-2.3.2.ds1/build-tree/i386-libc/wcsmbs/mbrtowc.op(.text+0x109): In function `__mbrtowc':
[11:46] <mjt> /stage/build/glibc/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/wcsmbs/mbrtowc.c:92: undefined reference to `__mbsinit'
[11:46] <mjt> /stage/build/glibc/glibc-2.3.2.ds1/build-tree/i386-libc/wcsmbs/mbrtowc.op(.text+0x1a2): In function `__mbrtowc':
[11:46] <mjt> /stage/build/glibc/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/wcsmbs/wcsmbsload.h:74: undefined reference to `_nl_C_LC_CTYPE'
[11:46] <mjt> etc
[11:46] <mjt> ;)
[11:46] <pitti> mmm, that's your problem
[11:46] <crimsun> mdz: question regarding libflac4 -> libflac6 if you have a moment
[11:47] <mjt> (i just tried to build my program with one of the resulting .o files from glibc... ;)
[11:47] <pitti> crimsun: btw, -686 packages with fixed XFS are up :-)
[11:47] <mdz> crimsun: it's broken, and there is nothing I can do to fix it until elmo comes around again, I'm sorry
[11:47] <crimsun> mdz: np, thanks.
[11:47] <mdz> elmo: are you around?
[11:47] <crimsun> pitti: awesome. I'll try 'em when I get home tonight (in a few hours).
[11:48] <elmo> mdz: yeah?
[11:48] <Keybuk> gah; whatever happened to mono-assemblies-base 1.0.4 ?
[11:50] <mdz> elmo: I need flac 1.1.1-2 and evms 2.5.0-1 from queue/new to get into hoary
[11:50] <mdz> elmo: and then upstream version freeze needs to happen
[11:51] <elmo> gar, your as bad as jeff
[11:51] <elmo> "fix MY packages, then let them eat FROZEN CAKE"
[11:51] <elmo> ;P
[11:51] <mdz> elmo: dude, I completely broke flac
[11:52] <mdz> and we would have been fine, except that someone didn't do the freeze on the day it was scheduled :-P
[11:52] <mdz> so the broken version came into hoary
[11:52] <mjt> pitti: thanks for the suggestion.. i think i can go from there (a bit.. slow but that's something anyway)
[11:52] <lamont> elmo: is there any easy way to pass a passphrase to gpg from a program?
[11:52] <mdz> elmo: evms, well, as long as you're there...:-)
[11:53] <lamont> Keybuk: see the bug
[11:53] <Keybuk> lamont: #?
[11:53] <mvo__> lamont: I think there is  "--passphrase-fd n"
[11:53] <lamont> it's busted, they know it, and they'll upload working sources to debian when they have it built everywhere.  _then_ we can bootstrap it.
[11:53] <lamont> Keybuk: looking
[11:53] <elmo> what mvo said
[11:53] <lamont> Keybuk: 5052
[11:54] <elmo> mdz: done, but it won't hit debian till tomorrow now - shall I freeze now and let flac through when it hits Debian?
[11:54] <mdz> lamont: what's "it"?
[11:54] <lamont> short answer is that it's ftbfs, and when someone gives me a working source patch, I'll fix it.
[11:54] <lamont> mono
[11:54] <elmo> anyone got any experience with ipmi ?
[11:56] <mdz> elmo: both debian and ubuntu users are harrassing me about flac; if it's not too much extra work, it would be nice to fix it at least for the Ubuntu users
[11:56] <mdz> elmo: (yes, I know, my fuckup and all)
[11:56] <crimsun> mdz: / elmo: many thanks.
[12:01] <mako> mdz, anyone: http://mako.yukidoke.org/outgoing/test-dir/