[12:00] <seb128> ok ok
[12:00] <enrico> elmo: around?
[12:00] <seb128> so go with the compatibility stuff
[12:19] (lamont/#ubuntu-devel) hrm... gonna have to reboot
[12:19] (lamont/#ubuntu-devel) changing IP's will do that to you...
[12:30] <enrico> wiki login has been fixed
[12:36] <pitti> mdz: ping
[12:37] <seb128> 'night
[12:37] <jdub> night seb128 
[12:37] <pitti> night seb128 
[12:37] <jdub> elmo: did you see my paste above?
[12:37] <__daniel> bye seb128
[12:51] <pitti> elmo: one last upload from chinstrap, because the mysql package was already there anyway. Sorry... 
[12:51] <elmo> jdub: err, yes, why is that a surprise?
[12:51] <elmo> your key isn't in the debian keyring?
[12:51] <elmo> pitti: why doesn't ftp work for you?  is it just with this server or in general?
[12:51] <pitti> elmo: it's a general problem with my ISP
[12:51] <pitti> elmo: it works, but it is sloooooooooow
[12:51] <pitti> elmo: that's why I scp it onto another host and ftp from there
[12:51] <pitti> elmo: if chinstrap is to be avoided, I can also route it through my own server
[12:51] <elmo> pitti: ok - I just want to encourage people to test out the new upload daemon - if ftp is fux0red for you, you can use chinstrap
[12:51] <jdub> elmo: boh
[12:51] <pitti> elmo: tomorrow I have some smaller packages to fix, I will test it then
[12:51] <jdub> i thought putting those in DEFAULTS would default to ubuntu
[12:51] <jdub> bong
[12:58] <pitti> night
[01:19] <doko> night
[01:22] <lamont> maybe re-iping things wasn't the best timed act of the day... :-(
[01:35] <lamont> grumble.  bounced mail.  only about 60 messages though. :-(
[02:02] <lucas_> hi
[02:02] <lucas_> somebody with some debian-cd knowledge ?
[02:02] <lucas_> I need to build iso with software from (uni|multi)verse
[02:02] <lucas_> it isn't supported, right ?
[02:03] <lucas_> am I right when I think that the easiest way to fix this is to grep for "restricted" and see what was changed to add "restricted" support ?
[02:27] <lamont> lucas_: I started with a copy of the CD, added files, replaced the Packages/Sources/Release files, and reburned the CD
[02:28] <lamont> the rune to make the ISO is "mkisofs -r -V 'Ubuntu 4.10 i386 Bin-1' -o warty-install-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 wherever-your-new-tree-is"
[02:28] <lamont> understanding what that means is left as an exercise.
[02:34] <lupus_> is discover only called on install of ubuntu?
[02:34] <lupus_> or each boot
[02:35] <jdub> only on install
[02:35] <jdub> during install
[02:38] <lupus_> why only durring install?
[02:40] <lamont> lupus_: because warty doesn't use discover.
[02:40] <lamont> well, mostly
[02:41] <elmo> hotplug is better, basically and we're migrating to it
[02:41] <elmo> +even in the installer
[02:41] <lupus_> ah so hotplug is not used in the installer at the moment
[02:41] <lupus_> only discover
[02:44] <elmo> yeah
[02:44] <elmo> tho, that's already changed in hoary
[03:00] <lupus_> so /etc/hotplug is for coldplugging and /etc/hotplug.d to have hotplugging? sorry I'm trying to understand how hardware is detected and configured
[03:03] <lupus_> nm I'm wrong :)
[03:20] <jdub> http://mail.nl.linux.org/humorix/2004-11/msg00002.html
[03:39] <lamont> jdub: heh
[03:49] <jdub> the final live cd looks brill
[03:50] (sladen/#ubuntu-devel) "final" ?
[03:50] <ironwolf> warty? yeah, it's pretty.
[03:52] <jdub> sladen: the release version, on the pretty printed cds :)
[03:52] <jdub> i didn't have the b/w to pull many live cd releases
[03:54] <lamont> ironwolf: did your order show up yet, btw?
[03:54] <ironwolf> lamont: no, only 3 days left too...
[03:55] <ironwolf> lamont: although I have had lots more local interest in them when they arrive.
[03:56] <eruin> blah, I can't rightclick files and create an archive anymore
[03:58] <jdub> vino + damage == rock!
[04:02] <lamont> well, night
[04:02] <jdub> later lamont
[04:03] <ironwolf> night lamont
[05:00] <ironwolf> lamont around?
[06:20] <fabbione> morning guys
[07:55] <fabbione> lamont: ping
[08:38] <pitti> Hi all
[08:44] <jdub> doko: woo!
[08:55] <lifeless> jdub: what were you pinging about before ?
[08:58] <jdub> don't remember :)
[08:58] <jdub> oh
[08:58] <jdub> here's something though
[08:58] <jdub> baz register-archive -> do you ever register anything other than an archive?
[08:58] <lifeless> oh, ui names ?
[08:58] <lifeless> ie baz register ?
[08:58] <jdub> yeah
[08:59] <lifeless> sounds good, chuck it in the mockup UI :)
[08:59] <pitti> ping lamont
[08:59] <jdub> lifeless: also, what do you think about splitting that page up a bit? it's getting unwieldy
[08:59] <jdub> lifeless: happy to take an initial stab at it
[08:59] <lifeless> please do
[09:03] <pitti> elmo: here?
[09:18] <jdub> doko: ping?
[09:39] <seb128> morning
[09:40] <seb128> jdub: #4092 is WONTFIX, right ?
[09:41] <jdub> yeah, atm
[09:42] <pitti> Hi seb128 
[09:43] <seb128> hey pitti 
[10:24] <Kamion> I really must actually upload our modified debian-cd to hoary for this release
[10:27] <fabbione> hey Kamion 
[10:27] <fabbione> Kamion: kernel-wedge doesn't like symlinks :(
[10:27] <fabbione> things need to be copied in proper places for it to work
[10:28] <Kamion> can you elaborate?
[10:28] <Kamion> oh, make-links and clean
[10:28] <fabbione> sure...
[10:28] <Kamion> yeah, but dpkg-source doesn't much like symlinks in diffs either
[10:28] <Kamion> at best they'll get expanded into real files
[10:28] <fabbione> remeber we agreed on the dir structure of debian/d-i/<arch> ?
[10:28] <Kamion> so you might as well copy
[10:28] <Kamion> yes
[10:29] <fabbione> perfect.. to generate debian/control from control.stub, kernel-wedge accesses a bunch of files like modules/<arch>/
[10:29] <fabbione> the original idea was to symlink those from the top level directory
[10:29] <fabbione> but kernel-wedge just delete the symlinks
[10:29] <fabbione> so they need to be copied and removed
[10:29] <fabbione> in order to keep the top level dir clean
[10:30] <fabbione> perhaps it would be nice for kernel-wedge to understand symlinks
[10:30] <Kamion> right, but all the modules/<arch> directories are separate anyway
[10:30] <Kamion> you might as well just copy them
[10:30] <fabbione> no big deal.. just some extra cp rm work
[10:30] <fabbione> Kamion: yes.. i agree. i don't want to clutter the top level dir.
[10:30] <fabbione> since it is the top level of the kernel
[10:30] <fabbione> and still other files need to be copied per arch
[10:31] <fabbione> and this will also keep the merging easier
[10:39] <mdz> pitti: pong
[10:40] <pitti> mdz: Hi!
[10:40] <pitti> mdz: can you please take a look at the mysql USN?
[10:40] <pitti> mdz: I try to reach lamont or elmo to investigate the missing build from ppc, but as soon as this is sorted out, I can publish it
[10:40] <mdz> pitti: ok
[10:40] <mdz> pitti: you can reproduce the problem, right?  it is not just me?
[10:41] <pitti> mdz: "the problem" ==?
[10:41] <mdz> I straced it and it is not calling mlock(2)
[10:41] <mdz> pitti: gpg
[10:41] <pitti> mdz: ah
[10:41] <pitti> mdz: I followed up the bug report
[10:41] <pitti> mdz: it's a buildd problem
[10:41] <mdz> yes, very strange
[10:41] <pitti> mdz: it works fine when I build it on my machine and I investigated the cause of the problem
[10:41] <pitti> mdz: luckily the warty version was built correctly
[10:41] <mdz> I saw
[10:42] <mdz> pitti: what do you want me to look at for mysql?
[10:42] <pitti> mdz: just the USN text
[10:42] <mdz> I sent email to the list regarding the diffs
[10:42] <mdz> ok
[10:43] <fabbione> i think some buildd chroots are having problems
[10:43] <pitti> mdz: https://chinstrap.warthogs.hbd.com/~pitti/usn-mysql.txt
[10:43] <fabbione> like having too many apt entries
[10:43] <pitti> fabbione: so far I only had problems with amd64, it's my first ppc failure
[10:43] <mdz> pitti: it should note explicitly that -0837 and -0956 require an authenticated mysql user in order to exploit
[10:44] <fabbione> pitti: i noticed gdb has been built
[10:44] <fabbione> but using universe packages
[10:44] <fabbione> that means that some stuff might be actually building for mistake
[10:44] <fabbione> (talking about hoary)
[10:44] <lucas_> Hi
[10:45] <lucas_> I've always been confused by "warty-updates" vs "warty" dists on the mirror
[10:45] <lucas_> from what I understand, some updates go in "warty", but not all of them ?
[10:45] <lucas_> or is "warty" totally frozen ?
[10:45] <daniels> warty's totally frozen
[10:45] <lucas_> ok
[10:46] <pitti> mdz: fixed
[10:48] <seb128> lucas_: changes in warty are mainly security fixes
[10:48] <lucas_> those go in warty-security right ?
[10:49] <seb128> yes
[10:49] <seb128> why ?
[10:55] <mdz> lucas_: as described on the website, stable releases receive only security fixes and other critical bug fixes
[10:56] <mdz> pitti: the advisory text needs a few more changes, I will send you an updated version
[10:56] <pitti> mdz: okay, thanks
[10:57] <lucas_> yup, my question was about building warty CDs that include the security/bug fixes
[10:57] <lucas_> but I need to read more debian-cd code
[10:57] <Kamion> (I'm only limited help here because I've never actually tried doing that ...)
[10:58] <lucas_> ok, I think I'll start by building CDs based on released warty packages, ignoring updates
[11:00] <Kamion> that will certainly be easier
[11:00] <lucas_> no plans to release ubuntu 4.10r(0..n) ?
[11:00] <Kamion> don't believe so
[11:01] <lucas_> ok
[11:01] <smurfix> lucas_: not much point, with a 6-month release schedule. This isn't Debian. ;)
[11:02] <lucas_> yeah I know, I was just asking because it would have helped me a lot ;)
[11:02] <Kamion> you could investigate update-cd I guess, but that's *really* never been tested with Ubuntu
[11:02] <lucas_> ok
[11:07] <lucas_> the easiest would probably be to write a tool that would merge warty-update and warty-security inside warty
[11:07] <lucas_> so there's no need to hack debian-cd
[11:07] <lucas_> (merge in the local mirror)
[11:09] <seb128> lucas_: do you really need the security updates on the CD ?
[11:09] <lucas_> it's not high priority, but it would be better
[11:10] <lucas_> some of my "customers" don't have broadband
[11:10] <Kamion> lucas_: that's a bit scary; debian-cd *is* capable of reading multiple Packages files in general so it shouldn't be necessary
[11:10] <lucas_> don't forget grenoble != la doua ;)
[11:10] <lucas_> ok
[11:10] <seb128> lucas_:  people who have a network connection just have to download these updates, what's the security issue with people who don't have a network connection ?
[11:11] <lucas_> the problem is for people who have a network connection but not broadband
[11:11] <seb128> lucas_: bah, just wondering if a student with no connection really needs the security updates
[11:11] <seb128> lucas_: security updates already are that big ?
[11:11] <lucas_> not sure
[11:11] <lucas_> depends on what is updated ;)
[11:12] <mdz> lucas_: we have talked about producing CDs containing only security updates
[11:12] <Kamion> seb128: yes, often
[11:12] <seb128> ok
[11:12] <mdz> seb128: xfree86 has been updated, e.g.
[11:12] <seb128> right
[11:12] <mdz> lucas_: that is what I recommend that you do, if you are interested in pursuing this
[11:12] <jdub> doko: around?
[11:13] <lucas_> mdz: it might be difficult regarding my user base
[11:13] <__daniel> hai
[11:13] <lucas_> well, that's not high priority anyway
[11:14] <lucas_> bbl
[11:21] <Kamion> mdz: lucas_ is doing a single CD with a number of other modifications anyway
[11:22] <Kamion> mdz: it makes little sense for him to waste time creating a separate security update CD
[11:24] <mdz> Kamion: except that the work would be reusable
[11:25] <Kamion> sure, but it's not what his userbase wants
[11:26] <Kamion> see ubuntu-devel@
[11:26] <Kamion> there's no point trying to get reusable work out of somebody when it's not usable for them
[11:28] <Kamion> mdz: oh, if you didn't notice, I moved mozilla-browser/mozilla-psm from ship to supported yesterday
[11:28] <Kamion> there seemed to be reasonable consensus for at least that step
[11:29] <mdz> that's fine by me
[11:36] <elmo> % linda *.changes
[11:36] <elmo> Happy birthday to me!
[11:36] <elmo> I'm 3 today!
[11:36] <elmo> oh dear
[11:38] <mdz> Kamion: his userbase will eventually need to download security updates; creating an updated CD doesn't solve that problem at all
[11:38] <mdz> the security update CD approach has the clear advantage of actually working on an ongoing basis
[11:38] <Kamion> it'll be no worse than for our own CDs though
[11:39] <Kamion> I don't think he has a problem either with his userbase having to download some updates or with updating his CD every so often
[11:40] <Kamion> elmo: linda scares me
[11:40] <mdz> ok, I guess I don't understand the use case then
[11:41] <pitti> elmo: can you please look why the mysql security update did not built on ppc?
[11:44] <elmo> err, it looks like lamont disabled warty-security on the powerpc buildds by mistake 
[11:44] <pitti> elmo: can you fix that or shall I wait for lamont?
[11:44] <elmo> I'll have a quick look in a bit
[11:44] <pitti> thank
[11:44] <pitti> s
[11:45] <Kamion> mdz: he's lending CDs to other students in his student union who aren't very computer-knowledgeable; he needs to remove/add some packages to provide for the students' special needs, and he needs to make some changes to the installer too
[11:45] <Kamion> mdz: the ones that can't download security updates are the ones who don't have an internet connection, so that's not such a big deal
[11:45] <Kamion> mdz: I think his rationale for updating the CD with security updates is just that he might as well, it's a nice-to-have
[11:45] <mdz> in that case, I don't see the point of bothering with security updates at all
[11:46] <mdz> ok
[11:47] <Kamion> I can certainly see the rationale; if you're going to build a CD now, it might as well be current
[11:48] <pitti> mdz: oh, have a happy holiday! :-)
[11:48] <mdz> thanks
[11:48] <pitti> mdz: thanksgiving is another opportunity to stuff one's stomach with far too much food, right?
[11:49] <mdz> correct
[11:49] <pitti> mdz: enjoy :-))
[11:49] <fabbione> hehehe
[11:56] <elmo> # list of distributions that buildd should take packages from
[11:56] <elmo> @take_from_dists = qw(stable frozen unstable);
[11:56] <elmo> *boggle*
[11:57] <Kamion> hooray for buildd
[11:57] <daniels> elmo: looks like someone installed a new w-b, heh
[11:58] <Kamion> yeesh, pciutils still has no DH_COMPAT or debian/compat? bleh
[11:58] <daniels> elmo: do you have access to the ia64 thingies?
[11:59] <elmo> daniels: blink - of course?
[11:59] <daniels> elmo: do you care to spin a build around them, or should I harass lamont when he wakes?
[12:01] <elmo> harass lamont to get debootstrap working, then I can create a hoary chroot on the port box
[12:01] <daniels> elmo: k, cheers
[12:01] <daniels> lamont: harass, harass, p.u.c/~daniels/xorg, etc
[12:02] <elmo> pitti: ok, should be fixed now
[12:02] <pitti> elmo: thanks
[12:02] <elmo> (or at least the powerpc buildds will start building things now)
[12:02] <pitti> elmo: it will automatically arrive at rookery now?
[12:02] <pitti> elmo: or must there be a trigger of some kind?
[12:02] <mdz> night, all
[12:02] <pitti> night mdz 
[12:02] <seb128> 'night mdz 
[12:02] <Kamion> sleep well
[12:03] <elmo> pitti: err, jackass you mean? yes
[12:03] <daniels> mdz: night
[12:03] <pitti> elmo: yes, of course. jackass
[12:04] <Mithrandir> why doesn't nautilus allow one to open a folder multiple times on multiple desktops?
[12:06] <seb128> bug ?
[12:06] <jdub> Mithrandir: you can in browse mode; spatial is spatial.
[12:06] <seb128> oh, doesn't
[12:06] <seb128> I misread
[12:06] <jdub> Mithrandir: the window *is* the folder.
[12:06] <Mithrandir> jdub: but the window is on another desktop.
[12:07] <Mithrandir> jdub: it means I have to race xpdf to make it open on the right desktop.
[12:07] <seb128> ?
[12:07] <seb128> what are you trying to open/start, and how ?
[12:07] <jdub> Mithrandir: you're saying that the window is open, and you try to open it again, but it does nothing (because it's already open on the other desktop)?
[12:08] <Mithrandir> jdub: no, it moves me to the other desktop.
[12:08] <Mithrandir> which is totally surprising.
[12:08] <seb128> it should move the window on the current one
[12:08] <Mithrandir> seb128: agreed.
[12:08] <seb128> it does here
[12:08] <Mithrandir> not here, but I'm using openbox.
[12:09] <seb128> oh, so probably an openbox bug
[12:09] <jdub> it does here too
[12:17] <pitti> elmo: $ ps aux|grep ntpd
[12:17] <pitti> ntp       2052  0.0  0.4  3516 3516 ?        SLs  12:16   0:00 ./ntpd
[12:17] <pitti> elmo: :-)
[12:19] <elmo> pitti: sweet thanks
[12:19] <gicmo> hi
[12:19] <pitti> elmo: well, it needs some tweaks (to work also on non-cap kernels and such), but it works in principle
[12:20] <daniels> elmo: so is davis fully set up to be abused?
[12:20] <elmo> pitti: next I need you to fix... ssh, cron, klogd, sylogd, postfix and getty.. kthxbye
[12:20] <elmo> ;-)
[12:20] <elmo> daniels: AFAIK, yeah
[12:20] <pitti> elmo: ssh? easy, it just could lack a _little_ functionality...
[12:20] <Kamion> *ahem*
[12:20] <pitti> elmo: btw, syslogd?
[12:21] <pitti> elmo: I fixed that yesterday
[12:21] <elmo> pitti: both syslogd and klogd?
[12:21] <pitti> elmo: no, it's impossible for klogd
[12:22] <pitti> elmo: klogd needs CAP_SYS_ADMIN, which is equivalent to root
[12:22] <pitti> elmo: the odd thing is, you cannot open /proc/kmsg as root and read from the descriptor as user
[12:22] <pitti> elmo: this works for normal files, but not for /proc/kmsg
[12:22] <pitti> elmo: with the current kernel there's nothing I can do
[12:23] <elmo> oh well.. nice for syslogd anyways
[12:23] <elmo> s/for/to get/
[12:24] <daniels> elmo: cool
[12:33] <Kamion> -rw-rw-r--    1 cjwatson cdimage  636405760 Nov 24 08:49 20041124/hoary-install-powerpc.iso
[12:33] <Kamion> -rw-rw-r--    1 cjwatson cdimage  625797120 Nov 25 08:49 20041125/hoary-install-powerpc.iso
[12:33] <Kamion> \o/
[12:34] <daniels> Kamion: congrats :)
[12:34] <daniels> Kamion: how did you shave that much off?
[12:35] <Kamion> mozilla-browser
[12:35] <daniels> ahr
[12:36] <daniels> elmo: btw, would it be possible to get access to an ia64 port box once lamont makes chroots work and stuff?
[12:36] <elmo> sure
[12:36] <elmo> I just need working debootstrap
[12:36] <Kamion> yeah, waiting on gcc-3.4
[12:37] <daniels> elmo: awesome, thanks
[12:37] <elmo> oh, ok, thought Lamont had bodged that
[12:37] <Kamion> think it's the last thing left to do
[12:37] <elmo> and why on earth do.. oh libgcc
[12:37] <Kamion> at least, it was last time I heard
[12:37] <Kamion> elmo: yeah
[12:37] <Kamion> I'm kind of refusing to do debootstrap until I can do it automatically from germinate output :-/
[12:38] <Kamion> lamont has a hacked script though I believe, if you want to ask him for it
[12:39] <elmo> no, that's fair enough
[12:39] <Kamion> anyone object to me adding pciutils-udeb to the installer seed?
[12:45] <daniels> Kamion: seems eminently sensible
[12:46] <elmo> daniels: btw, don't forget to add that fd candy to the appopriate seed
[12:46] <elmo> seb128: you too for gnome-python-extras
[12:46] <elmo> doko: and you too for zope
[12:46] <seb128> ok
[12:47] <daniels> elmo: good catch
[12:49] <Keybuk> jdub: btw. I've mailed the hotplug-ng and udevsend/udevd guys to see what they think the future should be
[12:49] <jdub> elmo, daniels: do we actually want the fd candy in any of the seeds?
[12:49] <jdub> Keybuk: rad
[12:49] <daniels> jdub: i put fdclock/xcompmgr/transset in supported
[12:50] <daniels> jdub: fdclock might be sorta kinda neat, but the compmgr is really just too slow
[12:50] <jdub> daniels: i don't think there's any reason to support them
[12:50] <Keybuk> jdub: I also sent them grepmap as a "here's the C modules.*map parser for you" :)
[12:50] <daniels> jdub: oh?
[12:51] <daniels> jdub: i think enough people will want to use them to support them
[12:51] <daniels> jdub: but not enough, and it's not general-purpose enough, to ship them per default
[12:51] <daniels> jdub: but, your call
[12:51] <elmo> yes, sorry, please remember when I say "add to the appropriate seed" there's a hidden subtext of "and get sign off for it, if you need to" :-P
[12:52] <jdub> yeah, these things should be added to the seed proposals page
[12:52] <jdub> daniels: they're not useful to support though, surely they're fine for universe
[12:53] <daniels> jdub: done
[12:53] <jdub> daniels: please put them on the proposals page though, we may come back to it
[12:54] <daniels> jdub: k
[12:56] <jdub> anyone mind if i patch out the openoffice.org kde stuff, so we can get a build?
[12:58] <daniels> oh frig, this means I need to edit the wiki
[12:59] <elmo> god I would KILL for sysklogd to use fricking logrotate
[01:01] <jdub> far out
[01:01] <jdub> 171MB
[01:02] <rburton> daniels: i hear you are off to see mallum on monday
[01:02] <daniels> rburton: i hear you are too!
[01:02] <rburton> daniels: indeed. want to meet at victoria?
[01:03] <daniels> rburton: rockin'
[01:03] <daniels> rburton: easy to get to from south ken?
[01:03] <rburton> yeah, along on the circle for a bit
[01:03] <rburton> or the district. yellow or green.
[01:03] <daniels> swoit
[01:03] <daniels> ahr, right
[01:03] <daniels> yeah
[01:04] <daniels> which means it's easy from earl's court also -- phat
[01:04] <rburton> daniels: what time were you planning on going?
[01:04] <daniels> rburton: *shrug*, whenever
[01:05] <haggai> jdub: sure.  I was thinking we're gonna have problems sometime with OOo needing GTK and KDE libs to build
[01:06] <daniels> haggai: availability isn't a huge problem, it's just that that would drag kde into main
[01:06] <haggai> jdub: I want to split some of the -dev sort of headers out and make an installable .deb from them but like everything with OOo it takes ages & ages to do
[01:06] <haggai> daniels: but that would suit KDE users ;)
[01:06] <Kamion> we could imaginably end up stripping out the KDE build-dep for Ubuntu; it wouldn't be the first package we've done that for ...
[01:07] <jdub> yeah, that's the main issue
[01:07] <fabbione> elmo: (wishlist) any eta for sparc.u.c =
[01:07] <Kamion> life will be easier once we have community maintenance for KDE
[01:07] <jdub> atm we can't build it because kdelibs4-dev isn't in universe
[01:07] <fabbione> s/=/?
[01:07] <jdub> Kamion: but that doesn't necessarily mean kde in main :)
[01:07] <haggai> is there any way we can tell if we're building for Ubuntu?  We have a lot of optional stuff in the pkgs controlled by DEB_BUILD_OPTIONS and it would be handy if we could do the same with the KDE bits too
[01:07] <_rene_> yeah, good idea
[01:07] <Kamion> haggai: nope, we just upload a *ubuntuN version
[01:08] <daniels> Kamion: is it worth setting a default DEB_BUILD_OPTIONS="ubuntu"?
[01:08] <Kamion> although having our changes integrated that way could make life easier
[01:08] <Kamion> daniels: users rebuilding our source packages won't set that
[01:08] <haggai> daniels: yeah, might be a good idea
[01:08] <daniels> Kamion: like, within dpkg-buildpackage, or /etc/environment, or something
[01:08] <elmo> fabbione: I'm trying to ping sabdfl about sparc boxes - I'd really like to know if we're going to do that first
[01:08] <Kamion> that's always the problem with DEB_BUILD_OPTIONS and similar; they can only be used for optional features, not what the buildd needs
[01:09] <Kamion> daniels: EWWW
[01:09] <daniels> Kamion: (sorry)
[01:09] <Kamion> daniels: (what if somebody wants to build the Debian source package on Ubuntu?)
[01:09] <daniels> Kamion: (good question)
[01:09] <jdub> (stop whispering)
[01:09] <Kamion> source packages pretty much have to be self-contained, unfortunately
[01:09] <daniels> Kamion: (of course, dpkg-buildpackage could only set D_B_O if the source version contained 'ubuntu' ...)
[01:09] <haggai> so what about adding some sort of DEB_BUILD_OPTIONS+=ubuntu in debian/rules?
[01:10] <haggai> (as an ubuntu-only patch)
[01:10] <Kamion> haggai: if our diff were just that one line, that'd rock
[01:10] <haggai> Kamion: that's my idea
[01:10] <rburton> daniels: meet at victoria train station, around platforms 1-8, about 11:30-40? there is a train at 11:53
[01:10] <daniels> Kamion: to every package?
[01:10] <daniels> rburton: sounds awesome
[01:10] <Kamion> not sure DEB_BUILD_OPTIONS is *quite* the right place, but anyway
[01:10] <jdub> haggai: what would the kde package have in it, if we did that?
[01:10] <_rene_> jdub: we could just disable it
[01:10] <Kamion> I think I'd prefer DEB_DISTRIBUTION or something
[01:10] <haggai> the advantage of DEB_BUILD_OPTIONS+= means you can build the ubuntu variant on Debian.. :)
[01:11] <_rene_> jdub: -Nopenoffice.org-kde etc
[01:11] <rburton> daniels: sweet. mail me your mobile so i can find you when you are lost ;)
[01:11] <daniels> rburton: heh :)
[01:11] <Kamion> yeah, just trying to avoid overloading DEB_BUILD_OPTIONS itself
[01:11] <fabbione> elmo: didn't we agree that i was going to offer "main" in an unofficial archive and that if the port will take off, we were going to buy buildd?
[01:11] <_rene_> jdub: so we could make -lde not even built
[01:11] <daniels> rburton: sent
[01:11] <Kamion> _rene_: or generate the control file
[01:11] <elmo> oh, maybe we did. blah, my brain sucks
[01:11] <Kamion> so that -kde isn't in the .dsc either
[01:11] <fabbione> elmo: because i am already building the "golden debs" for main at this stage...
[01:12] <jdub> _rene_: ahr :)
[01:12] <jdub> _rene_: handy
[01:12] <fabbione> elmo: and when they will finish i can add universe & co.
[01:12] <_rene_> jdub: we actually do that now like this with the java/nonjava flag
[01:13] <daniels> thom: kaping
[01:14] <haggai> Kamion: we actually generate the control file anyway so yeah we could take it out but I think just using -Nopenoffice.org-kde, like we do for the optional -java pkg, should be enough
[01:14] <elmo> fabbione: okay, I'll try and have a look at doing s.u.c in the next couple of days - it has to be below a few other things in my todo list tho
[01:14] <fabbione> elmo: sure... that will be more than perfect
[01:15] <_rene_> hmm. that still leaves the builddep, though ;-)
[01:15] <fabbione> elmo: when you will be ready to test the setup i will send you the gpg key for the buildd
[01:15] <fabbione> elmo: if you don't mind i want to keep them separate
[01:16] <haggai> _rene_: oh, yeah good point
[01:16] <haggai> _rene_: we can always do our trick of depending on something in the distro :)
[01:16] <haggai> _rene_: like the woody bp
[01:16] <elmo> fabbione: of course - tho, if we go ahead with the port, I think one of the things we do when we get our buildds, is rebuild the world on them ?
[01:16] <_rene_> ah, yeah
[01:16] <haggai> Build-depends: kdelibs | ubuntu-somthing
[01:16] <rburton> daniels: where did you send the mail? it's not here yet
[01:16] <_rene_> kdelibs4-dev | some-ubuntu-stuff
[01:17] <daniels> rburton: rburton@d.o?
[01:17] <jdub> haggai: oof. :)
[01:17] <rburton> daniels: ross@
[01:17] <daniels> ... which just bounced, rock on
[01:17] <_rene_> jdub: works, we did that already with woody and dpkg-dev ;-)
[01:17] <haggai> jdub: you haven't seen all our hacky^W neat stuff for our woody backport from the same OOo source? :)
[01:17] <fabbione> elmo: we can still use my "golden debs" to start with
[01:17] <jdub> haggai: i saw the 171MB download and turned back :)
[01:17] <daniels> rburton: try that
[01:17] <fabbione> elmo: there is no point in starting from scratch again
[01:18] <_rene_> jdub: heh
[01:18] <fabbione> elmo: i can already bootstrap ubuntu sparc chroots
[01:18] <haggai> jdub: ok, you failed the real h4ck3r test then
[01:18] <jdub> heh
[01:18] <fabbione> elmo: and with a bit of love we might be able to install ubuntu on them directly ;)
[01:18] <jdub> .au has lots of real hackers :)
[01:18] <jdub> we just don't ahve a lot of real bandwidth :)
[01:18] <fabbione> jdub: s/real/fake/
[01:19] <fabbione> ;)
[01:19] <daniels> we don't have much fake bandwidth, either
[01:21] <fabbione> daniels: well it was for the hackers
[01:22] <fabbione> daniels: mtools is another FTBFS from xlibs split :( i uploaded the fix.. mind to keep an eye on it?
[01:23] <daniels> fabbione: sure
[01:23] <fabbione> daniels: where is xorg crack? :P
[01:25] <daniels> fabbione: concordia has finished (like 20min ago), davis has just started -dbg, and catsby (my laptop) is meandering through
[01:25] <fabbione> davis ?
[01:25] <fabbione> ia64?
[01:25] <elmo> davis is adare
[01:25] <daniels> nope, new powerpc port box
[01:25] <elmo> er
[01:25] <fabbione> ah ok
[01:25] <daniels> adare's motd told me to use davis for chroot builds, so I did
[01:25] <elmo> davis is powerpc, it replaces adare
[01:25] <elmo> halley is the ia64 port box, but it doesn't have a hoary chroot yet
[01:26] <Kamion> haggai: something in the distro> that's really sick and twisted ;)
[01:26] <fabbione> ok
[01:26] <fabbione> thanks
[01:28] <_rene_> Kamion: you haven't seen the foo | dpkg-dev (<< something) builddeps, have you? ;-)
[01:28] <lupus_> libgnome2-common_2.8.0-5ubuntu1_all.deb the 5=debian release? and the 1=ubuntu release? or how does the versioning system work?
[01:28] <jdub> night all
[01:28] <bob2> 'night jdub 
[01:28] <daniels> jdub: 'nacht
[01:29] <daniels> _rene_: oh man, that's hideous
[01:29] <_rene_> daniels: hackish, but works
[01:29] <Kamion> _rene_: I think I noticed them once and RAN AWAY SCREAMING
[01:30] <Kamion> lupus_: first Ubuntu revision on top of 2.8.0-5
[01:31] <_rene_> Kamion: :)
[01:31] <fabbione> Kamion: we need to do a really hackish thing to merge the udeb creation :(
[01:31] <Kamion> fabbione: oh?
[01:31] <fabbione> Kamion: because the install target doesn't actually install in debian/<pkgname> (that i was hoping for)
[01:31] <daniels> fabbione: what's mtools doing with libxau?!?
[01:32] <fabbione> Kamion: and later binary-arch calls make-kpkg to create the debs, that are than moved to the right place
[01:32] <Kamion> fabbione: which install target?
[01:32] <fabbione> daniels: you ask me?
[01:32] <fabbione> Kamion: then one in the top level debian/rules
[01:32] <fabbione> daniels: it FTBFS without
[01:32] <Kamion> fabbione: oh, you clearly have to run kernel-wedge after most of binary-arch is finished
[01:33] <daniels> fabbione: oh man
[01:33] <fabbione> Kamion: yep
[01:35] <fabbione> daniels:
[01:35] <fabbione> floppyd.c:28:23: X11/Xauth.h: No such file or directory
[01:35] <fabbione> floppyd.c: In function `do_auth':
[01:43] <seb128> herzi: your testcase doesn't work and I think than bastien doesn't want to debug it 
[01:50] <herzi> well, it works on my machines, maybe it's locale-dependent?
[01:50] <seb128> $ ./compile.sh
[01:50] <seb128> gcc: -E required when input is from standard input
[01:50] <seb128> here
[01:51] <seb128> BTW don't bother to fix it, I've added a tarball to the BR
[01:51] <herzi> i saw that
[01:51] <herzi> it's good for non-english people to have this fixed
[01:52] <seb128> yeah
[02:11] <seb128> elmo: eog sync please
[02:11] <elmo> seb128: done
[02:11] <seb128> thanks
[02:11] <fabbione> Kamion: regarding the kernel-versions file
[02:11] <fabbione> Kamion: the last entry is the build-dep field, that we don't need anymore, since we build everything from the same source
[02:11] <fabbione> Kamion: problem is: if i leave a build-dep in there it finishes into debian/control
[02:11] <fabbione> Kamion: if i remove it kernel-wedge install-files will fail a sanity check
[02:12] <fabbione> Kamion: and i have 2 options to fix it:
[02:12] <fabbione> Kamion: a) patch kernel-wedge to be less anal in that sanity check
[02:12] <daniels> fabbione: if you want to give ubuntu4 a test run around sparc (p.u.c/~daniels/xorg), that would be cool
[02:12] <fabbione> Kamion: b) insert a fake build-dep in kernel-versions
[02:13] <fabbione> Kamion: fake as in writing for ex. tar
[02:13] <fabbione> Kamion: or something like that
[02:13] <fabbione> daniels: it would take hours to build and don't worry about sparc until there is a need for it :-)
[02:14] <fabbione> Kamion: what would you prefer?
[02:14] <fabbione> Kamion: the change in kernel-wedge would be limited to commands/install-files
[02:15] <fabbione> Kamion: the var is not even used.. just checked for len > 0
[02:15] <daniels> fabbione: heh, ok
[02:15] <daniels> fabbione: waiting on lamont for an ia64 test build anyway
[02:16] <Kamion> fabbione: uh, wait a sec, I want to look at this carefully
[02:16] <fabbione> Kamion: sure
[02:16] <Kamion> fabbione: we must not break kernel-wedge in such a way that you can't build Debian's installer on Ubuntu any more
[02:17] <fabbione> Kamion: removing the sanity check shouldn't break
[02:17] <Kamion> yeah, but it sucks
[02:17] <fabbione> otherwise we need to patch gen-control
[02:17] <fabbione> or create a gen-control-ubuntu
[02:17] <Kamion> noooo
[02:17] <Kamion> this is why I said "wait a sec"
[02:17] <fabbione> eheh
[02:17] <Kamion> let's not do random things just to hack it into working; this should be done properly
[02:18] <fabbione> i agree.. that's why i am discussing it with you :-)
[02:18] <Kamion> ok
[02:18] <Kamion> I don't see this sanity check?
[02:18] <fabbione>             ! length $builddep ) {
[02:19] <fabbione> in commands/install-files
[02:19] <Kamion> ah
[02:19] <Kamion> why not just not call gen-control?
[02:19] <Kamion> oh, no, you need it
[02:19] <fabbione> Kamion: because we need the control? ;)
[02:20] <fabbione> kernel-wedge is correct assuming that there must be a build-dep
[02:20] <fabbione> it's our merge that goes against it
[02:21] <Kamion> hmmm
[02:21] <fabbione> actually...
[02:21] <fabbione> i think the best approach would be to change gen-control
[02:21] <Kamion> I don't think I'd object to changing install-files, actually
[02:21] <Kamion> that seems the most compatible approach
[02:22] <fabbione> or create an ubuntu copy of it
[02:22] <Kamion> no
[02:22] <Kamion> no copies
[02:22] <fabbione> hmm why not?
[02:22] <fabbione> it would make merge very simple
[02:22] <Kamion> have you heard the term "clone-and-hack"?
[02:22] <fabbione> hmmm no
[02:22] <Kamion> if we copy, we do not get the benefit of bug fixes
[02:22] <Kamion> it's not a complimentary term
[02:23] <fabbione> Kamion: let me see one thing
[02:23] <Kamion> what gen-control change were you thinking of?
[02:25] <fabbione> Kamion: well on our system should not add the entry in the Build-Dep field
[02:25] <fabbione> Kamion: otherwise you will get a source that build-dep on itseld
[02:25] <fabbione> itself binaries
[02:25] <Kamion> I don't like that, I'd much rather remove the check from install-files
[02:26] <Kamion> that seems fairly harmless, looking at it
[02:26] <fabbione> Kamion: otherwise how would you feel in NOT touching the code at all
[02:26] <Kamion> especially since gen-control does not perform that sanity check
[02:26] <fabbione> and just add a fake build-dep ?
[02:26] <Kamion> nah, let's remove the check, that's better
[02:26] <fabbione> ok.. do you want to do it, or should i?
[02:27] <Kamion> no point adding fake cruft to lots of kernel-versions files
[02:27] <fabbione> hmm no
[02:27] <fabbione> it's only on one line
[02:27] <Kamion> I've got the change here, will upload
[02:27] <fabbione> the Build-Dep 
[02:27] <fabbione> ok thanks
[02:27] <Kamion> per-arch, remember
[02:27] <fabbione> not in this case
[02:27] <fabbione> it will add it to linux-source
[02:27] <fabbione> but ok...
[02:28] <fabbione> the change to the code is ok with me :-)
[02:28] <Kamion> um, you still have multiple kernel-versions files surely?
[02:28] <Kamion> I mean, you have to
[02:28] <fabbione> yes, but the gen-control changes only the Build-Dep to add the ones listed in kernel-versions
[02:28] <fabbione> anyway it's ok the change to the code :-)
[02:29] <Kamion> right, but if you were adding a fake build-dep you'd have to do that on every kernel-versions line; that's where the check was being applied
[02:29] <fabbione> oh yes
[02:29] <fabbione> i misunderstood you before :-)
[02:29] <Kamion> I'll talk to joeyh next time I remember, see if this can go upstream
[02:30] <fabbione> good idea
[02:30] <Kamion> uploaded, thanks
[02:30] <fabbione> thanks to you :-)
[02:30] <fabbione> i think i can give you the first -17 -> -18 interdiff tomorrow to create debs...
[02:31] <fabbione> tho there is still the versioning problem that i need evaluate
[02:31] <fabbione> if we are going to create newer or older udebs
[02:31] <Kamion> cooooooool
[02:31] <Kamion> udebs don't have an upgrade problem technically, but katie may hate you
[02:31] <fabbione> Kamion: i am taking my time to be as less intrusive as possible
[02:32] <fabbione> even if i don't fully understand the reason of this merge :-)))
[02:32] <Kamion> wouldn't it be a much newer version by default?
[02:32] <fabbione> imho it will make user's life more complicate with a bunch of extra kernel updates, only to change udebs
[02:32] <fabbione> Kamion: i didn't check.. i just had the flash while talking with you 3 seconds ago
[02:32] <Kamion> it's basically so that a kernel upgrade doesn't involve "build linux-source-2.6.8.1, wait, get Kamion to build linux-kernel-di-* so that the changes propagate to the installer"
[02:33] <fabbione> Kamion: yes.. i grok that :-)
[02:33] <Kamion> which can be important when we're doing stuff in a hurry, and mdz wants it for security uploads
[02:33] <fabbione> but on the other side
[02:33] <fabbione> "hey another kernel upgrade to fix the usb udev" ;)
[02:34] <Kamion> yep; I kind of regard that as "unlucky for running a development release"
[02:34] <Kamion> it'll be easier once our kernel package is in arch
[02:34] <fabbione> oh yeah...
[02:34] <fabbione> ehhehe
[02:34] <Kamion> then I can commit as I do stuff rather than uploading for every change
[02:36] <fabbione> linux-source-2.6.8.1-2.6.8.1$ kernel-wedge install-files
[02:36] <fabbione>         kernel-wedge copy-modules 2.6.8.1-3 386 2.6.8.1-3-386
[02:36] <fabbione>         kernel-wedge copy-firmware 2.6.8.1-3 386 2.6.8.1-3-386
[02:36] <fabbione>         kernel-wedge find-dups 2.6.8.1-3-386
[02:36] <fabbione> fabbione@gordian:/usr/src/wartydevel/kernel/linux-source-2.6.8.1-2.6.8.1$ 
[02:36] <fabbione> sweet :-)
[02:36] <Kamion> bonus :)
[02:36] <fabbione> let see what it did :-)
[02:36] <fabbione> impressing
[02:37] <fabbione> it's working :-)
[02:37] <fabbione> Kamion: probably later this evening...
[02:37] <fabbione> i was expecting more problems
[02:37] <Kamion> nifty, nice work
[02:42] <fabbione> xfs-modules-2.6.8.1-3-386-di_2.6.8.1-18_i386.udeb
[02:42] <fabbione> it almost work :-)
[02:43] <Kamion> that looks ok ...
[02:44] <fabbione> Kamion: yes.. all the udebs are ok...
[02:45] <fabbione> the debs aren't
[02:45] <fabbione> but it should be easy to do it nice and clean
[03:14] <zul> gday
[03:16] <pitti> die, evil ntp root privileges, die!
[03:16] <tseng> mmm, openntpd
[03:17] <tseng> privelage seperation + no listening by default
[03:17] <pitti> tseng: I just uploaded a new ntp package which lets ntpd run as normal user
[03:17] <tseng> mm, nice.
[03:17] <elmo> by day, pitti is just another programmer - but by night he turns into the DEROOTER - a shadowy figure fighting the wars others fear to wage, rooting out (har har) evildoers who retain priviledges they don't deserve
[03:19] <pitti> tseng: the funny thing is that it took me about half an hour to fix the code, and about one and a half to fix the broken init script handling
[03:19] <tseng> ew
[03:19] <smurfix> pitti: *sigh* yet more work for me.
[03:19] <tseng> so it now starts as root and drops?
[03:20] <fabbione> lol
[03:20] <pitti> smurfix: why, are you the Debian NTP team?
[03:20] <pitti> tseng: yes, it drops to ntp:ntp and only keeps CAP_SYS_TIME
[03:20] <smurfix> not quite "the", bu close.
[03:20] <fabbione> pitti: yes he is
[03:20] <tseng> great.
[03:20] <fabbione> smurfix: btw.. that mail about evdev
[03:20] <pitti> tseng: the code already kind of supported that, it just needed some tweaking
[03:20] <fabbione> smurfix: please discuss it either in ubuntu-devel or debian-x
[03:20] <pitti> tseng: the hard part was to get a smooth transition on package upgrading
[03:21] <fabbione> smurfix: i don't maintain X in ubuntu anymore :-D
[03:21] <smurfix> fabbione: OK
[03:21] <fabbione> smurfix: can't you see the difference yet?
[03:21] <fabbione> no caps lock..
[03:21] <fabbione> no irritation to my skin
[03:21] <sivang> fabbione : who is ?
[03:21] <sivang> :)
[03:21] <fabbione> i don't wake up yelling at the elfloader
[03:22] <fabbione> sivang: daniel the kid
[03:22] <smurfix> fabbione: the relevant changhelog entry was yours, though, so I thought maybe you'd feel responsible. ;-)
[03:22] <fabbione> smurfix: i did only one change to make it more flexible for certain corner cases
[03:22] <fabbione> smurfix: not as default protocol
[03:22] <fabbione> but you can discuss it
[03:23] <fabbione> with enough arguments you can convince daniels
[03:34] <pitti> smurfix: I sent the patch as a wishlist bug. Have fun with it :-)
[03:35] <smurfix> pitti: thanks. I guess. ;-)
[03:36] <Kamion> smurfix: one-handed typing> I don't want to know
[03:37] <smurfix> Kamion: read my blog... (or not)
[03:42] <daniels> smurfix: so!  evdev as default, eh?  sell me.
[03:44] <smurfix> daniels: (a) I like the ability to actually use the multiple buttons on mine.
[03:45] <daniels> smurfix: er, most people have working multi-button mice without evdev (by 'most people', I mean 'everyone not running Apple hardware')
[03:45] <smurfix> multi := >3
[03:47] <Kamion> smurfix: ouch :(
[03:47] <smurfix> my lowly Explorer has five and I didn't even have to configure $BROWSER to use the additional ones as back+forward
[03:47] <smurfix> Kamion: my thoughts exactly.
[03:47] <smurfix> Kamion: I thought you didn't want to know :-/
[03:50] <daniels> smurfix: so change to ExplorerPS/2
[03:50] <fabbione> daniels: evdev seems to autodetect that
[03:51] <fabbione> [debian-ntp]  Bug#282941: ntp-server: Please run ntpd as non-root
[03:51] <smurfix> daniels: why ask the poor user what mouse protocol he should use on his USB bus?
[03:51] <fabbione> tsk :-)
[03:52] <daniels> smurfix: yeah, I dunno whether it's safe for standard ImPS/2 or not; if it is, I'll make it the default
[03:52] <daniels> smurfix: unfortunately all I have here is my laptop, but if you want to do some research, it would be hugely appreciated (feel free to open a bug in Bugzilla, assigned to daniel.stone@canonical.com, status NEEDINFO)
[03:53] <daniels> smurfix: and yeah, I agree that asking a question like that is tremendously shit
[03:53] <smurfix> daniels: OK, will do.
[03:53] <daniels> cheers
[03:59] <smurfix> daniels: #4106
[04:00] <daniels> smurfix: thanks
[04:27] <fabbione> Kamion: testing a full build now :-)
[04:31] <fabbione> ccache orgy :-)
[04:43] <daniels> http://gstreamer.freedesktop.org/releases/gst-plugins/0.8.6.html <- polypaudio support
[04:44] <seb128> they have finally release 0.8.6 ?
[04:44] <daniels> yahuh
[04:45] <daniels> to be fair, they were blocked for about four or five days on fd.o
[04:46] <lifeless> rock
[04:47] <elmo> have polypaudio's problems been resolved?
[04:47] <daniels> elmo: not sure, but I would assume lack of a GStreamer sink would be one of them ...
[04:48] <daniels> fabbione: eh papa
[04:50] <fabbione> daniels: yes kid?
[04:51] <daniels> fabbione: wanna test the new nvidia packages?
[04:51] <daniels> fabbione: actually, wait until I merge the AGP patch -- nevermind
[04:51] <azeem> daniels: polypaudio can be transparently used as esound sink, no?
[04:51] <fabbione> daniels: not right now.. i am building a kernel package
[04:51] <azeem> now, a GStreamer source is something different, but AFAIK polypaudio handles that somehow as well
[04:52] <fabbione> UltraSPARC IV <- this is not supported by linux
[04:52] <fabbione> ops
[04:52] <daniels> azeem: unsure
[04:52] <daniels> fabbione: k
[04:56] <lamont> daniels: that died quickly yesterday...
[04:56] <fabbione> hey lamont 
[04:56] <lamont> (xort that is)
[04:56] <fabbione> lamont: the chroots that are building hoary/main are broken
[04:57] <fabbione> lamont: they manage to build gdb that build-dep on type-handling
[04:57] <fabbione> that is in universe
[04:58] <fabbione> lamont: btw.. good morning :-p
[04:58] <lamont> fabbione: is this a new gdb upload?
[04:58] <elmo> drow used type-handling?!
[04:58] <fabbione> lamont: it's a sync from debian
[04:59] <fabbione> E: Couldn't find package type-handling
[04:59] <elmo> dear god, what is the world coming to
[05:00] <daniels> lamont: yeah, there's a new one up there today
[05:00] <daniels> lamont: i told you you had to delete 000_stolen_from_fedora.diff :)
[05:00] <lamont> fabbione: gdb 6.3-4 predates the fix
[05:01] <lamont> daniels: missed that.  I can just regrab?
[05:01] <daniels> elmo: what does type-handling even do?
[05:01] <daniels> lamont: yah, same source version, lasted through clean builds on i386/powerpc/amd64
[05:01] <daniels> (in reverse order of speed to compltee)
[05:01] <fabbione> lamont: ok
[05:01] <fabbione> lamont: thanks for checking
[05:04] <lamont> daniels: build running
[05:05] <daniels> lamont: thanks dude
[05:05] <lamont> fabbione: there was a bug in the ogre-model implementation.  damn perl.
[05:05] <lamont> (fixed 23 nov)
[05:10] <fabbione> lamont: ogre-model?
[05:12] <Kamion> fabbione: seen Shrek?
[05:12] <fabbione> yes
[05:12] <Kamion> onions
[05:12] <fabbione> but i have seen it in italians
[05:12] <fabbione> ah ok
[05:13] <fabbione> so ogre-models is like onions and orks.. they have layers :P
[05:13] <lamont> fabbione: that, and it's smelly
[05:13] <fabbione> ehhe
[05:14] <daniels> elmo: could I please get linux-restricted-modules build-deps on concordia?
[05:19] <elmo> daniels: done
[05:19] <daniels> elmo: cheers
[05:20] <daniels> shitting hell, the l-r-m build goes into an infinite loop if it fails
[05:20] <thom>  "From: psychoelmo <psychoelmo@gmail.com>" *giggle*
[05:20] <thom> elmo: is that your pseudonym these days?
[05:20] <daniels> heh
[05:21] <lamont> Applying patch
[05:21] <lamont> +debian/patches/024_ati_r128_and_radeon_enable_build_without_vgahw.diff ...
[05:21] <lamont> +failed! (check
[05:21] <lamont> +stampdir/log/patches/024_ati_r128_and_radeon_enable_build_without_vgahw.diff
[05:21] <lamont> +for reason)
[05:21] <fabbione> why am i not surprised?
[05:21] <fabbione> daniels: let me guess
[05:21] <zul> its ati...go figure
[05:21] <fabbione> you renamed 020 to 025
[05:22] <fabbione> and not done a patch-audit
[05:22] <daniels> fabbione: dude, ease off it, will you?
[05:22] <fabbione> daniels: tell me if i am right or not..
[05:22] <fabbione> ;)
[05:22] <lamont> 8 out of 12 hunks FAILED -- saving rejects to file xc/programs/Xserver/hw/xfree8
[05:22] <lamont> 6/drivers/ati/radeon_driver.c.rej
[05:23] <lamont> elmo: elilo-installer/ia64 needs some unknown-love.
[05:23] <daniels> that's exactly what I copied to concordia and davis
[05:23] <daniels> fabbione: actually, you're wrong
[05:26] <fabbione> daniels: good :-)
[05:27] <fabbione> daniels: if what you have around is the same as what is in baz, here they all apply ok
[05:28] <daniels> fabbione: yeah, that one had to be updated because benh's patch lets you configure vgahw or not at runtime also
[05:28] <daniels> fabbione: so presumably after I did it, I copied to concordia and davis, but not rookery
[05:29] <fabbione> daniels: can you give the changelog some love before uploading please?
[05:30] <eruin> what's herbert xu's nick?
[05:30] <daniels> eruin: he doesn't IRC
[05:30] <thom> he doesn't use irc afaik
[05:30] <fabbione> eruin: afaik he doesn't irc
[05:30] <daniels> fabbione: it's not final, more stuff will change before then
[05:30] <eruin> crap, and I wanted to whine about nvidia6629 ;)
[05:31] <daniels> apparently 6629 is known broken
[05:31] <daniels> (says the man who doesn't own any nvidia hardware)
[05:31] <eruin> hmm, gotta google that.. they work fine here
[05:32] <fabbione> eruin: the problem seems to affect certain AGP busses
[05:32] <daniels> eruin: there's a patch on some forums somewhere supplied by an nvidia dude that I'm testing
[05:32] <fabbione> in specific conditions
[05:32] <fabbione> eruin: that makes it no no for us
[05:32] <daniels> 'testing' -> 'beating at until the package builds with it, then releasing to suck^Wtesters'
[05:32] <eruin> :D
[05:33] <lamont> hrm.. thumb cuffs for $6.99...
[05:33] <eruin> owell, as long as I have these alienified ooo1.9 debs installed 'm happy
[05:35] <_rene_> erm, you don't need to installl alienated debs when there are "normal" debs...
[05:35] <eruin> of 1.9?
[05:35] <_rene_> yes
[05:35] <eruin> and where might those be?
[05:35] <daniels> lamont: ...
[05:36] <_rene_> eruin: read debian-openoffice
[05:36] <lamont> it's a fun catalog, you see..
[05:36] <_rene_> eruin: http://lists.debian.org/debian-openoffice/2004/11/msg00216.html
[05:37] <shaya> how is one supposed to use smbmount if it cant be suid root?
[05:37] <shaya> used to always just smbmount as a regular user
[05:38] <eruin> _rene_: ah, yeah, I'm using those.. synaptic dupes them "alienated"
[05:38] <_rene_> ah. probably because you installed them with dpkg -i etc
[05:39] <eruin> what's the diff between java and nonjava?
[05:39] <haggai> eruin: the nonjava is a build without java support
[05:39] <_rene_> the java one ist built with java support, the other one is without ;-)
[05:39] <eruin> okay, I was foolishly thinking gtk
[05:40] <rburton> has oo.o 1.9 got anything really cool?
[05:41] <eruin> somehow the ooo1.9 I have on my fedora partition blend in with the rest of my gnome desktop, whereas these don't
[05:41] <eruin> well, .oot support
[05:41] <eruin> :)
[05:41] <rburton> .oot?
[05:41] <_rene_> the new file format :)
[05:41] <eruin> the new default format
[05:41] <rburton> ah
[05:42] <haggai> eruin: that's because I didn't enable the gtk or kde plugins yet
[05:42] <tseng> 1.1.3 is being built for hoary now
[05:42] <tseng> which has some of the visual improvements
[05:42] <eruin> all my old docs from my windows days are in .oot, that's why I need it :)
[05:42] <eruin> tseng: no oot support I suppose?
[05:42] <_rene_> err? this must be a different oot?
[05:42] <tseng> not afaik
[05:42] <haggai> what is oot?
[05:43] <_rene_> the new OASIS format
[05:43] <haggai> ah, yeah
[05:43] <eruin> _rene_: nah, I used an ooo1.9 release there too
[05:43] <_rene_> ah
[05:43] <_rene_> ok
[05:43] <haggai> eruin: oot format is scheduled for 1.1.5 I believe
[05:43] <azeem> "old docs from my windows days" <- IT landscape is moving fast these days, huh?
[05:43] <_rene_> tseng: there are rumours 1.1.5 will have backported support for OASIS
[05:45] <eruin> what does ooo use anyway? for the interface I mean
[05:45] <tseng> it has its own toolkit
[05:45] <_rene_> an own toolkit
[05:45] <tseng> its just being modified recently to emulate native toolkits
[05:46] <eruin> yeah, .56 milestone seemed to do that, while the one I'm running, .62 looks butt-ugly ;)
[05:47] <_rene_> you have to enable it during configure
[05:47] <_rene_> and the resulting stuff then of course is linked against gtk and kde/qt...
[05:47] <eruin> damn me for using those debs then
[05:48] <_rene_> tose debs in  no way have the usual quality. they are just made from a stock upstream build ;)
[05:48] <eruin> time to lobby the maintainer ;>
[05:48] <_rene_> erm? you are talking with them atm...
[05:49] <eruin> eek
[05:49] <eruin> you do the ones at ~halls/ ?
[05:49] <_rene_> haggai does
[05:50] <eruin> oooh haggaaii?
[05:50] <shaya> cant let security get in my way
[05:55] <haggai> eruin: as I said in the mail, it was a first cut and there's lots to improve on
[05:55] <haggai> eruin: I was just happy to have any .debs at all.. and many people asked for them so I put them up as they were
[05:56] <haggai> eruin: I'll turn on the gtk & kde interfaces for my next build, ok?
[05:56] <shaya> haggai: debs of what?
[05:56] <eruin> haggai: that'd be great! :)
[05:56] <haggai> shaya: openoffice 1.9.62
[05:56] <shaya> open office
[05:56] <shaya> aren't there gtk/kde interfaces in debian already?
[05:56] <eruin> for 1.1
[05:56] <haggai> shaya: we're talking about 1.9.x
[05:57] <_rene_> shaya: if you count experimental.. ;)
[06:01] <daniels> pitti: ah, dude!  want to test out a new radeon_drv?
[06:01] <daniels> thom: what sort of machine is your radeon in?
[06:01] <pitti> daniels: sure
[06:01] <thom> daniels: amd64
[06:02] <pitti> daniels: can you please mail it to me?
[06:02] <daniels> pitti: jah
[06:02] <pitti> daniels: I'm in a hurry, gotta go soon
[06:02] <daniels> pitti: sure thing
[06:02] <daniels> thom: dvi, yeah?  did it Just Work beforehand?
[06:02] <pitti> daniels: fixed the vga out?
[06:02] <daniels> pitti: hopefully!
[06:03] <daniels> thom: if you wouldn't mind giving http://people.ubuntu.com/~daniels/xorg/amd64-radeon_drv.o a spin, that'd be rad
[06:03] <tseng> daniels: whats different about it?
[06:03] <tseng> daniels: ill give it a try.
[06:04] <tseng> oh sorry.. missed the 64.
[06:04] <daniels> tseng: lots of fixups from benh
[06:04] <daniels> tseng: http://people.ubuntu.com/~daniels/xorg/i386-radeon_drv.o
[06:04] <daniels> basically, with a bare-bones (i.e. no special options) config file, every single configuration should be detected
[06:04] <shaya> daniels: what's in there?
[06:04] <tseng> mm, nice.
[06:05] <daniels> shaya: basically, you shouldn't ever need to specify any wacky options
[06:05] <daniels> every display you have connected should just come up and work
[06:05] <shaya> daniels: faster/slower or just options?
[06:05] <tseng> ill test on laptop w/ crt
[06:05] <daniels> shaya: just options, no optimisations iirc
[06:05] <tseng> and no layout options
[06:05] <shaya> oh well
[06:05] <daniels> http://people.ubuntu.com/~daniels/xorg/xorg_6.8.1-1ubuntu4_source.changes <- changelog
[06:06] <daniels> it's the 'break benh's radeon_drv challenge'
[06:07] <thom> brb, hopefully
[06:07] <tseng> daniels: works for me
[06:07] <tseng> w/o monitor_layout
[06:08] <daniels> tseng: :D
[06:08] <tseng> before it would mess up the top edge of the screen on the CRT
[06:09] <daniels> rooooooockin
[06:10] <tseng> unrelated X question
[06:10] <tseng> when i do something with direct rendering, like playing a dvd
[06:10] <tseng> it doesnt show up on the crt
[06:10] <tseng> can i config-fu something?
[06:10] <daniels> right, you need to set the overlay to the other crtc
[06:10] <daniels> hold on a sec
[06:11] <daniels> try Option "MergedFB"
[06:12] <tseng> i tried that once and got crap
[06:12] <daniels> is it any better now? ;)
[06:12] <tseng> funny rainbow colors and no X
[06:12] <daniels> heh
[06:13] <smurfix> daniels: I'll try the thing too, I need to reboot anyway
[06:13] <tseng> Option "MergedFB"   "true"
[06:14] <tseng> no hung X, but no video on crt either
[06:14] <daniels> so you just get a colourkey, or blank?
[06:15] <tseng> black square in totem
[06:15] <thom> daniels: close, but no cigar
[06:15] <daniels> thom: oh?
[06:16] <daniels> tseng: hm
[06:16] <thom> oh, hrm
[06:16] <fabbione> Kamion. IT WORKS ! IT WORKS!.. at least.. it builds fine...
[06:16] <thom> maybe i should specify some options for the second head
[06:16] <thom> like res and xinerama?
[06:16] <daniels> tseng: i suspect the only way you'll get it is with Xinerama + MergedFB, and moving the video on the second head
[06:17] <daniels> tseng: of course, we could write a tiny utility to just set OV0_CRTC_SEL
[06:17] <tseng> hm
[06:17] <daniels> thom: probably, if they're different resolutions
[06:17] <daniels> thom: if you select a res which both heads are capable of, it should work tho
[06:17] <daniels> thom: mergedfb may be a plus here
[06:18] <Kamion> fabbione: hooray
[06:19] <fabbione> Kamion: http://people.ubuntulinux.org/~fabbione/linux-source-2.6.8.1_2.6.8.1-18_i386.changes
[06:19] <fabbione> i just need to add one entry in the changelog
[06:19] <fabbione> and you to test on ppc
[06:19] <Kamion> guess I can kiss goodbye to my CPU time for a time
[06:19] <Kamion> a bit
[06:19] <fabbione> i386 is easy because it has only one kernel image used for d-i
[06:19] <fabbione> Kamion: run it at night
[06:20] <Kamion> fabbione: do I get the source as well as the .changes? :)
[06:21] <elmo> kamion: you can't reconstruct the .diff.gz from the md5sum?? lamer
[06:21] <Kamion> oh yeah, I forgot I could trivially crack any md5sum-signing scheme, silly me
[06:22] <fabbione> Kamion: yeah hold on :-)) i am preparing an interdiff
[06:22] <fabbione> start getting -17
[06:25] <fabbione> Kamion: http://people.ubuntulinux.org/~fabbione/17_to_18.diff
[06:25] <fabbione> the patch is big due to importing all the d-i stuff
[06:26] <fabbione> but the changes to the relevant files are contained
[06:31] <Kamion> fabbione: is ignoring errors from kernel-wedge check a good idea?
[06:31] <Kamion> I'd rather the build failed if that breaks
[06:32] <fabbione> Kamion: it breaks on unrelated packages like linux-headers
[06:32] <fabbione> because they are sometimes empty
[06:32] <fabbione> and kernel-wedge bitches about it
[06:32] <Kamion> heartbeat?
[06:32] <Kamion> hm, should just fix kernel-wedge for that
[06:32] <Kamion> but ok, later stage
[06:33] <fabbione> Kamion: yeah... reading the patch... driving you crazy... dieing slowly in front of your pc :P
[06:34] <Kamion> heh
[06:35] <Kamion> fabbione: I'm not sure shipping debian/control in its current condition is a good plan
[06:35] <Kamion> lots of i386-specific generated stuff in it
[06:37] <fabbione> Kamion: debian/control is regenerated everytime from control.stub
[06:37] <fabbione> if you were building it from amd64 or ppc would have been the otherway around
[06:37] <Kamion> yeah, I know that
[06:38] <Kamion> I think it might be better to save the ungenerated version
[06:38] <Kamion> and restore it in clean
[06:38] <Kamion> anyway, building
[06:38] <fabbione> i did use the same way as -di- but yes it can be done
[06:38] <fabbione> that's also why i call debian/control also in clean
[06:39] <fabbione> so it gets updated immediatly
[06:39] <fabbione> Kamion: have fun :-)
[06:40] <fabbione> i am off for today
[06:42] <smurfix> daniels: the radeonfb from ~daniels/xorg/i386-radeon_drv.o still kills my monitor
[06:43] <daniels> smurfix: hmmmmm
[06:44] <daniels> smurfix: what setup are you running?
[06:45] <smurfix> daniels: radeon 9600, one TFT display on its digital output.
[06:47] <smurfix> Putting it on analog gets me a "you exceed my timing parameters, go away" display instead of a "I'm told to shut down so I'll go away" message on the TFT.
[06:48] <smurfix> lspci -n:
[06:48] <smurfix> 0000:01:00.0 0300: 1002:4150
[06:48] <smurfix> 0000:01:00.1 0380: 1002:4170
[06:50] <daniels> smurfix: so plugging it into your VGA port breaks, but plugging it into your DVI port works?
[06:50] <smurfix> No, both break
[06:50] <smurfix> just differently.
[06:51] <daniels> does commenting out your HorizSync/VertRefresh lines, and commenting out the Option "DPMS" line, in the Monitor section, have any effect?
[06:53] <smurfix> daniels: I'll try ...
[06:54] <Mitario> hullo everyone
[06:56] <eruin> would any of you have a script to recursively print md5sums of a directory to a text file
[06:56] <daniels> eruin: touch foo && for i in $(find ./ -type f); do md5sum $i >> foo; done
[06:57] <eruin> thankyou :)
[06:59] <Keybuk> daniels: find . -type f | xargs md5sum > foo
[06:59] <daniels> Keybuk: meh
[07:02] <eruin> man I need to man find
[07:05] <eruin> daniels: can I ask you for another one? the find pattern to match all *~ files ? :P
[07:06] <tseng> -iname *~ ?
[07:06] <smurfix> daniels: nope
[07:07] <smurfix> daniels: same result. I can send you the xorg.log if that'd help.
[07:07] <eruin> tseng: cheers ;)
[07:10] <Kamion> fabbione: yeah, linux-kernel-di-* is different because it's only one architecture per source package
[07:11] <Kamion> tseng: just -name will do there
[07:11] <tseng> ya
[07:11] <tseng> i always use -iname out of habit
[07:22] <daniels> fabbione: have you got a link to the agp problems?
[07:22] <daniels> smurfix: er yeah, thanks
[07:22] <spotter> is there a good reason why pgp4pine is in multiverse, but pine isn't?
[07:22] <smurfix> daniels: daniel.stone@canonical ?
[07:27] <daniels> smurfix: yah
[07:28] <smurfix> daniels: sent.
[07:28] <daniels> ta
[07:33] <daniels> smurfix: try removing the HorizSync and VertRefresh lines
[07:33] <daniels> if that fails, remove the DPMS line
[07:33] <daniels> (all Section "Monitor")
[07:35] <smurfix> daniels: you're looking at the wrong Monitors section
[07:35] <smurfix> daniels: you want the one named "Test"
[07:35] <smurfix> daniels: iow, they already are commented off
[07:38] <daniels> smurfix: bah
[07:38] <daniels> what about if you take out all the custom modelines?
[07:40] <RubenV> is there an ubuntu specific anacron maintainer?
[07:40] <smurfix> I can do that. They did work a few months ago, so I kinda doubt that'll change anything. But I'll try.
[07:40] <bob2> RubenV: no
[07:40] <RubenV> i've just made a quick patch to add lsb functions to the init script
[07:40] <daniels> smurfix: so was it working right before you upgraded radeon_drv?
[07:40] <bob2> RubenV: send it to debian's bts
[07:41] <Kamion> bob2: no, don't
[07:41] <Kamion> RubenV: lsb functions are Ubuntu-specific, please file them in our BTS
[07:41] <RubenV> bob2: do they accept those?
[07:41] <RubenV> thought so
[07:41] <RubenV> ok, coming up
[07:41] <RubenV> it's just a quick fix though
[07:41] <bob2> oh, oops, the lsb pretty printing thing
[07:42] <smurfix> I was working up until ~three months ago, with the xfree that's no longer in Sarge either.
[07:42] <eruin> find relies on having an uptodate db
[07:43] <smurfix> daniels: s/I/It
[07:43] <eruin> ?
[07:43] <daniels> smurfix: with XFree86 4.2.1?
[07:43] <RubenV> hmmm
[07:43] <RubenV> no anacron module?
[07:43] <RubenV> i'll just put it under cron then
[07:44] <smurfix> daniels: probably. I didn't actually reboot for a long time and then was way too busy to reboot the system all the time to narrow the problem down. :-/
[07:44] <daniels> smurfix: could you please email the log from a working setup (preferably one with CRT, one with TFT) to benh@kernel.crashing.org, complete with your config and a quick description of the problem, and mention that it's broken both with 6.8.1's radeon_drv, and the patch that he sent me last night?  cc me as well please
[07:44] <daniels> smurfix: heh
[07:44] <daniels> smurfix: well, if you could get an email off, that would be great
[07:45] <smurfix> daniels: yeah, I'll have to dig up an older xfree from Snapshots and all that, but apparently there's no fucking way around doing the work. :-/
[07:45] <smurfix> (so what else is new)
[07:46] <daniels> smurfix: yeah
[07:46] <daniels> smurfix: oh, for the email, he doesn't need a working log -- just a broken one should be sufficient
[07:46] <RubenV> https://bugzilla.ubuntu.com/show_bug.cgi?id=4118
[07:46] <RubenV> gonna be cleaning up some more init scripts
[07:46] <RubenV> just to contribute something
[07:47] <smurfix> daniels: OK, that does limit the effort somewhat ;-)
[07:52] <Kamion> RubenV: don't put it under cron please
[07:52] <Kamion> RubenV: if there's no appropriate package, use UNKNOWN
[07:52] <smurfix> galeon is broken in hoary. It's linked to nautilus.so.2 which the latest update renamed to nautilus-private. :-/
[07:52] <RubenV> Kamion: aw, sry, too late :s
[07:52] <smurfix> s/nautilus/libnautilus/g
[07:53] <Kamion> RubenV: reassigned
[07:53] <RubenV> doing the alsa script now
[07:53] <RubenV> that does have a pkg :)
[08:15] <RubenV> voila, no more ugly starting ALSA
[08:15] <RubenV> and now it's time for some studying
[08:23] <__daniel> hai
[08:34] <Mithrandir> thom: I think I found a bug in apache.  wrt multiviews.
[08:44] <azeem> in theory, I could go an sell Ubuntu-CDs via the web, right?
[08:45] <tseng> sure
[08:45] <RubenV> as long as you obey the gpl
[08:45] <RubenV> i think :)
[08:45] <zul> he isnt modifying or removing the license
[08:46] <bob2> yes, but he is distributing gpl code
[08:46] <zul> oh yeah..duh
[08:48] <tseng> ew @ openoffice 1.1.3
[08:49] <RubenV> ?
[08:49] <tseng> fails on missing kdelibs4-dev
[08:49] <_rene_> hehe
[08:49] <_rene_> we had that discussion this afternoon
[08:50] <__daniel> OOo depends on kdelibs?
[08:50] <_rene_> openoffice.org-kde does
[08:50] <_rene_> and so the source build-deps on kdelibs4-dev
[09:09] <Md> I'm trying to understand how udev-udeb is being used. I see no init script in the package and no postinst to create the rules. who knows more?
[09:10] <Md> I can't remember Colin Watson's nick
[09:10] <Kamion> Md: that's me
[09:10] <Kamion> Md: it's all still in development and wildly unsuitable for sarge, which is why I haven't sent the patches back yet
[09:10] <Kamion> Md: rootskel does all the init work
[09:11] <Md> Kamion: I started merging some parts of it, feel free to send any kind of patches or comments
[09:11] <Kamion> ok, fair enough, but I think it would be a good idea to keep it out of sarge; I'm scared what would happen if udev-udeb showed up in the debian-installer Packages file
[09:11] <Astharot> hi Md :)
[09:11] <Kamion> something might decide to install it :)
[09:12] <Md> BTW, you don't need -pudev for dh_link because it's the default and you don't need -a for dh_installdirs because all debian/*.dirs files are always processed anyway
[09:12] <Kamion> Md: rootskel pretty much has to have control of the early init process in d-i - it's too custom
[09:12] <Kamion> Md: yeah, that's true
[09:12] <Kamion> I think I thought the former was clearer despite the default
[09:12] <Md> Kamion: yes, I'm just adding some code to debian/rules but the package will not be generated by default
[09:12] <Kamion> ok, cool
[09:12] <Kamion> at some point soon I'll be mailing debian-boot and all the affected maintainers with the work I've done
[09:13] <Md> do you have an URL for the rootskel file which deals with the rest?
[09:13] <Kamion> but I don't want to distract too much from sarge with shiny things
[09:13] <amu> do we have a kernel with benh's sleep-support for a G4 ? 
[09:13] <Kamion> amu: afraid not
[09:13] <Kamion> Md:    libiw27 |       27-1 |       testing | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
[09:13] <Kamion> oopd
[09:13] <Kamion> Md: http://archive.ubuntu.com/ubuntu/pool/main/r/rootskel/rootskel_1.09ubuntu3.dsc
[09:14] <Kamion> I put it next to the existing devfs code
[09:15] <amu> Kamion: stupid question, why not?  
[09:15] <Kamion> amu: no kernel maintainer for hoary right now
[09:16] <Md> Kamion: /.dev is definitely not necessary for d-i
[09:16] <daniels> amu: that's an update to 2.6.9 + the patch
[09:16] <Kamion> Md: noted, will fix
[09:16] <amu> ubuntu-ppc without sleep, is like you go undressed to bed :( 
[09:16] <Kamion> I wasn't sure
[09:18] <amu> daniels: no prob with it, just woundert is there something like this atm
[09:19] <Kamion> Md: is it likely to be possible to use udev without having hotplug at all? it would be nice to be able to switch Debian over one step at a time rather than all at once
[09:20] <Md> Kamion: you need at least /sbin/hotplug. what's wrong with the rest of the program, anyway?
[09:20] <lucas_> hi
[09:20] <Kamion> switching d-i to hotplug is non-trivial; it requires an overhaul of the hardware detection architecture
[09:20] <Kamion> I'm working on it but it's not the work of five minutes
[09:21] <Md> Kamion: oh, you mean coldplugging. it's not mandatory, look at the init script to see how to disable it
[09:21] <Kamion> we could certainly install some kind of dummy /sbin/hotplug in the meantime
[09:21] <Md> Kamion: /sbin/hotplug does nothing by itself, look at it
[09:21] <Kamion> I know, I've been looking at it and friends for much of today :)
[09:22] <Kamion> it can't be called /sbin/hotplug in d-i incidentally, for annoying reasons
[09:22] <Md> like?
[09:22] <Kamion> we have to activate it only after pivot_root
[09:22] <Kamion> if you call it /sbin/hotplug then udevd gets started up in the first initrd and prevents it being unmounted
[09:23] <Kamion> I ran into that straight away
[09:23] <Kamion> so I just call it /sbin/hotplug.real instead and echo that into /proc/sys/kernel/hotplug shortly after pivot_rooting
[09:23] <Md> so don't put it in the first initrd... what am I missing? or make it just exit if everything it needs is not there
[09:24] <Kamion> you have to put it in the first initrd, or you don't get it until after the first round of hardware detection
[09:24] <Kamion> d-i has no way to install additional udebs until then
[09:25] <lucas_> Kamion: how big is a full ubuntu mirror ? debmirror is broken, so I need to get everything. but I'm not sure if it will fit on my disk.
[09:25] <Md> then I think it should be patched to exit until the environment is OK, it looks simpler
[09:25] <Kamion> how should it tell?
[09:26] <Kamion> there is no significant difference in the filesystem between before pivot_root and after, apart from /dev being populated
[09:26] <Md> [ -e /some/file ]  || exit 0
[09:26] <Md> at worst you will have to create a flag file
[09:26] <Kamion> the first initrd is copied wholesale to the ramdisk
[09:26] <Kamion> I think I prefer the current approach TBH, it's easier to understand and doesn't seem fragile
[09:27] <Md> I find easier to understand *my* approach :-)
[09:27] <Kamion> if I patch /sbin/hotplug then that patch needs to be on the real system as well - I don't want the code to differ between deb and udeb
[09:28] <Kamion> so a flag file doesn't sound like an option ...
[09:28] <Md> that's OK, I maintain hotplug and can do this :-)
[09:28] <Kamion> oh, I thought that was ukai
[09:29] <Md> I'm the co-maintainer
[09:29] <Kamion> ah
[09:30] <lucas_> ***lucas@ubuntu2:/space/ubuntu-mirror/pool$ ls -l universe/x/xmms-liveice/xmms-liveice_1.0.0-6_i386.deb
[09:30] <lucas_> lrwxrwxrwx    1 lucas    lucas          72 Nov 25 13:55 universe/x/xmms-liveice/xmms-liveice_1.0.0-6_i386.deb -> ../../../../pool/multiverse/x/xmms-liveice/xmms-liveice_1.0.0-6_i386.deb
[09:30] <Kamion> hm, speaking of, a hook in hotplug to allow feeding back module names to whatever's calling the rc scripts would be really nice ... :-)
[09:30] <Kamion> but, looking at the code, it seems very non-trivial to add such a hook
[09:30] <lucas_> there are symlinks looping to themselves on the archive :/
[09:30] <Md> Kamion: what?
[09:30] <Kamion> lucas_: I believe something on the wiki tells you
[09:30] <Kamion> Md: look at how hw-detect interacts with discover and you'll understand
[09:31] <Kamion> Md: especially the bit that allows the user to enter module parameters for each module that's going to be loaded
[09:31] <Md> the major problem with hotplug is that it should be completely rewritten to remove all compatibility code for 2.2 and 2.4 kernels...
[09:31] <Kamion> lucas_: my warty+hoary mirror for amd64+i386+powerpc is just over 10GB
[09:31] <mdz> Md: also the udev race conditions seem to need hotplug changes to be fixed
[09:31] <Md> Kamion: module parameters are managed by modprobe, not hotplug
[09:31] <Md> mdz: which race?
[09:32] <Kamion> Md: there is no way for d-i to know in advance what modules are going to be loaded so that it can ask
[09:32] <lucas_> Kamion: ok, thanks
[09:32] <mdz> Md: between the completion of the modprobe process and the creation of the device node
[09:32] <mdz> so that modprobe <module> && work with /dev/foo works as expected
[09:32] <Md> mdz: it will never be fixed, there is no easy way to do it and the maintainer says to use dev.d
[09:33] <Kamion> Md: I would like to be able to know when each module is going to be loaded so that I can ask the user if they want to supply any options to it, basically
[09:33] <Kamion> Md: we can do this with discover because it just gives back a list of module names it wants rather than loading them itself
[09:33] <Md> Kamion: I see your point, but if users know that some modules need options they probably know their names as well
[09:33] <Kamion> Md: there's nowhere for d-i to ask that though
[09:33] <Kamion> Md: people could drop to a terminal and do it, but that's hardly acceptable UI
[09:34] <Md> Kamion: I think this could be added to hotplug without too much work, BTW
[09:34] <mdz> Md: that works for some cases, but not others
[09:34] <Md> Kamion: there is no reason to use a terminal
[09:34] <mdz> pppd, for example, doesn't make sense as a dev.d script
[09:34] <Kamion> how should people add options in the context of d-i then?
[09:35] <Md> Kamion: you present users with a dialog with input fields for a module name and its options
[09:35] <Kamion> Md: in debconf? good luck
[09:35] <Md> mdz: OTOH in this case you already know the device name
[09:36] <Kamion> mdz: /lib/debian-installer-startup.d/S40framebuffer-module-linux-x86 is another example
[09:36] <Kamion> I've had several cases recently where /dev/fb/0 simply never appeared
[09:36] <Kamion> it's as if the event vanished somewhere between hotplug and udev
[09:36] <mdz> Md: true, but polling waiting for the device node to appear is such a hack
[09:36] <Kamion> but I haven't been able to reproduce it reliably enough to debug it; it seemed to go away when I started poking at it
[09:37] <Md> mdz: agreed. but I'm not going to fight this anymore, you people should subscribe to the linux-hotplug mailing list
[09:37] <mdz> Md: I wish I could follow the mailing lists for every project that I work with, but unfortunately it is too much
[09:39] <Kamion> the problem with using /etc/dev.d for the framebuffer stuff is that checking to see whether /dev/fb/0 has appeared seems to be about the only reliable way to tell whether the framebuffer module loaded properly or not
[09:40] <Kamion> particularly with vesafb and vga16fb; they can load and then not work
[09:40] <Kamion> so /etc/dev.d doesn't really work; you still have to say "we're going to wait for a while to see if this worked, otherwise give up" :-(
[09:40] <Md> BTW, you should use "sleep 0.1" instead of "sleep 1"
[09:41] <Kamion> is that implemented in busybox?
[09:41] <Md> if it works in busybox
[09:41] <Kamion> it doesn't seem to be
[09:42] <Kamion> it just uses sleep(3)
[09:42] <Kamion> I would certainly prefer finer granularity
[09:42] <Kamion> then again, it seems to take as long as five or six seconds for the device to appear on my test laptop
[09:43] <Kamion> I'd love to know what the system is doing for that time
[09:43] <Md> me too. in this case I find hard to blame fb brokeness on udev :-)
[09:43] <Kamion> oh, I'm not blaming udev exclusively, but it does make things harder to follow that's all :-/
[09:44] <Kamion> still, getting rid of devfs *was* nice
[09:45] <Md> it was a bad idea from the start to use devfs for hardware detection, but nobody listened...
[09:45] <Kamion> nothing else was available at the time
[09:45] <Kamion> for d-i, that is
[09:45] <Md> it was a bad idea to not target 2.6 kernels from the start as well :-)
[09:45] <Kamion> you do realise d-i development started four years ago right?
[09:45] <Md> yes
[09:46] <Kamion> it's not good strategy to develop for a kernel you can't run yet :)
[09:46] <Md> maybe not from the start, but one year ago
[09:46] <doko> elmo: please sync openoffice.org-debian-files, when openoffice.org 1.1.3 enters hoary
[09:46] <Kamion> could be; we've been gradually moving over
[09:47] <Kamion> my experience so far certainly tends to support my opinion that moving to udev/hotplug in a hurry would not have been a good idea from a stability/permanent-releasability point of view
[09:47] <smurfix> Md: even half a year ago I wouldn't have depended on 2.6 exclusively.
[09:47] <Kamion> I'm somewhat worried for hoary actually; I'd much prefer if we were getting the massive attention that d-i changes in Debian get, for a change this sweeping
[09:47] <Kamion> but we're committed to it
[09:48] <Kamion> mdz: oh, do you mind if I add pciutils-udeb, usbutils-udeb, and libusb-0.1-udeb? I need pci.ids and usb.ids now that discover1-data is no longer around to provide the names of network interfaces for netcfg's UI
[09:48] <Kamion> mdz: which I had totally not thought about in advance
[09:48] <azeem> Kamion: joeyh said you will open up the d-i branch for etch soon, so if you merge it early, you'll get enough testing there as well, hopefully
[09:48] <azeem> you == the d-i guys
[09:49] <Kamion> mdz: and getting lspci and lsusb will probably be a bonus for debugging purposes, too
[09:49] <Kamion> azeem: yeah, I'm very much hoping so
[09:52] <Kamion> azeem: I have a number of other changes I want to merge, but which are too untried for sarge
[09:53] <azeem> sweet
[09:59] <fabbione> Kamion: how is the build going?
[10:02] <Kamion> make[1] : Entering directory `/home/cjwatson/src/ubuntu/linux-source-2.6.8.1/linux-source-2.6.8.1-2.6.8.1/debian/build/build-power4-smp'
[10:02] <Kamion> The changelog says we are creating 2.6.8.1, but I thought the version is 2.6.8.1-3-power4-smp
[10:02] <Kamion> make[1] : *** [stamp-debian]  Error 1
[10:02] <Kamion> oh, damnit, I probably need Ubuntu's kernel-package
[10:03] <fabbione> argh.. yes
[10:03] <Md> ROTFL! I just noticed that the new udev makefile prints init-style green "[OK] " labels instead of the whole command line
[10:03] <fabbione> Md: green? it's white here
[10:03] <fabbione> ahh
[10:04] <fabbione> never miind
[10:09] <Kamion> fabbione: trying again, off to the pub now
[10:09] <fabbione> Kamion: have fun :-)
[10:27] <elmo> doko: nothing to sync?
[10:38] <doko> elmo: ahh, ok, from experimental, or should this be directly uploaded?
[10:43] <Mithrandir> fabbione: pong?
[10:44] <fabbione> ehehe
[10:44] <fabbione> Mithrandir: #debian-women
[10:44] <fabbione> i was trying to convice your gf to build a kernel for me :-P
[10:44] <Mithrandir> hehe :)
[10:44] <Mithrandir> what arch?
[10:44] <fabbione> amd64
[10:45] <Mithrandir> I don't think she has an account on any amd64 box
[10:45] <fabbione> we need to fix this, don't we? ;)
[10:45] <fabbione> well it's easy
[10:45] <Mithrandir> she just doesn't have any account on my home box, is that so weird? :)
[10:45] <fabbione> just grab linux-source-2.6.8.1<whatever>-17.d*
[10:46] <fabbione> Mithrandir: apply this: http://people.ubuntulinux.org/~fabbione/17_to_18.diff
[10:46] <fabbione> and build
[10:46] <fabbione> it needs to be done in hoary
[10:47] <fabbione> even if you tell me in 2 days or tomorrow late evening if it works, it will be more than fine
[10:47] <Mithrandir> applied against what kernel source?
[10:49] <fabbione> Mithrandir: we have only one
[10:49] <fabbione> that applied to the entire package
[10:49] <fabbione> linux-source-2.6.8.1-2.6.8.1
[10:50] <Mithrandir> yeah, but my DSL is only at about 260KB/sec atm.
[10:50] <fabbione> yeah don't worry...
[10:51] <fabbione> even tomorrow is fine
[10:52] <fabbione> brb
[10:55] <jdub> doko: can we remove the kde depends/packages from OOo in the mean time, before haggai and _rene_ add their optional foo?
[10:58] <doko> jdub: I'll have a look, but maybe let's wait for the first problem reports before the next upload.
[10:59] <jdub> doko: if it depends on kdelibs4-dev, it won't build.
[10:59] <jdub> doko: OOo is sitting there happily not building.
[10:59] <jdub> doko: so i have a problem report and a solution for you ;-)
[11:03] <seb128> jdub: how is flumotion package going ? thomasvs was asking about it
[11:03] <jdub> seb128: haven't spent time on it since the initial packaging - have to upgrade and upload.
[11:04] <elmo> doko: synced
[11:04] <jdub> seb128: will probably do it over the weekend, can't today.
[11:04] <seb128> jdub: ok
[11:07] <_rene_> we probably could do it fairly quick... I just need a package which reliably is in ubuntu but not in debian ;-)
[11:07] <_rene_> the DEB_BUILD_OPTIONS logic is already written...
[11:10] <Matt|> hoary: anyone got totem working?
[11:10] <doko> jdub: ok, will do another one ...
[11:13] <_rene_> ok, if anyone wants to tell me that package, mail me ;-)
[11:13] <Matt|> hey guys is totem working ok in hoary? just crashes on startup here
[11:18] <thom> Mithrandir: oh?
[11:21] <jdub> doko: i was going to do a quick revision here, but 171MB... OWCH :)
[11:21] <jdub> Matt|: load it with a file
[11:21] <Matt|> jdub, ok i'll try
[11:22] <Matt|> jdub, yeah that works ok
[11:22] <jdub> known bug, hopefully there'll be a new release soon
[11:23] <Matt|> upstream bug?
[11:23] <jdub> yes
[11:23] <Matt|> ok thanks v much
[11:23] <Mithrandir> thom: go to http://err.no/personal/wishlist/ 
[11:23] <Matt|> it is a recent thing
[11:23] <doko> jdub: yes, that's why I didn't upload it with my 16kB upstream ...
[11:23] <Mithrandir> thom: but I'm off to bed now.  Talk to you in the morning
[11:23] <jdub> doko: i'm tempted to do it on chinstrap or something
[11:24] <jdub> doko: man, my upstream is fatter than that - if you don't want to do it, let me know
[11:26] <doko> it's on adare for now, I just didn't want to upload the binaries.
[11:27] <jdub> you only need to upload the diff
[11:27] <elmo> you only CAN upload the diff
[11:27] <doko> yes, working on it ...
[11:28] <jdub> elmo: so, the mp3 stuff in debian - what led to it being acceptable?
[11:29] <elmo> jdub: *shrug* decoding's never not been accepted - at the time, the consensus was it was as valid as the lzw decompress patent, i.e. not
[11:29] <elmo> oh, and infact, I think Thompson explicitly said free decoders were okay or something too
[11:29] <jdub> ?!
[11:30] <jdub> well, lzw stuff led to libgd-nonfree and friends
[11:30] <pitti> mdz: nice de-rootification hints, thanks for them
[11:30] <seb128> jdub: please comment on #4092 :)
[11:30] <elmo> jdub: only for encode
[11:30] <elmo> jdub: decode was always accepted
[11:31] <elmo> that's why we had web browsers in main...
[11:31] <elmo> or image viewers or...
[11:31] <elmo> and why libungif existed
[11:31] <jdub> seb128: that's the ffmpeg thing?
[11:31] <seb128> jdub: yes
[11:31] <jdub> seb128: oddly, this is related ;)
[11:31] <seb128> :)
[11:32] <jdub> elmo: so the 'debian stance' is that the patents cover encoding, not decoding, so let's get on with it?
[11:32] <elmo> okay, I may have made up the point about Thompson not going after decoders at one stage - I only vaguely recall reading that, and can't find a reference
[11:32] <elmo> jdub: err, no - the consensus at the time, as I remember it was that the mp3 decode patent wouldn't stand up
[11:32] <jdub> and i can't remember them ever saying anything positive about non-thomson Free implementations
[11:33] <jdub> elmo: whoa, okay
[11:33] <jdub> elmo: so, ffmpeg stuff.
[11:33] <elmo> remember, that's partially based on lzw precedent - unisys claimed decode on that too, and we (and gzip upstream who did a lot of research into it) thought that was bogus too
[11:34] <elmo> but Debian really isn't a good example, we do a lot of legal stuff that's dubious basically through lethargy.. e.g. it took us years to start enforcing GPL vs. SSL conflicts
[11:34] <elmo> jdub: what's that do?
[11:35] <jdub> so if debian thinks a patent is bogus, you'll ship until there's judgement or injunction
[11:35] <jdub> ?
[11:35] <jdub> ffmpeg viciously violates every mpeg related patent known to man
[11:35] <elmo> jdub: *shrug* I'm really not comfortable answering questions about "what debian does" - I can't speak for them , but historically we have yes
[11:35] <seb128> ffmpeg is staying in NEW for months :p
[11:36] <elmo> jdub: more so than the existing stuff we have?
[11:36] <elmo> e.g. xine, SDL's plaympeg etc.?
[11:36] <jdub> doesn't debian's xine disable its ffmpeg stuff?
[11:37] <jdub> ffmpeg is copy'n'pasted in lots of things
[11:37] <jdub> so it's a hard one
[11:37] <jdub> seb128: 'longtemps' in french?
[11:37] <seb128> yes
[11:38] <seb128> you start with the big "everybody speaks french" plan ? :)
[11:38] <jdub> heh, what does it mean? :)
[11:38] <seb128> oh
[11:38] <seb128> a long time
[11:38] <jdub> haha
[11:38] <seb128> I thought you were reaction to my <seb128> ffmpeg is staying in NEW for months :p
[11:38] <jdub> yeah ;)
[11:38] <jdub> but no
[11:38] <jdub> my french is not that good
[11:39] <jdub> i just saw it on vuntz's jabber status :)
[11:39] <seb128> oh ok
[11:39] <jdub> 'parti pour longtemps' -> fun :)
[11:39] <seb128> he he
[11:40] <jdub> i think xine uses a limited ffmpeg
[11:40] <seb128> jdub: about ffmpeg, dunno what sam did exactly with the package waiting in NEW, but usually he does really good work
[11:40] <elmo> sam is usually very careful with patents
[11:40] <seb128> yes
[11:40] <jdub> seb128: is that gst-ffmpeg or ffmpeg itself?
[11:40] <seb128> ffmpeg
[11:41] <jdub> oh no, it has libavcodec in it too
[11:41] <elmo> the main question is if the ffmpeg in NEW does encode - we have decoders in main (-> precedent), we don't, AFAIK, have any encoders
[11:41] <seb128> taaz is waiting on ffmpeg to upload gst-ffmpeg ... that's not needed, but since no decision is taken about ffmpeg ...
[11:41] <mirak> erf
[11:41] <jdub> so it's sitting in NEW purely because it's controversial?
[11:41] <mirak> j'ai cr un fichier   "-f2" par megarde
[11:41] <mirak> je ne parviens pas a le virer
[11:42] <mirak> avec tm
[11:42] <mirak> rm
[11:42] <mirak> bon je l'ai vir avec konqueror
[11:42] <mirak> mais j'ai pas trouv comment faire avec rm
[11:43] <mirak> il croit en effet que je lui passe une option
[11:43] <seb128> mirak: ECHAN imho
[11:43] <mirak> ?
[11:43] <_rene_> mirak: and if not ECHAN, ELANG anyway
[11:43] <seb128> mirak: that's #ubuntu-devel ...
[11:43] <_rene_> mirak: this is an english-speaking channel...
[11:43] <mirak> damn
[11:43] <mirak> sorry
[11:43] <mirak> lol
[11:44] <mirak> I am tired
[11:44] <mirak> my bad
[11:44] <smurfix> mirak: so go to sleep
[11:44] <jdub> i can't understand what you are talking about, but i would defend to the death your right to say... whatever it is.