[12:02] <daniels> kent: it enables server-side compositing, which means that instead of having to do a round-trip to the client and asking it to repaint itself please, when you expose it (e.g. move another window out from in front of it), it's just always there
[12:02] <daniels> kent: try dragging windows around
[12:02] <daniels> kent: (the effect is infinitely more pronounced with exa)
[12:03] <kent> daniels, so using xcompmgr -a is a way of accelerating the desktop?  I meen, i thought composite was about eyecandy.. ?
[12:03] <mjr> kent, no, it's not
[12:04] <mjr> it's certainly useful for eyecandy, but it's more than that
[12:04] <Kamion> CarlFK: it's just something in a non-optimal place in partman
[12:32] <hunger> Is the synaptic driver currently broken in dapper?
[12:34] <daniels> install xserver-xorg-input-synaptics
[12:34] <hunger> daniels: Ah, yes! I had installed the old one and that confused me:-)
[12:34] <hyperactivecrond> can i talk to an admin for the website... i need my account de-permanently deleted...
[12:36] <Burgwork> hyperactivecrond, which website?
[12:36] <hyperactivecrond> the wiki
[12:36] <hyperactivecrond> apologies. the wiki
[12:36] <hunger> daniels: did you notice my bugreports about broken manpages in the X debs in malone?
[12:37] <hunger> daniels: The man-pages got moved into .../man3 while the .so entries referencing them still claim stuff to be in man3x.
[12:39] <daniels> hunger: hm?
[12:40] <daniels> hunger: you know there's no /usr/share/man/man3x, right?
[12:40] <seb128> jbailey: around?
[12:40] <hunger> daniels: Yes. Some manpages reference others and they list man3x there.
[12:41] <jbailey> seb128: Yup
[12:41] <hunger> daniels: Check XShape* in /usr/share/man/man3/
[12:41] <seb128> jbailey: do you have a dualhead setup?
[12:41] <jbailey> seb128: Not currently, no.
[12:41] <hunger> daniels: mandb sends me mails about this each night:-)
[12:41] <seb128> ah, I thought
[12:41] <jbailey> seb128: I used to.  I'm on a cinema display now.
[12:41] <seb128> somebody with a such config? :)
[12:41] <daniels> hunger: ah, I see
[12:41] <seb128> jbailey: did you notice something like http://bugzilla.ubuntu.com/show_bug.cgi?id=21628 ?
[12:42] <jdub> http://www.flickr.com/photos/badroucha/82634154/
[12:42] <jbailey> seb128: No, my setup was Xinerama./
[12:44] <seb128> jbailey: oki, thanks anyway :)
[12:45] <daniels> seb128: when i had a mergedfb setup, I used that in lieu of workspaces, so
[12:45] <jdub> http://www.flickr.com/photos/86444323@N00/81971182/
[12:45] <jdub> whoa :)
[12:46] <tseng> hey now
[12:46] <tseng> can I get that in gdm
[12:46] <daniels> (nsfwish)
[12:48] <hyperactivecrond> lol
[12:51] <jdub> tseng: i'm, ah, thinking of doing something like that...
[12:52] <Seveas> jdub, how about a very winXP like gdm login op april 1st :)
[12:52] <hyperactivecrond> no admins for the wiki here then..
[12:52] <jdub> Seveas: heh
[12:54] <jsgotangco> whoa
[12:56] <jsgotangco> hmm
[12:56] <jsgotangco> jdub, planet css is missing?
[12:56] <jdub> jsgotangco: the fact that it's tagged and titled ubuntu is what gets me :)
[12:57] <jdub> jsgotangco: ugh, probably changes on the main website breaking it
[12:57] <jdub> yeah, i think the website has been redone or something
[12:57] <jdub> i don't know
[12:57] <jdub> yikes
[12:57] <jdub> it's moin now
[12:57] <jdub> that's remarkably sane
[12:58] <jdub> but not good for planet ;)
[12:58] <tseng> yay moin
[12:59] <lucas> does somebody has a cool Ubuntu-colored HEADER.html I could use ?
[12:59] <tseng> yeah i put the snippet in REVU
[12:59] <lucas> HEADER.html = file put before the file list by apache when there's no index.*
[12:59] <tseng> grab it
[12:59] <lucas> ah good idea
[01:00] <jsgotangco> yeah the website is in moin now (most of it)
[01:22] <jsgotangco> nice kannel is in universe this should come in handy at work
[01:24] <Burgwork> jsgotangco, kannel?
[01:25] <jsgotangco> Burgwork, its a wap/sms gateway i use it heavily at work, we used to do it in fedora but we're switching servers =)
[01:25] <jsgotangco> Burgwork, its a very popular app used by telcos and mvnos
[01:51] <jdub> daniels: ping
[01:52] <daniels> jdub: respecognise
[01:52] <jdub> heh
[01:52] <daniels> wassgoinon?
[01:52] <jdub> daniels: ati in a laptop, unknown device 5a62, only works with fglrx atm, ati driver makes the screen all flashy and wonky
[01:53] <jdub> daniels: know what it is and if xorg supports it, and how we can fix autodetect?
[01:53] <HrdwrBoB> that's the technical term
[01:53] <daniels> ah, xpress 200
[01:53] <daniels> jdub: if it's running breezy, try Option "Accel" or Option "NoAccel"
[01:53] <daniels> this has been fixified in dapper
[01:53] <jdub> daniels: dapper
[01:54] <daniels> bugger
[01:54] <daniels> does Option "MonitorLayout" "LVDS,NONE" help?
[01:54] <daniels> (device section)
[01:54] <jdub> also i'm still not getting synaptics love :)
[01:54] <daniels> yeah, I only fixed that like this morning
[01:54] <daniels> so the seeds won't have been updated yet
[01:54] <jdub> monitorsection didn't work
[01:55] <jdub> er, monitorlayout
[01:55] <daniels>  frig
[01:55] <daniels> i have no idea
[01:55] <daniels> can you please email me both xorg.0.logs? i need to write a tool for treenaks on monday to get the information to fix it
[01:56] <jdub> with and without the monitorlayout option?
[01:56] <daniels> just without
[01:56] <daniels> both -> ati and fglrx
[01:56] <jdub> oh right
[01:57] <jdub> funny - only reason i bothered trying again was because fglrx still crashes the crap out of it ;-)
[01:57] <daniels> god
[01:57] <daniels> airlied got himself one of those for christmas, so hopefully they're working soon
[01:58] <daniels> nightmare devices
[01:59] <jdub> daniels: this quebecistani craptop is pretty evil all 'round :)
[02:00] <daniels> heh
[02:00] <mjg59> daniels: Is this the same thing that fucks the Firegl V5000
[02:00] <mjg59> ?
[02:00] <daniels> mjg59: maybe, who knows
[02:00] <mjg59> daniels: We had that failing on the HP 8240
[02:00] <daniels> mjg59: xpresses are screwed in general, though.  shared vram, yay.
[02:00] <daniels> mjg59: oh? well, I'll pass you the program too
[02:00] <mjg59> I think this has discrete memory
[02:00] <mjg59> daniels: There's an open bug about it in bugzilla - hang on
[02:00] <jdong> I wasn't able to get a meaningful answer in #ubuntu, but what on EARTH is prat.ubuntu.com?!
[02:01] <seth_k|lappy> It works!
[02:01] <daniels> mjg59: i won't be around on the weekend (in bendigo), but basically you want to read RADEON_FP_*, particualrly the syncy bits
[02:01] <Burgwork> daniels, that i810 no dri bug seems to have fixed itself as of today
[02:02] <daniels> jdub: one half of archive.ubuntu.com
[02:02] <daniels> Burgwork: okay
[02:02] <mjg59> Gah, can't find it now
[02:03] <daniels> mjg59: RADEON_FP_CRTC_H_TOTAL_DISP, RADEON_FP_CRTC_V_TOTAL_DISP, RADEON_FP_H_SYNC_STRT_WID, RADEON_FP_V_SYNC_STRT_WID, RADEON_TMDS_PLL_CNTL, RADEON_TMDS_TRANSMITTER_CNTL, RADEON_FP_HORZ_STRETCH, RADEON_FP_VERT_STRETCH, RADEON_FP_GEN_CNTL
[02:03] <mjg59> http://bugzilla.ubuntu.com/show_bug.cgi?id=14043
[02:03] <daniels> mjg59: also RADEON_LVDS_GEN_CNTL, RADEON_PIXCLKS_CNTL, possibly also RADEON_BIOS_[456] _SCRATCH
[02:04] <mjg59> daniels: Ok - I probably won't have time to deal with this myself for now
[02:04] <daniels> mjg59: okay, I should get to it on monday then
[02:04] <Burgwork> jdub, css messed on planet.u.c? my issue or the worlds?
[02:04] <daniels> Burgwork: world's
[02:04] <daniels> jdong: 01:02 < daniels> jdub: one half of archive.ubuntu.com
[02:05] <jdub> Burgwork: wuc changed, broke planet
[02:05] <jdong> daniels: oh, so some packages are hosted on there?
[02:05] <Burgwork> jdub, ah, ok
[02:05] <jsgotangco> moin rules!
[02:06] <jdub> moin's great, i totally approve of switching wuc to it, but would have been good to have any idea whatsoever in advance
[02:06] <daniels> jdong: ... it's one of the servers in the a.u.c rotation.
[02:06] <jdong> daniels: ok, thanks, that clears it up!
[02:07] <lucas> it also broke the CSS on popcon.u.c
[02:10] <jsgotangco> argghhh
[02:11] <elmo> planet should work now
[02:12] <elmo> if jdong ever comes back, someone point him at http://www.comnap.aq/comnap/comnap.nsf/P/StationsByName/CLnava
[02:12] <daniels> CONCORDIAH
[02:13] <jdub> elmo: planet is pointing to shitty old css from the plone site
[02:13] <jdub> elmo: we need to get it onto humboldt so i can actually fix it and stuff :)
[02:13] <jdub> yay for http
[02:13] <jdub> elmo: i'll fully prep it now, given that i have http love
[02:13] <elmo> jdub: um, thanks for like telling us.  after complaining about not being told stuff :-P
[02:13] <elmo> (about the CSS)
[02:14] <jsgotangco> chile?
[02:14] <jdub> elmo: i found out like, minutes ago
[02:14] <jdub> elmo: and it shouldn't be your responsibility to fix
[02:14] <elmo> jdub: eh?
[02:14] <elmo> yeah it is
[02:14] <elmo> planet isn't the only thing that points at the css on www.u.c
[02:15] <elmo> it needs fixed, and  who else is going to?
[02:15] <jdub> well, the web people should've told you that, then
[02:15] <jdub> before changing it all
[02:15] <jdub> same as i
[02:16] <jsgotangco> who are the other web people (aside from henrik)?
[02:16] <jdub> http://www.flickr.com/photos/kittyfish/82737624/
[02:18] <jsgotangco> jdub, yahoo has this neat widget that retrieves images from flickr based on tags...on windows and osx though...
[02:18] <jdub> i have a neat shell script ;-)
[02:18] <jsgotangco> ohhh
[02:18] <jdub> i just use rss, and a shell script to modify it for inclusion on the fridge
[02:18] <whiprush> we need a slick rss/flickr/web2.0whatever screensaver badly.
[02:19] <jsgotangco> you really have to call it web2.0? heh
[02:19] <whiprush> I tried to say that with a straight face, heh.
[02:22] <hyperactivecrond> man heh
[02:36] <\sh> infinity / lamont: ping
[02:37] <psusi> anyone ever used hal callouts before?
[02:38] <\sh> infinity / lamont: if you have time please have a look on atom4...it builds nicely in a pbuilder but FTBFS on all archs on our buildd ...think it's a "cons" problem...thx 
[02:40] <infinity> s/cons/scons/?
[02:41] <infinity> Oh, cons indeed.
[02:46] <\sh> cons 
[02:46] <infinity> Yeah.  Let me poke it with a stick.
[02:47] <\sh> Many thanks :)
[03:00] <hunger> Some are gziped others are not, sometimes the first rotated file is called .0, sometimes .1.
[03:00] <lifeless> hunger: I think you mean less unique
[03:00] <lifeless> hunger: or even homogenous
[03:01] <hunger> lifeless: homogenous sounds like it might fit, yes.
[03:03] <hunger> Hmmm... is the initscript for cups broken? logrotate complains about it here.
[03:29] <infinity> \sh: Should be fixed now.  We'll see in ~30 mins.
[03:29] <\sh> infinity: great :)
[04:10] <jouston> Hi all
[04:16] <jouston> Anyone see Malcolm or Mark?
[04:28] <elmo> BenC: is the -ubuntu<n> suffix to the package name a linux-source thing or a kernel-package thing?
[04:42] <nekohayo> anyone know when gst plugins base multiverse, and gstreamer development files might appear in the repositories?
[04:42] <nekohayo> I'm pretty much stuck without them I cannot fully compile pitivi, gnonlin and gst-python
[05:11] <fabbione> elmo: the -ubuntu<X> comes out only if you compile your kernel manually.
[05:11] <fabbione> elmo: it's the EXTRAVERSION in the toplevel Makefile of the kernel to distinguish from vanilla kernels on kernel.org
[05:12] <elmo> oh, ok, I never even thought to check that
[05:12] <elmo> I thought it was the LOCAL_AUTO_VERSION config maybe
[05:12] <elmo> thanks
[05:12] <fabbione> elmo: it doesn't appear on our packages because there is an override
[05:12] <fabbione> if you really hate it, you can override it
[05:13] <fabbione> export UBUNTUBUILD=1
[05:13] <fabbione> and it will clear the EXTRAVERSIOn
[05:13] <elmo> or just edit the Makefile? :)
[05:15] <fabbione> elmo: that would do too :)
[05:31] <psusi> have we any hal gurus about who might shed some light on having hal invoke a callout when it detects a cdrom?
[07:46] <jsgotangco> is anyone aware that grub is still borked in the daily builds?
[07:46] <pitti> hey folks
[07:47] <jsgotangco> hi pitti 
[07:48] <ajmitch> hi pitti 
[07:54] <Mez> morning all
[07:54] <infinity> Hey pitti.
[07:54] <Keybuk> morning Mr Pitt
[07:55] <Mithrandir> moo
[07:55] <pitti> hi infinity 
[07:55] <pitti> hey Keybuk 
[07:56] <Keybuk> infinity: any progress on madwifi-ng packaging?
[07:59] <infinity> LRM is taking a back seat to some apache/php stuff today, but it's likely a weekend thing to get madwifi-ng happening for testing.
[08:00] <Keybuk> ok
[08:03] <Mithrandir> infinity: we were going to discuss livecd-squashfs too
[08:03] <infinity> And that.
[08:03] <infinity> Good thing I have my secretary here.
[08:04] <Mithrandir> infinity: I just need a filesystem.squashfs on the cd, but we don't want it for ppc yet, just for amd64 and i386 (I don't know what ia64, hppa, sparc wants).
[08:05] <fabbione> Mithrandir: there is no sparc livecd yet
[08:05] <fabbione> Mithrandir: so don't worry too much about it
[08:05] <fabbione> probably next week if i feel like hacking on it
[08:05] <Mithrandir> infinity: we also want to be able to go back by flipping a switch, if possible.
[08:06] <Mithrandir> or at least, mdz would want that
[08:06] <dholbach> good morning
[08:06] <infinity> Switch flipping is easy enough.
[08:07] <Mithrandir> infinity: is there anything else you need from me on that matter?
[08:07] <infinity> Well, some sort of "how do we build these squashfses" would be nice. :)
[08:08] <Mithrandir> mksquashfs, in squashfs-tools
[08:08] <Mithrandir> mksquashfs /path/to/live/chroot foo.squashfs
[08:08] <infinity> Is it one command?  Are we re-ordering files before (with a config file), or after (with rsync)?  Do we need to do stupid block-zeroing magic, or will they always be as small as possible?
[08:09] <Mithrandir> I think we'll look at the reordering later, no we don't need a block-zeroing thing.
[08:09] <infinity> Oh, wait, we can't reorder after with rsync, cause it's readonly.
[08:09] <Mithrandir> at least, I didn't and got decent results from rsync with a changed fs.
[08:10] <infinity> So, we'll need to order the files on fs creation.
[08:10] <infinity> Yeah, but you didn't change the fs THAT much.  I'm betting it'll get pretty mucked up after a few days of development, when I try to rsync, say, Friday-to-next-Thursday.
[08:11] <Mithrandir> quite possibly, but rsync will just see inserted and removed chunks, which it should handle pretty well, shouldn't it?
[08:11] <infinity> Meh.  Time will tell, I guess.
[08:11] <infinity> As long as the file order doesn't change, life is good.
[08:11] <infinity> If the order changes, we're up shit creek.
[08:12] <infinity> If squashfs is deterministic in how it creates filesystems, this may be a nonissue.
[08:12] <infinity> ext3 is (intentionally) non-determinstic, hence the rsync-over-the-image trick to reorder files.
[08:13] <Mithrandir> it didn't change much when I removed a bit and inserted a bit, at least.
[08:14] <Mithrandir> if it's a problem, we'll just do a find /chroot | sort and use that as an input file (at least initially)
[08:15] <trappist> is there a maintainer for iptables or are we just using debian's package?
[08:15] <infinity> Well, the best test would be for you to debootstrap two chroots, squash them both, then rsync a over b and see how different they are.
[08:16] <infinity> Mithrandir: If you have a reasonably speedy mirror and disk subsystem there, you could do that test.  Otherwise, I'll eat a buildd for a while doing it.
[08:17] <infinity> (I have no local mirror in my house right now, so those sorts of tests at home are... painful)
[08:17] <Mithrandir> you don't need to test with a mirror, just do it with /usr/share/doc or something, then with a copy of it, then rsync?
[08:18] <infinity> Oh, fair point.
[08:18] <Mithrandir> you probably want something with a bit of size, but ~100-200M should be plenty.
[08:18] <infinity> Assuming a "cp -a" won't be drastically different from two debootstrap/dpkg runs.
[08:19] <infinity> My /usr/share/doc is 137MB, that should do.
[08:20] <infinity> Did we decide on a compression method to use for squash?
[08:20] <Mithrandir> well, it's doing stuff in directory order, so it might be different, but then, two debootstrap runs should be doing stuff in the same order as well, so.
[08:20] <Mithrandir> I haven't investigated -lzma properly yet, so we'll just use the stock one so far.
[08:20] <Mithrandir> there's no packaged mksquashfs-lzma yet, for instance. :-)
[08:21] <infinity> Not when package dependency loop breaking kicks in.  As the archive changes, packages get installed in different orders.
[08:21] <Mithrandir> sure, so cp in a few directories by hand afterwards or something.  It'll be equivalent to two debootstraps immediately following each other. :-)
[08:22] <infinity> Heh.
[08:22] <infinity> We'll see.
[08:22] <infinity> Should be some fun tonight.
[08:22] <infinity> I expect I'll have prototype squashfs livefs builds working by Monday morning/afternoon.
[08:23] <Mithrandir> nice
[08:23] <infinity> The Monday dailies should be squash, if all goes well.
[08:23] <infinity> (only amd64/i386 for now, yes?)
[08:23] <Mithrandir> infinity: yes
[08:24] <infinity> Oh, I'll have to hit up the cdimage scripts too, to deal with multiple fs types, if you/Colin haven't already.
[08:24] <infinity> So maybe not Monday.  Though the buildd side will (should) be happy by then.
[08:27] <Mithrandir> ok, I hand-munged a /u/s/d a bit, and ended up with:
[08:27] <Mithrandir> sent 52545 bytes  received 56952 bytes  5918.76 bytes/sec
[08:27] <Mithrandir> total size is 66011136  speedup is 602.86
[08:27] <Mithrandir> so it _looks_ good at least.
[08:28] <trappist> O
[08:28] <Mez> can someone please tell me I'm right in thinking to set this bug as "WONTFIX" - http://bugzilla.ubuntu.com/show_bug.cgi?id=21959
[08:28] <trappist> I'd like to ask again, because the netfilter code has undergone some huge revisions and the package doesn't seem to have changed to accomodate them.  do we have a maintainer for iptables?  am I in the right channel for this question?
[08:29] <infinity> trappist: Please, file a bug.
[08:31] <trappist> infinity: I was looking into fixing bug 16831 - of those who've responded to it so far none seem the think the package needs work.  I don't know if one of them is the maintainer.
[08:34] <infinity> Okay, so a rebuild could magically fix it, according to that bug.
[08:35] <infinity> Err.  It's there in dapper.
[08:35] <infinity> (base)adconrad@cthulhu:~$ dpkg -L iptables | grep recent
[08:35] <infinity> /lib/iptables/libipt_recent.so
[08:36] <trappist> infinity: try iptables -A INPUT -s 1.2.3.4 -m recent -name test --set
[08:36] <fabbione> and it is in breezy
[08:36] <fabbione> you need to use -updates
[08:36] <fabbione> a fixed iptables has been uploaded to -updates a while ago
[08:37] <trappist> sigh.  thanks :)
[08:37] <jsgotangco> infinity, hi are you aware that grub install in daily is borked?
[08:37] <fabbione> jsgotangco: it's not because of grub
[08:38] <jsgotangco> ahhh
[08:38] <fabbione> OOo2 was uninstallable
[08:38] <fabbione> that breaks apt
[08:38] <jsgotangco> its because of 00o2?
[08:38] <fabbione> and when grub-installer calles apt-get install grub
[08:38] <fabbione> it fails
[08:38] <fabbione> it could have been any other package
[08:38] <jsgotangco> ahhh
[08:38] <fabbione> for today is OOo2
[08:38] <fabbione> or yesterday
[08:38] <jsgotangco> i tried 4 and 5
[08:38] <fabbione> yes..
[08:38] <Mithrandir> infinity: btw, sabdfl wondered about m-t 1.5.  Any idea when you'll have that? :-)
[08:39] <fabbione> as i said.. yesterday
[08:39] <infinity> Mithrandir: Yeah, he mailed me.  asac and I need to sit down and get it done.
[08:39] <infinity> -ETODOLISTTOOLONG
[08:39] <pitti> ogra... you smuggled nbd into breezy main without a main inclusion report...
[08:40] <fabbione> and it is FTBFS afaict
[08:40] <fabbione> or was
[08:54] <triceratops> Does anybody knopw how to have web lookup for online dictionaries like dict.leo.org in dict-applet 2.13.4 as it was in the former versions?
[09:10] <Keybuk> . o O { I thought the point of modularising X is that you'd only need to upload one or two components at a time ... }
[09:12] <Burgundavia> Keybuk, nah. The point was to increase the amount of email traffic. Sinister plot by ISPs really
[09:13] <infinity> Keybuk: With 7.0 final, I suspect that will be true, yes.
[09:13] <infinity> Keybuk: Some of the smaller apps may never see an update again.  Ever.
[09:13] <Keybuk> my "next unread e-mail" finger hurts
[09:43] <whiprush> hey Keybuk 
[09:45] <Keybuk> hey whiprush *hugs*
[09:45] <Keybuk> how's things?
[09:45] <whiprush> good good
[09:45] <whiprush> http://mail.gnome.org/archives/networkmanager-list/2006-January/msg00009.html
[09:45] <whiprush> you probably saw that by now
[09:45] <dholbach> re Keybuk
[09:45] <Keybuk> whiprush: no?
[09:46] <whiprush> they got their ath card just yesterday apparently
[09:46] <Keybuk> lol
[09:46] <whiprush> Keybuk: I've also tried to replicate your 30 second network skipping problem, and I can't at all.
[09:46] <Keybuk> whiprush: you have an Atheros?
[09:46] <whiprush> I seem to have an inverse problem
[09:47] <whiprush> yeah.
[09:47] <whiprush> x40.
[09:47] <whiprush> when I try to switch off the network it picks, it doesn't
[09:47] <Keybuk> whiprush: run "sudo iwevent", network-manager and nm-applet
[09:47] <Keybuk> every 13s or so, you'll see it do something like "New AP: 00:00:00:00:00:00"
[09:47] <whiprush> it always tries, connects, then decides "nope, I want this other network" and it goes off and tries to go to it.
[09:48] <whiprush> my laptop is at work, I will test it when I get in though
[09:48] <Keybuk> sounds like the same bug
[09:48] <Keybuk> it'd connect to the new network, and leap off it again when the next scan request comes in
[09:48] <Keybuk> mine does much the same, the laptop won't hold on a network if there's a stronger/shinier one nearby
[09:48] <whiprush> you pick a specific AP and it seems to just want the strongest signal
[09:48] <whiprush> or, the open one.
[09:48] <whiprush> right.
[09:49] <Keybuk> sounds totally like the same bug ;)
[09:49] <whiprush> Keybuk: have you filed a bug upstream?
[09:49] <whiprush> because I looked, and I don't see any.
[09:49] <whiprush> and I find it kind of surprising that the fedora or suse guys don't seem to have the same problem.
[09:49] <Keybuk> it's because the Atheros driver can't do a "background scan"; in order to scan all channels for networks (just to update the list of available ones) it has to leave the one it's connected to
[09:49] <Keybuk> Fedora don't ship madwifi
[09:50] <Keybuk> not sure what the SuSE guys do, I suspect they have the same problem
[09:50] <Keybuk> it's a madwifi bug, not a network-manager bug
[09:50] <jsgotangco> whiprush, go to sleep!
[09:50] <whiprush> jsgotangco: heh
[09:50] <Keybuk> and it's allegedly fixed in madwifi-ng, which we're going to try
[09:50] <whiprush> oh, cool.
[09:50] <jdub> N.G.
[09:51] <infinity> Yeah.  Time will tell if it stands for "Next Generation" or "Not Good"
[09:51] <whiprush> heh
[09:51] <Den> Can anyone tell me how to get the latest Dapper kernel installed on Breezy? I know changing /etc/apt/sources.list from B to D, then apt-get update, then apt-get install linux-386 does NOT work - it only dl's about 23kB, &doesn't change the kernel.  Any suggestions?
[09:51] <whiprush> Keybuk: anything else blocking n-m? 
[09:51] <Keybuk> Den: DON'T EVEN TRY IT
[09:51] <Keybuk> Den: SERIOUSLY
[09:52] <Keybuk> whiprush: nope
[09:52] <Den> It has been suggested to me to see if a bug is fixed
[09:52] <Nafallo> Keybuk: looks like there is troubles with madwifi-ng according to nm-mailinglist :-P.
[09:52] <Keybuk> Den: a better thing would be to download a dapper Live CD and test that
[09:52] <Nafallo> morning btw :-)
[09:52] <Den> See bugzilla bug 21565
[09:52] <Keybuk> Nafallo: that bug was fixed recently, wasn't it?  I saw a commit on madwifi-ng to expose the right things in sysfs
[09:53] <Nafallo> ah, nice. must have been then :-).
[09:53] <Den> I have also tried the flight2 dapper cd - it fails to boot - it drops me to a busybox console.
[09:53] <Den> I'd love any suggestions.
[09:53] <Keybuk> Den: upgrading to the dapper kernel will mean you also have to update much of userspace because you'll need new udev, initramfs-tools, module-init-tools, hal, d-bus, gnome-volume-manager, probably then libgtk+, libgnome, et. al.
[09:53] <Den> I don't care
[09:54] <Den> I only want to see if the bug is fixed with the new kernel
[09:54] <whiprush> Keybuk: so basically, laptop network magic is blocked by this one bug.
[09:54] <Keybuk> Nafallo: will find out next week I guess
[09:54] <infinity> whiprush: Well, that and NM being fundamentally not Debian/Ubuntu/infinity friendly.
[09:54] <Den> Ben Collins who responded when I submitted the bug said to try the latest kernel.
[09:55] <whiprush> infinity: tell me which wall your banging your head against, so I can join you.
[09:55] <infinity> whiprush: But if Keybuk can get hacking on NM (after I get him a madwifi that actually works), maybe I can file a mess of wishlist bugs. :)
[09:55] <infinity> whiprush: My biggest issue with it is the complete lack of central (system/root) configuration.
[09:55] <Nafallo> Keybuk: what's the plan btw, we already have the latest "stable" version. should we try cvs soon? in that case we need libnl :-)
[09:55] <Den> Keybuk: any further suggestions?
[09:56] <Nafallo> (next stable will need it anyway since head does now) ;-)
[09:56] <infinity> whiprush: So, if you configure your network with NM, you (a) don't have a network during boot... You only get it when you log in, and (b) if you configure the network under your profile, your mom will log in and not be able to use the internet.
[09:56] <whiprush> infinity: Its amusing to me that the guys that work on this stuff all have thinkpads ... with atheros cards.
[09:56] <infinity> We could live with (a) (though I'd rather not), but (b) is just plain wrong.
[09:56] <infinity> People who can become root should be able to set "system defaults"
[09:56] <whiprush> infinity: I can see where that could be a problem.
[09:56] <Den> Anyone - is the Dapper flight 2 cd supposed to boot up properly?  Or, is it in a development state where it only boots to a busybox console?
[09:57] <infinity> whiprush: I'm a Thinkpad user with ipw2200, but my plate is too full to even look at NM right now.
[09:57] <Nafallo> Den: the former ;-)
[09:57] <infinity> Den: It won't boot if you have an SATA CDROM.
[09:57] <whiprush> infinity: fc4 and 2 suse releases have shipped with it, it just sucks that we kind of got stuck with the short end of the stick.
[09:57] <infinity> Den: Otherwise, it should work for most pepole.
[09:58] <Den> I have a ieee1394 firewire CD, SCSI on top of that 
[09:58] <Den> That all works fine with the Breezy live cd
[09:58] <infinity> Den: Oh, yes.  That won't work with flight2 either.
[09:58] <jdub> Den: you have a firewire CD drive?
[09:58] <infinity> Den: A more recent livecd daily build should work.
[09:58] <Den> but the Dapper live cd doesn't boot - just to busybox console
[09:59] <Keybuk> whiprush: yes, because the person the spec is assigned to is affected by that bug ;)  I can't do anything with n-m if it doesn't work for me <g>
[09:59] <whiprush> infinity: thanks for your efforts though.
[09:59] <infinity> Den: (Flight 2 forgot to load SCSI CD modules)
[09:59] <whiprush> Keybuk: you too.
[09:59] <Den> When will a fixed cd be available?
[09:59] <infinity> Keybuk: Well, dude, if I'm blocking specs, by all means, whip me harder to get madwifi working for you. :)
[09:59] <Keybuk> infinity: you'd enjoy it too much
[09:59] <infinity> Yes, and..?
[09:59] <Den> jdub: yes
[10:00] <jdub> Den: rad ;)
[10:00] <Keybuk> and I haven't got to the point of starting on that spec yet either
[10:00] <Keybuk> it's blocked by jbailey too
[10:00] <infinity> Den: http://cdimage.ubuntu.com/daily-live/20060106/
[10:00] <whiprush> jdub: this is one of those situations where I totally rip off one of your sayings.
[10:00] <Keybuk> and he'd definitely enjoy a whipping too much
[10:00] <infinity> Den: No idea if today's daily works, but I see no immediate reason why it shouldn't at least boot.
[10:00] <whiprush> "Ladies and Gentlemen, the Linux Desktop!!!" <self-trepanation>
[10:01] <jdub> whiprush: and i correct your spelling? :)
[10:01] <whiprush> always. :)
[10:02] <Den> infinity: So this daily cd is basically as complete as the flight2 cd?
[10:02] <infinity> Den: Same software, just newer (and completely untested, where flight2 had some testing before we announced it to the world)
[10:03] <infinity> Den: Anyone willing to test dailies and file bugs gets a cookie, though.  So, that's something to look forward to.
[10:03] <Den> Does anyone know if the daily live cd fixed the problem of loasing the scsi cd modules?
[10:03] <jdub> infinity: how's rsync going with the dailies, btw?
[10:03] <infinity> Den: Yes, that was fixed quite a while ago.
[10:03] <Den> Thanks everyone - I'll try the daily cd.
[10:04] <infinity> jdub: ETOOVAGUE
[10:04] <jdub> infinity: is rsync allowing us to update CDs without stressing the tin cups and string?
[10:04] <infinity> jdub: "Yes, rsync works fine", "Yes, we're keeping the diffs minimal through crazy tricks on the buildds", "Your mom"
[10:05] <Den> As a final note, back to the original question, anyone know of a way to just pull the latest kernel, plus anything necessary for it to work, into a Breezy system on the hard disk?
[10:05] <infinity> Yeah, our diff minimizing antics work pretty well for that (assuming you're updating from a reasonably recent ISO.. I image breezy-final -> dapper-daily might be a bit of a pain)
[10:05] <pitti> Den: the latest kernel requires a lot of userspace changs
[10:05] <infinity> Den: Your best (?) bet at that point is just to upgrade to dapper.  Which I don't recommend, unless you really like bugs.
[10:05] <jdub> infinity: yeah, just wondering if it was still doing well during dapper (i was around for the antic development)
[10:05] <pitti> infinity: I tried that, btw, and I got a speedup of 1.02
[10:06] <Den> so, is there a simple way to acquire all the necessary userspace changes, or is that a nonsimple task?
[10:06] <pitti> Den: the latter
[10:06] <Den> infinity: thanks for the info.
[10:06] <infinity> jdub: Seems to hold up well.  There've been some tweaks to it (late in the breezy cycle, went into production for dapper dailies) that make it a bit nicer still.
[10:06] <Den> Thanks everyone. :)
[10:06] <infinity> jdub: And it'll all go out the window when we switch to squashfs and have to develop new antics. :)
[10:07] <infinity> (Which could be as early as Monday...)
[10:09] <jdub> heh
[10:09] <jdub> i'll dodge the download, then ;)
[10:10] <jsgotangco> ahhh
[10:11] <infinity> Den: Actually, I'm not sure if firewire CD drives will work... We fixed the SCSI issue, but we may not be including everything required to make your setup go.  I'd still appreciate it if you could test, though.
[10:11] <infinity> Den: And if it doesn't boot, file a bug report on the "casper" package, pretty please (with sugar on top)
[10:12] <jsgotangco> bye bye coaster
[10:15] <Burgundavia> pitti, how do I say "If you speak German", in German?
[10:15] <pitti> Burgundavia: "Wenn Sie Deutsch sprechen, ..."
[10:15] <pitti> Burgundavia: but don't you need a sensible 'then' clause?
[10:16] <Burgundavia> pitti, https://wiki.ubuntu.com/EdubuntuCommunity , see chat with us on IRC
[10:16] <pitti> Burgundavia: ah :) that's fine as it is
[10:17] <Den> infinity: gotch - will do.
[10:17] <Den> Everyone - thanks for your work on ubuntu!
[10:17] <Burgundavia> pitti, excellent, thanks
[10:25] <Den> Anyone - Would Ubuntu consider creating a daily version that is "light" - ie, just the basic kernel, gui, etc, so it is much smaller than 600MB?  Is that a reasonable, workable possibility?
[10:25] <Treenaks> Den: You can rsync the images. you'll only have to download a few MB each day that way
[10:26] <infinity> Den: http://cdimage.ubuntu.com/livecd-base/20060106/
[10:26] <Den> Can I rsync the daily to the flight 2 cd iso?
[10:26] <infinity> Den: That won't even have a GUI, mind you.  Just the base system.  Should dump you at a console after it boots.
[10:26] <infinity> Den: Yes, you can definitely rsync from flight-2 to the current daily.  Should save some time.
[10:27] <Den> Ive never done rsync - would you give me a web page pointer on how to sync the flight2 iso to the daily?  If there is no such page, could someone put one up on the wiki in a day or so?
[10:28] <Treenaks> Den: it's 1 command line.
[10:28] <Den> Treenaks: do tell!
[10:29] <Treenaks> Den: https://wiki.ubuntu.com/GettingUbuntu
[10:29] <Treenaks> Den: at the bottom
[10:29] <Treenaks> Rsync to get the latest ISO
[10:29] <infinity> rsync rsync://cdimage.ubuntu.com/cdimage/daily-live/current/dapper-live-i386.iso ./my_old_iso.iso
[10:29] <Treenaks> maybe -v or --progress in there somewhere
[10:29] <Treenaks> if you want pretty progress meters
[10:29] <infinity> And --partial if you don't want to cry if you lose your connection.
[10:31] <Den> Thanks again, everyone!
[10:37] <Treenaks> pitti: is the blender USN screwed, or is it the same as the nbd one (except for the package name)?
[10:40] <pitti> Treenaks: hm?
[10:40] <Den> Does the daily, and also the flight 2 cd, not have the gui?  They are only console mode?  (That is what I'm concluding from your latest responses.  But, I had thought flight2 had everything the complete Breezy cd had.)
[10:40] <Treenaks> pitti: the blender advisory in my inbox has a details section about NBD, not about blender
[10:40] <Treenaks> (USN-238-1)
[10:40] <pitti> Treenaks: oh, fuck, thanks for pointing out
[10:42] <Treenaks> StevenK: can it netboot?
[10:42] <mvo> StevenK: boot with dhcp/tftp
[10:42] <Treenaks> StevenK: (or use an USB something)
[10:43] <StevenK> I can install using a USB flash disk?
[10:43] <StevenK> I have a 1Gb flash disk, so I can mirror the CD. :-)
[10:43] <pitti> Hey seb128 
[10:43] <seb128> hi pitti
[10:47] <Den> infinity: Will you please clarify this confusion you have caused me:  You said "That wont have a GUI, just the base system. Should dump you at a console.", but on the DapperFlight2 web page, it says that includes "aster GNOME start up times, improvements to the user interface, a shiny new optimized kernel, GNOME 2.13.3, OpenOffice.org 2.0.1 RC2, Firefox 1.5 and much more"
[10:48] <Den> infinity: So, the synced daily should have the GUI, yes?
[10:48] <Nafallo> lamont, infinity: could one of you clear the dep-wait on bsdgames, thanks :-).
[10:49] <pitti> Treenaks: sent an update, thank you
[10:49] <Treenaks> pitti: np
[10:49] <pitti> Treenaks: *brown paperbag*
[10:52] <infinity> Den: No, the URL I pointed at for "live-base" images is just the base system.  If you're downloading "daily-live", it will be just light Flight-2 (with a GUI)
[10:52] <infinity> Den: You must have missed the URL I pasted right before I said "that one won't have a GUI". :)
[10:53] <Den> infinity: OK, thanks for the clarification, I'll go back & reread what you'd said.
[10:53] <Keybuk> weird, have there really been no uploads for 6 hours?
[10:54] <Keybuk> or is something broken
[10:54] <Treenaks> or both :)
[10:55] <Keybuk> jdub: anything up with the lists servers?
[10:55] <Keybuk> elmo: anything up with the archive?
[10:55] <Znarl> Keybuk : Why do you ask?
[10:55] <Keybuk> Znarl: because the last message to -changes was 6 hours ago
[10:56] <StevenK> Znarl: By the way, I mailed in a admin ticket just over 3 weeks ago, about my ubuntu.com address ...
[10:57] <Znarl> StevenK : Do you have the RT number handy?
[10:57] <StevenK> Znarl: Sure. #1217
[10:58] <Znarl> StevenK : Thanks, I'll chase elmo about it for you.
[10:59] <StevenK> Znarl: Thanks.
[11:05] <jdub> Znarl: btw, the mailman template customisations were lost during the transfer, so our archives don't look like LOVE
[11:08] <Znarl> jdub : LOVE is important, I can fix that.  Can you create an RT request for archives LOVE to be restored?
[11:08] <jdub> Znarl: yo
[11:18] <jdub> mjg59: ping
[11:21] <Keybuk> ok, my BAD brain just gave me the phrase "HOT BROWN LOVIN'"
[11:21] <Znarl> Keybuk : Sorry. :(
[11:21] <jdub> Keybuk: the train company in GTA:SA is called "brown streak"
[11:21] <Keybuk> Kamion: well, I for one welcome our new HP overlords
[11:21] <jdub> Keybuk: it always reminds me of, well, us.
[11:21] <jdub> ubuntu: a series of six month brown streaks
[11:25] <ogra> pitti, nope, i didnt, that was matt
[11:31] <Kamion> Mez: 21959 shouldn't be WONTFIX; not entirely sure where the bug is though, but I think it must be either dpkg or coreutils
[11:32] <Kamion> Mez: though adept could probably trivially work around it by doing chdir("/") right at the start
[11:33] <Kamion> Mez: actually, apt does that, so let's say adept should too for consistency
[11:35] <Kamion> dpkg can't do that itself across the board because it might be asked to install files from the current directory, although perhaps it should take more care when executing subprocesses that don't depend on that
[11:35] <Kamion> it looks to be a relatively complicated problem from dpkg's point of view
[11:35] <Keybuk> it should probably exec scripts in /
[11:36] <jpetersen> hi
[11:37] <Kamion> ah, and rm's fixed now too
[11:44] <Keybuk> I like it when bugs do that
[12:03] <Diziet> Kamion: I disagree.  I think that ought to be WONTFIX.  dpkg is entitled to assume that the world is sane, and dpkg (which runs as root) failing to have access to any relevant bit of filesystem is not sane.
[12:04] <Diziet> Although coreutils isn't entitled to assume that so if that's the only problem then it's a real bug.
[12:05] <Kamion> with any luck that's the only problem, and it's fixed in dapper
[12:05] <Kamion> I do think adept and apt should be consistent though
[12:05] <Kamion> either both should chdir(DPkg::Run-Directory), or neither should
[12:06] <Kamion> particularly since adept uses libapt ... I wonder is it calling dpkg itself in some cases
[12:07] <Kamion> Diziet: also, I think the current directory is only a "relevant bit of filesystem" to dpkg if it's installing a .deb with a relative path
[12:07] <Kamion> in normal cases I don't want dpkg to depend on what cwd I happen to be executing it from
[12:07] <Diziet> I think the cwd is always relevant.
[12:07] <Diziet> For the purposes of it needing to be sane.
[12:07] <Kamion> Only if you don't change it first. :-)
[12:08] <Kamion> Of course I suppose you could be installing lots of .debs, some in a relative path and some in the current-directory-at-startup, so I can see how it would be messy for dpkg to try to handle that.
[12:09] <Kamion> er, "some in an absolute path" I mean
[12:11] <ogra_ibook> Keybuk, did you get the urls yesterday ?#
[12:11] <Kamion> jbailey: does grub2's new scripting language support (aargh, MADNESS, but anyway) allow us to figure out the kernels available on any given filesystem on the fly rather than having to precalculate them?
[12:11] <Keybuk> ogra_ibook: no, did you mail me them?
[12:11] <ogra_ibook> nope i posted them here
[12:11] <Keybuk> IRC is a lossy medium
[12:12] <Keybuk> I don't keep more than ~50 lines of scrollback
[12:12] <ogra_ibook> https://wiki.ubuntu.com/ThinClientAudioSupport and the implementation: http://people.ubuntu.com/~ogra/bzr-archive/ltsp/sound/
[12:12] <Keybuk> can you mail those please
[12:13] <ogra_ibook> Keybuk, not before tomorrow ... 
[12:14] <ogra_ibook> my mailserver is broken, i'll replace it today
[12:14] <Keybuk> ok
[12:14] <Kamion> infinity: any idea why openoffice.org2 failed to build on powerpc? it got SIGABRT apparently
[12:14] <Kamion> infinity: it built before, but mysteriously didn't get uploaded (maybe we gave it back before the uploader ran or something)
[12:20] <seb128> Kamion: could you promote "libavahi-client-dev libavahi-glib-dev" so gnome-vfs2 builds again?
[12:20] <seb128> (avahi has been accepted for promotion by pitti 2 days ago)
[12:20] <Diziet> Hmm, my testbed only has room for another 3 installs (I give them 10GB each).  Maybe I should garbage-collect some of them.
[12:25] <Kamion> pitti: xmltoman doesn't seem to have an inclusion report, so if I promote avahi, we won't be able to build it any more
[12:25] <Kamion> build avahi, that is, until xmltoman's promoted
[12:26] <pitti> *sigh*
[12:26] <pitti> how many different implementations of xml->man converters do we have already?
[12:26] <Kamion> p.s. somebody please fix jack-audio-connection-kit not to need type-handling, or akode not to need jack-audio-connection-kit, or something
[12:26] <StevenK> pitti: As many as Debian?
[12:27] <pitti> Kamion: I'll review it
[12:27] <Kamion> pitti: also libdaemon has no report
[12:27] <pitti> it's just a simple arch:all perl script anyway
[12:29] <pitti> Kamion: xmltoman is fine, I'll write a report now and approve it
[12:31] <Kamion> pitti: ok, stick it straight in the promoted section
[12:31] <pitti> yep
[12:32] <infinity> Kamion: Gah, you gave it back?  Meh.
[12:32] <Kamion> infinity: I asked lamont to do it
[12:32] <Kamion> I guess he didn't check
[12:33] <Kamion> but either way, upshot is it's not in the archive :(
[12:33] <pitti> Kamion: I already asked Riddell to dop jack from akode, and he said he already fixed it
[12:33] <infinity> Grr.
[12:33] <pitti> Kamion: we should keep jack in universe to leave it uncrippled
[12:33] <infinity> Kamion: He gave it back RIGHT when it finished, so the buildd purged the files before it could move them to the upload directory.  Fine (and whacky) timing.
[12:34] <Kamion> pitti: ah, sparc is lagging on akode so anastacia still thinks it needs jack
[12:41] <fabbione> Kamion: it will take no less than 12 hours to get it there
[12:41] <fabbione> i can't build anythinig till gjc-4.0 is done
[12:41] <fabbione> assuming it can finish
[12:41] <fabbione> the circular depends between po-debconf/gettext/libgjc is a pain
[12:41] <pitti> Kamion: libdaemon looks reasonable, I'll write a report, too
[12:42] <pitti> Kamion: in fact such a lib is a nice idea
[12:44] <pitti> Kamion: I'll put it right into promoted as well, shall I?
[12:45] <Kamion> pitti: yes
[12:47] <Kamion> seb128: ok, promoted now
[12:47] <seb128> Kamion: thanks
[12:51] <jbailey> Kamion: I can ask, but from the things they've shown me, yes.
[12:52] <jbailey> Kamion: Part of what they had talked about was going through and putting a file or something that was unique in each filesystem and just searching for it.
[12:52] <jbailey> Kamion: If you can search for files and construct arbitrary paths, looking in a directory and constructing arbitrary filenames seems like a logical step.
[12:54] <Kamion> that would significantly improve boot menu usability on multiple-boot machines of which more than one of the installations is frequently upgraded
[01:06] <jdub> mjg59: ping
[01:26] <rikai> later all , to bed with me o/
[01:27] <Den> Is there a way to boot into an ubuntu cd iso image on the hard disk?  ie, I'm running ubuntu, i have an ubuntu cd iso in /hda5/home/me/ubuntu.iso, now can I boot into that cd iso image?
[01:28] <Treenaks> Den: burn it to CD, boot from Cd
[01:28] <Den> Treenaks: yeah, I know that option
[01:28] <Den> Treenaks: but how about what I asked about?
[01:29] <Treenaks> Den: impossible / VERY hard
[01:29] <Den> ok thanks
[01:29] <Gagatan> Den: qemu -cdrom <iso-image> -boot d    slow as hell
[01:29] <Gagatan> if you want to test e.g. a livecd
[01:29] <Kamion> note that that emulates a machine booting that CD, though
[01:29] <Kamion> it won't test whether your machine can boot it
[01:30] <Den> so, as of today, in the linux world, there's no way to just plain boot like i described, right?
[01:30] <Kamion> no
[01:30] <Den> thanks
[01:32] <ogra_ibook> i be you could do it with decent knowledge of the initramfs internals ...
[01:32] <Kamion> ogra_ibook: it would need significant bootloader cooperation as well
[01:33] <ogra_ibook> boot into busybox, mount the iso and boot into it ... but you wouldnt know if the kernel and booting in the iso works
[01:33] <Kamion> jdub: bugger off
[01:33] <ogra_ibook> s/in/of/
[01:33] <jdub> heh
[01:34] <jdub> Kamion: that bcm driver port just saved you from that mol userspace driver feature ;-)
[01:34] <ogra_ibook> pfft 
[01:34] <Kamion> I'm owed a release cycle of being able to clean stuff up as it is; was hoping it would be this one but that so didn't happen
[01:34] <ogra_ibook> if it would work stable in any way
[01:34] <BenC> bcm is stable for me
[01:35] <ogra_ibook> if i go 10m away from my AP it hardlocks my system
[01:35] <Treenaks> ogra_ibook: bcm43xx ?
[01:35] <BenC> I haven't tried going out of range yet
[01:35] <ogra_ibook> and if i run it at 54mbit my left knee melts
[01:35] <BenC> are you running 2.6.15-11?
[01:35] <ogra_ibook> Treenaks, yup
[01:35] <ogra_ibook> not yet
[01:35] <ogra_ibook> i'm still at -10
[01:35] <BenC> you have yours working at 54M?
[01:36] <ogra_ibook> yes, but it heats up heavily
[01:36] <BenC> mine wont even link past 24M
[01:36] <ogra_ibook> i have to drop to 11M
[01:36] <BenC> this is in your ibook?
[01:36] <segfault> is there any planned date for flight3?
[01:36] <Kamion> segfault: I hope sometime next week
[01:37] <ogra_ibook> BenC, yup
[01:37] <BenC> Kamion: I'll try to keep the kernel ABI at -11 for you
[01:37] <BenC> now that 2.6.15 is final, it shoudn't be such a moving target
[01:37] <Kamion> good, thanks
[01:38] <segfault> upstreamfreeze means universefreeze too, or just main?
[01:38] <ogra_ibook> both
[01:38] <segfault> humm, ok
[01:39] <ogra_ibook> it was long announced that we'll do it this way this release because of the 3/5 year support cycle ...
[01:39] <ogra_ibook> all MOTUs should know about it
[01:40] <dholbach> although we should try to wangle a week or two more for universe - the motu crew had a bad time catching up on merges and were waiting on main merges in some cases as well
[01:41] <segfault> how about new packages? like those listed in UniverseCandidates
[01:42] <sistpoty> dholbach++
[01:42] <ogra_ibook> if you can guarantee they'll get enough testing for being 3-5 years supported by motu ...
[01:42] <ogra_ibook> dholbach, i thought that was clear anyway ...
[01:43] <ogra_ibook> dholbach, i think we event talked about two weeks back then ...
[01:43] <sistpoty> ogra_ibook: freezing upstream would be ok... but revu contains really many packages, I guess we'll never get these done in 9 days
[01:43] <dholbach> ogra_ibook: there's enough time after that - we're talking about a week or two and universe is (although we'll try to take care of it) not supported anyway"
[01:43] <ogra_ibook> 9 days ?
[01:43] <dholbach> sistpoty: january 19th
[01:43] <ogra_ibook> dholbach, sure
[01:43] <sistpoty> dholbach: phew... thought of 15th for some reason :)
[01:43] <segfault> i'll try to finish packaging dspam this weekend, it's a nice tool
[01:44] <dholbach> but we should really do a hardcore review day soon
[01:45] <seb128_> dholbach: you should get a system which makes easy for people to review quickly a package :p
[01:45] <dholbach> seb128_: revu2 is in the works :)
[01:46] <sistpoty> hehe
[01:48] <dholbach> we should take the point to the next TB meeting
[01:48] <dholbach> it's urgent our release team knows about our request
[01:48] <ogra_ibook> ??
[01:49] <Kamion> 'bzr shelve' rocks
[01:49] <ogra_ibook> dholbach, it was already agreed on that universe might delay up to two weeks
[01:49] <sistpoty> dholbach, ogra_ibook: maybe we should also do a motu-meeting again?
[01:49] <ogra_ibook> no need to bring it up again
[01:49] <ogra_ibook> sistpoty+++
[01:50] <dholbach> Kamion: can you confirm this point? universe uvf == main uvf +2 weeks?
[01:50] <Kamion> dholbach: https://wiki.ubuntu.com/DapperReleaseProcess explicitly contradicts that, but we'll be flexible with exceptions for universe
[01:51] <ogra_ibook> it was topic in the discussion we had before dapper started and agreed on in a TB meeting ... as well as in the BOF at ubz
[01:51] <Kamion> We have found in the past that newer universe packages tend to demand newer dependencies in main. Accordingly, universe will enter UpstreamVersionFreeze at the same time as main, in order to reduce dependency tension between newer versions of packages in main and universe. The exact details of sync and merge schedules will be the decision of the MOTU team. As in main, syncs and merges to universe after UVF must be verif
[01:51] <mjg59> jdub: Hi
[01:51] <Kamion> ^-- from the UBZ spec
[01:52] <Kamion> having universe UVF later was brought up in the discussions, but we decided against it in favour of simply being flexible with exceptions
[01:52] <ogra_ibook> hmm, you cut off the intersting part :)
[01:52] <dholbach> How do we decide about NEW packages?
[01:52] <Kamion> dholbach: that's the next sentence
[01:52] <Kamion> ogra_ibook: where did it cut off?
[01:53] <Kamion> dholbach: please read the spec
[01:53] <dholbach> Kamion: merci beaucoup
[01:53] <dholbach> yes
[01:53] <ogra_ibook> As in main, syncs and merges to universe after UVF must be veri
[01:53] <Kamion> must be verified to build and install on current Dapper (or exceptions granted for new or updated dependencies).
[01:53] <ogra_ibook> thats all i got 
[01:53] <Kamion> ogra_ibook: you could go and read the spec too though, it's just a copy/paste from that
[01:53] <ogra_ibook> i'm just doing :)
[01:53] <dholbach> Kamion: because that's what i need to know for AptGetOrg :-(
[01:54] <mvo> dholbach: will we have to update our script again?
[01:55] <dholbach> mvo: yes, it's broken atm :)
[01:55] <dholbach> rejoice! :)
[01:55] <mvo> dholbach: you broke it again :P ?
[01:55] <dholbach> er err erm, must be err apt-get.org ;-)
[01:55] <dholbach> i'll poke it
[01:56] <mvo> let's setup a bzr archive for it and poke it together
[01:56] <dholbach> mvo: later, food now, but i look forward to working on it
[01:57] <Kamion> infinity: is there any way that, when downloading a new live CD cloop from cdimage, I could automatically find out the kernel version for which its initramfs was built?
[01:58] <infinity> You could peer inside the initramfs and look at the /lib/modules/ directory...
[01:58] <infinity> Or I could give you a manifest of some sort.
[01:59] <Kamion> peering inside the initramfs involves mounting the cloop/squashfs or otherwise poking inside it, and generally is Hard Work
[02:00] <Kamion> oh, no, I download the initramfs separately, don't I
[02:00] <infinity> Well, no, cause I'm including the initramfs alongside the cloop...
[02:00] <infinity> Yeah.
[02:00] <Kamion> still kinda hard work though
[02:00] <Kamion> oh, hey, it's in the .manifest already, isn't it
[02:00] <infinity> I'm sure it's a one-liner with cpio.
[02:00] <Kamion> cjwatson@little:~/cdimage/scratch/ubuntu/live$ grep ^linux-image-2.6 i386.manifest
[02:00] <Kamion> linux-image-2.6.15-11-386 2.6.15-11.16
[02:00] <infinity> Oh, duh.
[02:01] <infinity> Also, DUH.
[02:01] <infinity> Did I mention *DUH*?
[02:01] <Kamion> ok, so in my copious free time I can make cdimage refuse to build images if the ABI of the kernel it's trying to use differs from that
[02:01] <infinity> I'm just glad someone other than me didn't really think clearly for 2 minutes.
[02:02] <Kamion> which will save a few coaster-quality images
[02:02] <infinity> Oh, hrm.  You need the kernel when building?  Of course.
[02:02] <infinity> Why don't I just dump the kernel in the same directory, solving the problem?
[02:02] <infinity> And you can build with that one.
[02:02] <infinity> Either a raw kernel or the .deb, or whatever you need.
[02:03] <Kamion> that's a good plan, yes, just the vmlinu* will do
[02:03] <Kamion> it's vmlinux on some architectures and vmlinuz on others, I think
[02:03] <Mithrandir> you want the initramfs as well, don't you?
[02:03] <infinity> I'll just cp -a /boot/vmlinu*
[02:03] <infinity> Ish.
[02:03] <Kamion> Mithrandir: already have it
[02:03] <Mithrandir> 'k
[02:04] <infinity> Mithrandir: Having the initramfs is the whole problem, really, since he needs a kernel to match. :)
[02:04] <Kamion> yeah, will be some fiddling around when finding the kernel image, but it's the right thing to do
[02:04] <Kamion> thanks, I'm glad *you* were thinking clearly for this one ...
[02:04] <infinity> It's rare, but it happens.
[02:05] <infinity> Any naming scheme you'll want for those, or just ${image-prefix}-${basename}?
[02:07] <Kamion> hmm, I think $image_prefix.kernel; my scripts need to know whether it's a vmlinux or a vmlinuz for each architecture *anyway*, so there's no loss in forgetting that information temporarily
[02:07] <Kamion> but it can be .vmlinux/.vmlinuz if that's too icky for you
[02:08] <infinity> Well, I was going to have the full kernel name, so you can quickly see the ABI/flavour, etc...
[02:08] <infinity> Unless that's useless info to you.
[02:08] <Kamion> it's awkward because I have to download it
[02:09] <infinity> lftp does wildcards. :)
[02:09] <Kamion> ... automatically
[02:09] <infinity> (and is scriptable)
[02:09] <Kamion> I don't mind the ABI/flavour being in the filename as long as there's a symlink with a consistent name
[02:09] <infinity> Oh, yeah.  That's the sane way.
[02:09] <infinity> Damn sanity.
[02:10] <infinity> Actually, screw it.  The ABI isn't in the initramfs I copy, I'll take it out of the kernel too.
[02:10] <infinity> And, as pointed out, the manifest has it.
[02:11] <Kamion> "/usr/share/debconf/confmodule: line 40: return: set: numeric argument required"
[02:11] <Kamion> Mithrandir: ^-- that's between "Shadow passwords are now on." and "Generating locales..." in live CD startup; don't know where the bug is
[02:12] <Mithrandir> Kamion: can you run it with DEBCONF_DEBUG=. ?
[02:13] <Mithrandir> I'm wondering if it's the debconf-communicate going awry
[02:13] <Kamion> I think it must be after that given that it's after shadowconfig on
[02:13] <Kamion> which is called by user-setup-apply
[02:14] <Kamion> oh ... shadowconfig on writes to stdout. maybe that's confusing debconf
[02:15] <Mithrandir> hmm, actually, I don't do any debconf-ish things between before user-setup-apply and long after locale-gen
[02:17] <Kamion> oh, it *is* the debconf-communicate
[02:17] <infinity> Kamion: Okay, testing on royal right now.
[02:17] <Kamion> I think your shell syntax for newlines is off - the newlines are ending up in the value of passwd/user-uid
[02:18] <Kamion> Mithrandir: you need a real newline rather than \n, I think
[02:18] <Mithrandir> Kamion: I probably should use printf
[02:18] <Kamion> Mithrandir: use a here-doc
[02:18] <Kamion> debconf-communicate <<EOF
[02:18] <Kamion> ...
[02:18] <Kamion> EOF
[02:18] <Mithrandir> ah, point.
[02:18] <Mithrandir> I tend not to remember about heredocs
[02:20] <Mithrandir> Kamion: I'll fix that and the make rofs mount visible to you after I've gotten the keymapper stuff working.  Might not be today.
[02:21] <Mithrandir> heredoc fix done, though
[02:22] <Kamion> Mithrandir: thanks
[02:24] <jbailey> seb128: Why does gnomevfs2 now bring in avahi?
[02:24] <Kamion> Mithrandir: you also need to >/dev/null debconf-communicate
[02:25] <Mithrandir> Kamion: I know
[02:25] <Kamion> ok
[02:25] <Mithrandir> (done, committed)
[02:26] <Mithrandir> Kamion: keymapper is causing me grief, though.  I can't get it to give me sane decision trees. :-(
[02:27] <seb128> jbailey: because it's built with it? :)
[02:28] <seb128> jbailey: it does dns-nd
[02:29] <seb128> jbailey: you can automatically get the shares listes by nautilus then by example
[02:29] <jbailey> seb128: Does it automatically find other machines / listen to mdns traffic?
[02:30] <jbailey> seb128: Neat.  Does it do that by default, or do we still do no listeners by default?
[02:30] <jbailey> I've had a few questions about networking machines together, so this'll be lovely to have.
[02:31] <seb128> I don't really know the details (for mdns by example)
[02:31] <seb128> it should list _ftp._tcp / _webdav._tcp / _webdavs._tcp / _sftp-ssh._tcp by default though
[02:32] <Treenaks> seb128: how is this different from libnss-mdns?
[02:32] <mvo> stupid question maybe, but why does it have this funny names "_ftp", "_webdav"?
[02:32] <Treenaks> mvo: they are SRV records
[02:32] <Treenaks> mvo: those have names like that, by convention
[02:32] <seb128> Treenaks: I don't know, I've not really played with zeroconf stuff, I've no setup for that and I don't know how it works exactly
[02:32] <mvo> Treenaks: aha, thanks
[02:33] <infinity> Kamion: http://royal.buildd/~buildd/LiveCD/dapper/base/current/
[02:33] <infinity> Kamion: That'll do?
[02:33] <jk_work> on what kind of network could I expect to find actual zeroconf services?
[02:33] <Treenaks> jk_work: any network with a mac on it ;)
[02:34] <infinity> Kamion: (Arches with only 1 flavour get the convenience symlink, just like they do for the initrd)
[02:34] <Kamion> fabbione: new rescue uploaded to Debian
[02:34] <Kamion> infinity: perfect
[02:36] <jdub> mjg59: still there
[02:36] <jdub> ?
[02:36] <mjg59> jdub: Hi
[02:36] <jdub> yo
[02:37] <infinity> Kamion: Okay, rolled out all over.  Should start working for you as things become installable.
[02:38] <infinity> Kamion: Which, it looks like, I may need to dedicate a day or two to again...
[02:38] <Kamion> infinity: ubuntu-desktop is installable, at least
[02:39] <Kamion> as is kubuntu-desktop. edubuntu-desktop is uninstallable though
[02:39] <lamont> morning all
[02:39] <slomo_> Treenaks: libnss-mdns is only for resolving hostnames... the gnome-vfs zeroconf support lists published services (at least the ones seb128 has said above) in "network"... similar to the samba support
[02:39] <Treenaks> slomo_: ok.. so you still need both?
[02:40] <Kamion> infinity: thanks! could you start off some builds with that now so that I can test out the cdimage side?
[02:41] <infinity> Kamion: I can, but I dunno how many things other than base build right now...
[02:41] <infinity> Oh, actually, the world doesn't look that broken.
[02:41] <infinity> Shock.
[02:42] <mjg59> infinity: madwifi-ng crack kthxbi
[02:43] <infinity> Kamion: I'll give you ubuntu on all arches to play with.  You don't need {ku,edu} too, do you?
[02:43] <slomo_> Treenaks: depends on what you want to do :)
[02:43] <Kamion> infinity: nope
[02:43] <Kamion> yeah, I kicked various bits of the world last night
[02:44] <zul> hey
[02:44] <ogra> Kamion, hmm, i dont see anything that holds back edubuntu-desktop in dapper_probs.html or the cdimage report
[02:47] <infinity> mjg59: It's a weekend project, I think.
[02:47] <infinity> mjg59: Bug me on Monday if you've heard no news.
[02:48] <mjg59> infinity: No problem
[02:48] <Kamion> ogra: I haven't looked. If you want to, debootstrap a clean chroot with only main and restricted in sources.list and try to apt-get install edubuntu-desktop.
[02:48] <Den> Den: Actually, I'm not sure if firewire CD drives will work... We fixed the SCSI issue, but we may not be including everything required to make your setup go.  I'd still appreciate it if you could test, though.
[02:48] <Den> [01:10]  <infinity> Den: And if it doesn't boot, file a bug report on the "casper" package, pretty please (with sugar on top)
[02:48] <Den> infinity: It didn't boot.
[02:49] <ogra> Kamion, i will tonight... have ti rush to the DC now to replace my mailserver
[02:49] <ogra> s/ti/to/
[02:49] <Den> Anything you want me to do befor filing a bug report
[02:49] <infinity> Den: Yeah, talk to Mithrandir.  He maintains casper. :)
[02:49] <infinity> (and it's 1am for me, so I care about this much --><-- right now...)
[02:51] <Den> Mithrandir: Dapper doesn't boot on my sony vaio laptop with cdrom in the base station.  cd is 1eee1394 firewire, using scsi to access.  DO you want a bug report filed?
[02:53] <Mithrandir> Den: what module do you ordinarily use to access the firewire stuff?  I don't have any such beast here, so it'll be a bit hard for me to debug. :-)
[02:54] <Den> Mithrandir: the Breezy llive cd boots fine] 
[02:55] <Den> Breezy installed fine to my HD also, and that boots fine off the HD.
[02:55] <fabbione> Kamion: great
[02:55] <Mithrandir> Den: sure, but I need to know what modules to add.  If you give me that, I can fix it.  (And I'll need it if you file a bug as well as if you talk to me on IRC. :-)
[02:55] <Den> I haven't loded any modules by hand - Breezy just worked.
[02:56] <infinity> Den: Yes, but breezy used an entirely different method.
[02:56] <Den> Be specific about what you want - yuo want me to boot breexy & do an lsmod?
[02:56] <infinity> Den: It had a full debian-installer on the livecd, which would probe/load everything in existance.
[02:56] <infinity> Den: The dapper setup is much.. Slimmer.
[02:57] <Den> tell me specifically what info you need
[02:57] <infinity> An lsmod in breezy would be a good start, yeah.
[02:58] <infinity> We can spot cdrom/sr_mod in the lsmod output, and track up to see what's using it.
[02:58] <tuhl> is there a specialized IRC channel for  ubuntu-server ?
[02:58] <infinity> tuhl: Yes, #ubuntu-server.
[02:58] <zul> yeah #ubuntu-server
[02:58] <Mithrandir> Den: yes, the output of lsmod from an installed system which can access the ieee1394 drive should be enough for me to dig through
[02:59] <Den> I was told a while ago (erm, this was on Debian testing from `1 yr ago, with a 2.4 kernel, that all that has to be done is 1st load ieee1394 firewire support, then load scsi on top of that, then the linux kernel will see the cdrom drive
[03:00] <infinity> Den: Sure, but neither of us knows precisely what that entails, not having such a setup at all.  So, the lsmod output should be enough to know what we need.
[03:00] <Den> Is Dapper live cd loding the ieee1394 firewire, then loading scsi (on top if firewire)?
[03:00] <infinity> Mithrandir: Incidentally, we probably want this for USB CD drives too.
[03:00] <Mithrandir> Den: it's probably not loading ieee1394.
[03:01] <Den> is it easy to put ieee1394 into the daily build of Dapper - if so, I'll try it out asap
[03:02] <Mithrandir> infinity: do we need more than usb-storage, [eou] hci-hcd?
[03:02] <Mithrandir> Den: yes, it's easy.  My weekend is almost here and I'm dead tired, so I'm probably not going to upload any such changes until monday the earliest, but if I gave you an ISO, could you test it for me?
[03:03] <Den> yes - but "give me an iso" how?
[03:03] <Mithrandir> I can make one and you can download it over HTTP?
[03:03] <infinity> Kamion: Looks like it's only going to succeed on i386/amd64, since OOo2 is still building on powerpc, and ia64 just looks completely horked.
[03:04] <Den> can I rsync it from todays iso?
[03:04] <infinity> Kamion: So, hopefully you can test on one of the former. :)
[03:04] <Mithrandir> Den: that's a bit hard over HTTP. :-)
[03:04] <Kamion> infinity: yeah, normally using i386/amd64 at the moment
[03:04] <Mithrandir> Den: I could nuke the live part of the image, though, so it won't be a huge download?
[03:05] <Mithrandir> Den: it won't _work_ that way, but we can check if it would have if it could have mounted the image
[03:05] <Den> noo problem, just let me know where to get it from & I'll dl it, burn it & try it & tell you what happens
[03:06] <Den> Mithrandir:  when will you have it ready
[03:06] <Mithrandir> Den: give me 30 minutes or so
[03:07] <infinity> 28326 pts/2    D+     0:00 dpkg --status-fd 8 --configure --pending --force-configure-any --force-depends
[03:07] <infinity> Why.  The.  Fuck.  Is that in D state?
[03:07] <fabbione> infinity: is that amd64 k8?
[03:07] <infinity> Kamion: Does debootstrap hate me?
[03:07] <Den> Mithrandir: I've gotta get ofline now, can you email me a msg as to what I need to do?
[03:07] <infinity> fabbione: No, i386.
[03:07] <Mithrandir> Den: sure, /msg or email?
[03:07] <fabbione> infinity: o
[03:07] <fabbione> k
[03:07] <Mithrandir> Den: if email, I need your mail address
[03:08] <Den> Mithrandir: hereon1@fastmail.us
[03:08] <Mithrandir> Den: cheers. :-)
[03:08] <Den> Mithrandir: do you still want the lsmod from my booted Breezy?
[03:09] <Mithrandir> Den: yes, please.  tfheen@ubuntu.com
[03:09] <Mithrandir> or /msg
[03:09] <Den> Mithrandir: what is "/msg"?
[03:09] <Mithrandir> if you do /msg Mithrandir you'll get a window where you can give me information privately.  Just so you don't flood the channel.
[03:09] <Mithrandir> just type it into the window
[03:10] <Den> I'll get you the lsmod in about 15 -30 min
[03:10] <Den> thanks, bye
[03:10] <Mithrandir> thanks
[03:10] <infinity> Hrm, okay, maybe if another build hadn't been stuck in an infinite loop, the world may have been happier.
[03:11] <Kamion> infinity: seems a bit unusual, that
[03:12] <infinity> Kamion: Yeah, nevermind, the machine has half hosed, due to some retarded debian/rules looking for CPAN a few billion times per second, or something.
[03:12] <Kamion> heh
[03:14] <Den> Mithrandir: Ok, I got the lsmod in a  file - my nick isn't registered on freenode, so I don't thnk I can msg you, unless you turn on that capability from a nonreg nick.  You want to do that, or hae me email the lsmod to you?
[03:15] <Mithrandir> Den: just mail it to me.  I thought I had turned it on, but freenode seems to turn it off nilly-willy
[03:25] <Den> Mithrandir: It should be in your email now
[03:25] <infinity> Kamion: amd64 is ready.  i386 is lagging due to the aforementioned infinite loop.
[03:25] <Mithrandir> Den: great.  ISO is available at http://err.no/tmp/live-test.iso
[03:25] <Den> I'm dling it already
[03:26] <Den> thanks all, gotta get to sleep
[03:26] <Den> bye
[03:28] <Mithrandir> I'm off for the weekend.
[03:29] <Den> Mithrandir: is ubuntu employer or volunteer for you?
[03:29] <tseng> he's off :)
[03:29] <Mithrandir> Den: I'm paid to work on ubuntu
[03:31] <Den> Mithrandir: cool -n thanks for yuour help
[03:31] <Den> bye
[03:35] <zul> why its only 1 am :)
[03:36] <infinity> Thpt.
[03:37] <pitti> elmo: please sync rus-ispell from sid
[03:48] <infinity> Kamion: i386 done.  Now I'm gone for good. :)
[03:56] <pitti> Kamion: 'check' approved as gst 0.10 build dep
[03:59] <pitti> seb128: any other urgent reviews needed?
[04:02] <Kamion> promoted
[04:03] <seb128> pitti: urgent nop
[04:03] <seb128> pitti: xchat-gnome uses libsexy but we can build without it and there is no hurry
[04:04] <Diziet> I just got a random internal server error from bugzilla.  It went away when I reloaded.
[04:06] <mdz> infinity: we shouldn't need to worry about file ordering with squashfs except as an optimization
[04:06] <mdz> infinity: each file is compressed separately, as I understand it
[04:07] <doko_> infinity: is openoffice.org2 still building on amd64?
[04:09] <Kamion> doko_: it built ages ago
[04:09] <Kamion> openoffice.org2 | 2.0.1-0ubuntu3-1 |        dapper | amd64
[04:10] <pitti> doko_: you mean powerpc?
[04:11] <doko_> Kamion: I can't see the build log on p.o.c/~lamont
[04:12] <Kamion> doko_: were you looking in openoffice.org2 rather than openoffice.org2-amd64 by mistake?
[04:12] <Kamion> it's there, under the latter
[04:12] <doko_> and it's still the 2.0.0m143-0ubuntu3 in the archive
[04:13] <Kamion> only for sparc
[04:13] <Kamion> openoffice.org2 | 2.0.0m143-0ubuntu3 |        dapper | sparc
[04:13] <doko_> Kamion: no, openoffice.org2 builds native packages on amd64 and suffixes them -experimental
[04:13] <doko_> that will go away for the release, when we decide which packages we ship
[04:14] <Keybuk> mdz: I have SUCH an elegant redesign of readahead :p
[04:14] <pitti> Keybuk: dd > /dev/null? :)
[04:14] <Kamion> doko_: amd64's excluded for openoffice.org2 in Packages-arch-specific
[04:14] <Keybuk> every package that includes an init script should stick a file in /var/lib/readahead listing the things it reads from, or causes to be read, etc.
[04:14] <lamont__> Keybuk: I don't think you're allowed to use the words "elegant" and "readahead" in the same sentence
[04:14] <Kamion> doko_: you need to get elmo or lamont or infinity to update that if you want it to build there
[04:14] <Keybuk> and in postinst call update-readahead if it exists
[04:14] <Keybuk> and that looks through rc*.d and builds up early, middle and late lists and sorts the files by block on fs
[04:15] <Keybuk> is shiny
[04:15] <lamont__> doko_: %openoffice.org2: i386 sparc powerpc
[04:15] <lamont__> and note that ubuntu uses the debian file, so changing it will mean that debian also tries to build oo.o2...
[04:15] <doko_> Kamion: ok, just wondering why it built before ...
[04:16] <Kamion> doko_: it didn't
[04:16] <Kamion> cjwatson@jackass:~$ ls queue/done/openoffice.org2_*_amd64.changes
[04:16] <Kamion> ls: queue/done/openoffice.org2_*_amd64.changes: No such file or directory
[04:16] <Kamion> at least not as far as I can see
[04:16] <doko_> lamont__: debian doesn'tz have ooo2 anymore
[04:16] <doko_> apt-cache show openoffice.org2-core-experimental
[04:16] <doko_> Package: openoffice.org2-core-experimental
[04:16] <doko_> Priority: optional
[04:16] <doko_> Section: universe/editors
[04:16] <doko_> Installed-Size: 118164
[04:16] <doko_> Maintainer: Debian OpenOffice Team <debian-openoffice@lists.debian.org>
[04:16] <lamont__> ah, kewlness
[04:16] <doko_> Architecture: amd64
[04:17] <doko_> Source: openoffice.org2
[04:17] <doko_> Version: 2.0.0m143-0ubuntu3
[04:17] <doko_> lamont__: be we'll have the problem again when we rename the package
[04:17] <mdz> Keybuk: tell me about it
[04:18] <Kamion> doko_: ah, ok, last month before the last clear-out of queue/done then
[04:18] <Kamion> maybe P-a-s was different then
[04:18] <Keybuk> mdz: just did ;)
[04:18] <doko_> btw, what version number should I use for breezy-updates?
[04:19] <mdz> and I just read it ;-)
[04:19] <lamont__> Kamion: if we built it, PaS didn't say not to
[04:19] <mdz> I should increase my sliding response window
[04:19] <Keybuk> oh, and it'll include an audit-me program you stick in your init script while testing and builds that list for you
[04:19] <Keybuk> that daemonizes, loops reading the process table and maps for everything under its own parent process until its parent dies
[04:20] <Keybuk> (where its parent = the init script)
[04:20] <sabdfl> seb128: fyi, links in email are still not opening up firefox
[04:20] <mdz> Keybuk: will that give high enough resolution to catch small files?
[04:21] <jsgotangco> good evening
[04:22] <Keybuk> mdz: should do; the other option is to strace, but that doesn't tell us (reliably) how the file is being used
[04:23] <lamont__>  Diziet I just do that with gnome-session
[04:23] <mdz> Keybuk: hmm?  the syscall arguments should make that clear enough
[04:24] <Diziet> My mirror seems skew.  When do Release* etc. get updated ?
[04:24] <Keybuk> mdz: true
[04:24] <lamont__> Diziet: every 30 minutes or so
[04:24] <Keybuk> easy enough to trace parent as well
[04:24] <lamont__> at somewhere between :10 and :20, and again 30 min after that, roughly.
[04:24] <seb128> sabdfl: what does "gconftool-2 -g /desktop/gnome/url-handlers/http/command" say?
[04:24] <lamont__> depends on archive processing times.
[04:25] <mdz> Keybuk: could also inotify everything which might be worth readaheading; it's only 20k or so directories ;-)
[04:25] <mdz> Keybuk: or vm.block_dump
[04:25] <Keybuk> doesn't block_dump indicate writes?
[04:25] <sabdfl> seb128: mozilla-firefox %s
[04:25] <mdz> is it only writes?
[04:25] <Keybuk> dunno
[04:26] <Keybuk> that's lower-level than I usually like to get
[04:26] <Keybuk> at least, without protection, anyway
[04:26] <mdz> When this flag
[04:26] <mdz> is set, Linux reports all disk read and write operations that take place, and
[04:26] <mdz> all block dirtyings done to files
[04:26] <Diziet> lamont__: Hmm, tedious.
[04:27] <Keybuk> does it say what asked for that though?
[04:27] <lamont__> Diziet: yeah - I wrote a script that just smashes itself against the wall until the Release file is consistant with all the Packages/Sources files.
[04:27] <mdz> I think it may have a pid
[04:27] <seb128> sabdfl: what does "grep firefox ~/.gconf/%gconf-tree.xml" say?
[04:27] <mdz> Jan  6 07:27:31 localhost kernel: [4786666.135000]  zsh(27642): dirtied inode 145441 (var) on sda1
[04:27] <mdz> you would have to map the inode numbers back to files though
[04:28] <mdz> since it doesn't provide the path
[04:28] <Keybuk> of course it doesn't, that'd be helpful ;)
[04:28] <lamont__> mdz: so /var/ is sda1?
[04:28] <lamont__> or is var the inode on sda1
[04:28] <mdz> lamont__: var is the name of a file in some directory on the filesystem on sda1
[04:29] <mdz> e.g. Jan  6 07:27:30 localhost kernel: [4786665.979000]  workrave(6163): dirtied inode 2711137 (todaystats) on sda5
[04:29] <lamont__> ah, ok
[04:29] <mdz> that's /home/mdz/.workrave/todaystats
[04:29] <sabdfl>                                         <stringvalue>firefox_launcher</stringvalue>
[04:29] <sabdfl>                                 <dir name="firefox_launcher">
[04:29] <sabdfl>                                                         <stringvalue>firefox_launcher</stringvalue>
[04:29] <sabdfl>                                                 <dir name="firefox_launcher">
[04:29] <sabdfl>                                                 <stringvalue>mozilla-firefox %s</stringvalue>
[04:29] <sabdfl> ... repeat the last line 3 times
[04:30] <seb128> sabdfl: seems you played once with the setting (from the GNOME capplet to set the default browser by example) and it's set as an user setting now, nothing we can change on upgrade from GNOME
[04:30] <sabdfl> seb128: seems that we definitely we want to do something extra here
[04:30] <seb128> sabdfl: firefox should really ship a mozilla-firefox to firefox link to avoid such breakage
[04:31] <sabdfl> surely the postinst can find and correct these?
[04:31] <seb128> postinst go visit all the user directory and change user datas... hum
[04:31] <seb128> I would rather ship a mozilla-firefox compatibility link with firefox
[04:32] <seb128> mdz: what do you think?
[04:33] <seb128> mdz: some user have "mozilla-firefox" as default browser (user setting), and we changed the binary name to firefox since
[04:33] <mdz> seb128: if it has the value mozilla-firefox and there is no mozilla-firefox in the default PATH, we should migrate it to firefox
[04:33] <infinity> mdz: Ahh, slick.  (re: squashfs compression)
[04:33] <mdz> oh, it's in the home dirs
[04:33] <mdz> ick
[04:34] <mdz> compat symlink sounds ok
[04:34] <seb128> mdz: it's an user gconf setting, they changed it with the preferred app capplet ...
[04:34] <infinity> Kamion / doko: openoffice.org2 got amd64 added to P-a-s a while back, but elmo probably needs a ping to sync.
[04:34] <infinity> elmo: P-a-s sync, please.
[04:34] <seb128> mdz: k, thanks
[04:35] <seb128> sabdfl: are you ok with having a symlink mozilla-firefox/firefox to fix the issue?
[04:35] <lamont__> keyboard chooser is still borked in the presence of no keyboard
[04:36] <sabdfl> seb128: only partly. mdz, this is a good example of stuff the upgrade tool should be able to sort out
[04:37] <mdz> sabdfl: yes, eventually, but it's beyond the scope of the first iteration we've specified
[04:37] <Diziet> I'm currently trying to figure out whether this binary name change is anything to do with the x-www-browser breakage, btw.
[04:38] <Diziet> Also, wasn't someone going to talk to Mozilla upstream to ask them if it was OK for us to call it mozilla ?  That would save a fair amount of pain.
[04:38] <mdz> Diziet: does firefox even try to migrate the alternative?
[04:38] <mdz> Diziet: jdub, please ping him on it
[04:38] <Diziet> The maintscripts will remove the old alternative and provide the new one.  Which ought to migrate it.
[04:39] <infinity> (If it hasn't been thrown into manual, due to a danling alternative link along the way)
[04:39] <Diziet> jdub: AYT ?  Have you talked to mozilla about {mozilla-,}firefox ?
[04:39] <infinity> Yay, update-alternatives.
[04:39] <Diziet> infinity: I tested it and it didn't seem to mind dangling alternatives.
[04:40] <infinity> Ahh, maybe the dangle is only a problem when creating an alternative.
[04:40] <Diziet> Is the mirror update at :10 or :20 ?
[04:40] <infinity> I know there's a dangling situation that will magically shove you into manual mode.
[04:40] <infinity> Which sucks.
[04:40] <Diziet> I mean, the ftp site update.
[04:40] <Diziet> That's pretty crappy.
[04:40] <Diziet> I'm about to test an instrumented upgrade.  As soon as I can get my mirror back into shape.
[04:40] <infinity> Diziet: Starts at :03 and :33... Lasts as long as the cronjob runs, then triggers mirrors.
[04:41] <infinity> Diziet: Roughly :20 and :50 for most mirrors, I'd suspect.
[04:41] <Mithrandir> hmm, I think I gave Den an amd64 iso.. hope he has an amd64. :-P
[04:41] <Diziet> I'm getting directly from archive.ubuntu here atm.
[04:42] <infinity> Diziet: Right, which is a round-robin of mirrors, based on the real ftpmaster behind them.
[04:42] <Diziet> The problem I have is that my mirroring program downloads md5sums at the beginning and Release* near the end (due to the way the alphabet happens to fall).
[04:42] <Diziet> By the time it gets to downloading the Release* they don't match up any more.
[04:42] <Diziet> Specifically, they refer to files not in the md5sums.
[04:42] <infinity> Diziet: Fix your mirroring program to grab Sources/Packages/Release last.
[04:43] <Diziet> The mirroring program currently doesn't have any Debian-specific knowledge.
[04:43] <Diziet> It also assumes (not unreasonably) that there will be a quiet time for you to take the snapshot.
[04:43] <infinity> Ahh, shame.
[04:43] <Diziet> I could take a day to fix it to construct the mirror out of Release I suppose.
[04:44] <Diziet> That would make mirroring specific suites possible too.
[04:44] <infinity> The "anonftpsync" script used by most Debian mirrors works pretty well in the face of Debian/Ubuntu mirror processes.
[04:44] <Mithrandir> infinity: yeah, or debmirror.
[04:44] <infinity> Or that.
[04:44] <Nafallo> apt-proxy wfm ;-)
[04:45] <Kamion> sabdfl: on root-squashed NFS, of course, an upgrade tool running as root won't even be *able* to change user settings ...
[04:46] <slomo_> infinity: please give-back gst-plugins-base0.10 on i386, thanks :)
[04:48] <mdz> Kamion: I: Found additional base dependencies: modutils
[04:48] <mdz> Kamion: do you know what's causing that?
[04:49] <infinity> slomo_: Rebuilding.
[04:49] <Diziet> In fact, my program downloads things in the order of the supplied md5sums.gz.  But the order listed is pessimal.
[04:49] <janimo> elmo, please delete the xfprint and xffm4-icons source packages from the archive. They are deprecated by xfprint4 and xffm4 and cause needless confusion for users. thank you
[04:50] <Kamion> mdz: various packages have Depends: modutils | module-init-tools; switching the order of the alternatives should make that go away
[04:51] <janimo> weird, since latest ffox update I can't connect to the wiki
[04:51] <Keybuk> modutils must die!
[04:51] <doko_> infinity: do you know any reason that the bittorrent package is that behind in debian/ubuntu compared to upstream. you did the last sync ...
[04:52] <Kamion> Keybuk: alsa-base, alsa-utils, bluez-utils, pcmcia-cs
[04:52] <Kamion> I'll fix pcmcia-cs now
[04:55] <infinity> doko_: Not sure, no.  Haven't had a chance to poke the Debian maintainer about it.
[04:55] <infinity> slomo_: Failed anyway.
[04:56] <infinity> slomo_: Looks like an underlying library needs a rebuild before gst-plugins-base can build.
[04:57] <slomo_> infinity: i'll take a look at it... it failed previously because of gstreamer0.10 FTBFS on x86
[04:58] <infinity> slomo_: In this case, it's some build-dep referencing /usr/lib/libavahi-glib.la, which doesn't seem to exist.
[04:58] <infinity> slomo_: So, install the build-deps, grep for that in /usr/lib/*.la, rebuild the package that owns the offending file, profit.
[04:58] <slomo_> infinity: must be gnome-vfs2... seb128?
[04:58] <Keybuk> Kamion: alsa-* are on my hit list at the moment
[04:59] <infinity> slomo_: Or mail me about it (or bug me tomorrow) and I'll fix it.  It's too late for me to pretend to think right now.
[04:59] <slomo_> infinity: np :) i'll take care of it and when it isn't fixed until tomorrow i'll tell you
[04:59] <seb128> infinity: right, gnome-vfs2, I'll fix it
[05:00] <slomo_> ok
[05:00] <mjg59> lala
[05:01] <mjg59> libfoo.dipsy
[05:01] <infinity> Maybe I'll just sneak a filter into dpkg, and see if anyone notices.
[05:01] <pitti> infinity: pkgstriplafiles, we know the pattern :)
[05:02] <zul> infinity: didnt you say you were going to bed :)
[05:02] <janimo> infinity what's the problem with shipping .la files?
[05:02] <infinity> zul: I did.  I got up again.
[05:02] <janimo> I just recently had to relibtoolize a package
[05:02] <janimo> because of missing libXft.la
[05:02] <infinity> janimo: They're completely useless on GNU/Linux, and they break the world when they appear/disappear from version to version.
[05:02] <infinity> Best if they're just never there in the first place.
[05:03] <janimo> why do debian ship them?
[05:03] <janimo> shouldn't this be a policy if they are useless and break stuff?
[05:03] <infinity> Because "make install" generally installs them, and most people don't know/understand why they're evil/useless.
[05:04] <infinity> I'd love to push .la stripping into some tool like cdbs, so it becomes a defacto policy overnight, then slip it into Debian policy.
[05:04] <doko_> infinity: libltdl uses them to dlopen libs
[05:05] <Keybuk> infinity: they're not useless
[05:05] <Keybuk> they're required
[05:05] <Keybuk> if you ship the .a file, you need to ship the .la file
[05:05] <Keybuk> if you remove the .la file, you also need to remove the .a file
[05:05] <pitti> so much the better :)
[05:06] <Keybuk> and they're not evil
[05:06] <pitti> I doubt that we need static libs for the majority of libs
[05:06] <Keybuk> show me a problem with a .la file, and I'll show you a problem with the library
[05:06] <infinity> Oh, feh.  The static case.  Right.
[05:06] <infinity> Also, you're not supposed to care about libtool anymore, you gave it up.
[05:07] <infinity> Anyhow, I guess I need to remove the part of policy about including static libs, while I'm being subversive.
[05:07] <Keybuk> I still care about being able to compile and link stuff ;)
[05:07] <Keybuk> and I still know how it all works
[05:08] <janimo> so is there another reason to remove .la files?
[05:08] <janimo> I know libXft.la being recently removed caused a FTBFS
[05:08] <infinity> According to Keybuk, we need more of them, not less. :)
[05:08] <janimo> and needing to patch the upstream debian package
[05:09] <janimo> daniels, you know why libXft.la is gone?
[05:12] <infinity> janimo: At a guess, I'd say because Xorg now uses pkg-config to determine library dependencies.
[05:13] <infinity> (which doesn't have the nasty side effect of telling you to depend on .la files, but instead tells you to depend on libraries...)
[05:13] <Keybuk> hmm
[05:14] <Keybuk> if there's a .la file with another .la file in its dep list, that's usually a bug
[05:14] <lamont__> if I'm stupid enough to install xorg-server on a headless box, why does it ask me questions, I wonder...
[05:14] <Keybuk> I went on a crusade about 18 months ago to purge most of those
[05:14] <Keybuk> they should only occur if the other library comes from the same source
[05:14] <infinity> Keybuk: That happens all the time.  That's the reason for the FTBFS that just happened.
[05:14] <Keybuk> infinity: then somebody needs braining and being taught how to use libtool
[05:14] <infinity> Keybuk: Package A builds against Package B when Package B has a .la file.  Package A's .la get B's .la listed in it.  Then Package B drops the .la file, and Package A is broken.
[05:15] <Keybuk> Package A should only get -L/path/to/B -lB in it
[05:15] <infinity> Keybuk: All of GNOME is apparently broken.  We ran into this time and again during the breezy cycle.
[05:15] <Keybuk> where the -L would be dropped
[05:15] <mjg59> Why has gedit vanished from the menus? Surely it's an application that people want to use to create things?
[05:16] <Keybuk> GTK+ uses an infamously broken version of libtool
[05:16] <seb128> mjg59: ls ~/.local/share/applications/gedit* ?
[05:16] <mjg59> /home/mjg59/.local/share/applications/gedit.desktop
[05:16] <mjg59> "NoDisplay=true"
[05:17] <seb128> that's it
[05:17] <mjg59> So why did that get set?
[05:17] <seb128> that's the question
[05:17] <seb128> some app must write it
[05:17] <janimo> Keybuk, are platforms as varied today as 10 years ago as to be such a need for libtool?
[05:17] <janimo> and autotools?
[05:17] <mjg59> Hm, Odd.
[05:18] <Keybuk> janimo: it's an interesting thought
[05:18] <seb128> did you change the association for some mimetype with nautilus by example?
[05:18] <Keybuk> sadly it's still true
[05:18] <Keybuk> Solaris STILL doesn't have a decent link loader
[05:18] <seb128> mjg59: BTW I just figured what was causing the nautilus crasher on partial upgrade you had
[05:18] <seb128> mjg59: nautilus Depends on libnautilus-exnensions need to be updated
[05:20] <mjg59> seb128: Ah, cool
[05:24] <Keybuk> janimo: automake we'll need for ever, because it takes the pain away of writing decent Makefiles
[05:24] <janimo> Keybuk,I'd hoped Makefiles would go away too ;)
[05:25] <Keybuk> for a while, I vaguely linkered with building libtool directly into Automake, so it produced .c.o make rules, etc.
[05:25] <Keybuk> janimo: what would you use instead?
[05:25] <Keybuk> something has to specify how to build things
[05:25] <janimo> one of the newer build systems
[05:25] <Goshawk> hi, as you know the ubuntu-desktop package depends from a lot of packages, in particular it depends from usplash. now, can we change this dependece and set it to be usplash || upower. so upower can be installed without loosing upgrades
[05:25] <Keybuk> you need a "this goes here, that goes there, use these switches, etc."
[05:25] <janimo> scons/jam etc
[05:25] <Keybuk> imnso, the newer systems are HORRIBLE
[05:25] <Keybuk> with a syntax that came directly from the 18th level of hell
[05:26] <janimo> they may be more horrible than make but not more horrible than make with auto*
[05:26] <Keybuk> *shrug* I think they are
[05:26] <Keybuk> auto* are easy
[05:26] <Keybuk> autoconf is "write a bunch of shell code, and sprinkle in well-documented macro names"
[05:26] <stratus> Goshawk, upower?
[05:26] <janimo> to me it's the most ugly non-easy tool I have used
[05:26] <Keybuk> automake is "write your makefile, and sprinkle in well-document variables to get the magic"
[05:26] <janimo> including tla
[05:26] <Keybuk> ?!
[05:27] <Goshawk> stratus, yep, even more people in ubuntu use it
[05:27] <pitti> janimo++
[05:27] <Keybuk> bin_PROGRAMS = foo    (foo is a program that goes in .../bin)
[05:27] <janimo> automake is ok
[05:27] <Keybuk> foo_SOURCES = foo.c bar.c  (build it with foo.c and bar.c)
[05:27] <janimo> but autoconf sucks
[05:27] <Keybuk> that's easy
[05:27] <Keybuk> autoconf's fine
[05:27] <stratus> Goshawk, what's the source package name?
[05:27] <Keybuk> a small file listing things your program need
[05:27] <Goshawk> stratus, it's not in the default ubuntu report
[05:27] <janimo> generating 800Kbyte file for a  30 Kb C project
[05:27] <janimo> that's fun
[05:27] <Goshawk> stratus, www.nanofreesoft.org
[05:28] <Keybuk> if you have an 800KB file, you have someone who doesn't know what they're doing
[05:28] <stratus> Goshawk, oh i see so it makes no sense to list it as a Depends, IMHO.
[05:28] <Goshawk> stratus, or look for "upower" on ubuntuforums
[05:28] <pitti> janimo: and it really bites your testicles off if you ever have to change anything in a > 6 month old package...
[05:28] <Keybuk> the most important feature of auto* is that you don't need it to compile the programs
[05:28] <stratus> Goshawk, by default you can't satisfy it.
[05:28] <Keybuk> which just about every other "my first build system" fails on
[05:28] <Goshawk> stratus, i suggest usplash || upower
[05:28] <stratus> Goshawk, you should try merge upower changes back into usplash (if possible), if not you can try upload upower
[05:28] <psusi> you don't?  you need it to generate the makefile so you can compile the programs
[05:28] <pitti> Keybuk: I'd consider that a bug, not a feature
[05:28] <janimo> Keybuk, I am sure it's a powerful tool, but it's so complicated most people (yes developers) don't really grok it
[05:28] <janimo> myself included
[05:29] <stratus> Goshawk, but (by default) you can't satisfy the upower part of this depends.
[05:29] <Keybuk> pitti: why?
[05:29] <janimo> and a lot of time is wasted on fixing this crap instead of the program itself
[05:29] <Goshawk> stratus, so you suggesto to upload upower on the ubuntu repo?
[05:29] <stratus> Goshawk, i bet that you'll receive this response but you can try open a bug against ubuntu-desktop through bugzilla
[05:29] <Keybuk> imagine the hell if you got "Sorry, this source needs foobuild 1.0 and you have 1.1 installed"
[05:29] <Keybuk> etc.
[05:29] <Keybuk> which I have seen
[05:29] <Keybuk> *cough* ant
[05:29] <stratus> Goshawk, yes, let me look what's it
[05:30] <Goshawk> stratus, it's like usplash but more eye candy
[05:30] <pitti> Keybuk: there is a lot of redundant and big stuff, and updating it for bug fixes is painful and breaks too often
[05:30] <Keybuk> Goshawk: and less working
[05:30] <janimo> auto* is used so that every software can run on all old IRIX/AIX/HPUX whatever old PDP machines
[05:30] <janimo> dictatorship of minorities as drepper sais it
[05:30] <Keybuk> pitti: I agree, but I've never seen a replacement that solves that
[05:30] <pitti> Keybuk: and autoconf/make is an great example of how backwards compatibliity should *not* look like :/
[05:30] <janimo> it pulls the whole rest down
[05:30] <Goshawk> Keybuk, until now all the signed bugs have been solved
[05:31] <janimo> linux/bsd/solaris
[05:31] <infinity> Goshawk: ubuntu-desktop will never depend on something outside of ubuntu/main.  Don't bother filing the bug report, please.
[05:31] <stratus> Goshawk, talk with usplash folks and if they don't plan to merge the 'eye candy' stuff from upower, talk with MOTU folks and ask upower upload.
[05:31] <janimo> for the rest handmade makefiles if they have users :)
[05:31] <pitti> Keybuk: if it were backwards compatible, then it wouldn't even suck so hard, so maybe that's the actual source of my grief
[05:31] <stratus> thanks infinity 
[05:31] <Keybuk> Goshawk: does it work on all of the architures, and support every single graphics card out of the box?
[05:31] <Keybuk> pitti: that's more Debian's fault.  auto* have been backwards compatible for years; Debian just have never used the versions that they fixed those problems with
[05:31] <pitti> Keybuk: (although I still ask myself why I need a 500 byte patch for configure.in, and then a 1.2 MB patch for the resulting changes)
[05:31] <Goshawk> Keybuk, it support all the vesa compatible cards, but it will broke the suspend mode right now
[05:31] <psusi> I don't understand why people don't just write portable code that doesn't need hacks to work on various platforms
[05:32] <stratus> Keybuk, is usplash supporting every single graphics card out of the box?
[05:32] <Goshawk> Keybuk, many people have problem with upslash, try to look at ubuntuforums
[05:32] <psusi> cause that's basically what auto* does... detect what hacks need enabled on your platform
[05:32] <pitti> Keybuk: btw, that's one (of the few) things I really like about Java :)
[05:32] <Keybuk> pitti: yeah, I agree
[05:33] <Keybuk> pitti: one day I promised myself I'd write an automake-replacement that was as simple, but didn't need autoconf or libtool
[05:33] <Keybuk> IN MY COPIOUS FREE TIME
[05:33] <pitti> that you basically don't need a build system
[05:33] <Keybuk> because I don't care about anything other than Linux
[05:33] <pitti> Keybuk: *after* you finished wig&pen :)
[05:33] <Goshawk> stratus, thanks for your support
[05:33] <infinity> stratus: It supports any card that you can run a framebuffer on (unlike upower, which requires vesafb), so yes, close enough to supporting everything.
[05:33] <Keybuk> pitti: meh
[05:33] <stratus> Goshawk, you're welcome
[05:33] <Keybuk> pitti: that'd involve me not resigning from Debian at some point ;)
[05:34] <pitti> Keybuk: that would indeed be nice; I always looked for that kind of replacement, but it seems that scons is not the answer
[05:34] <stratus> infinity, oh thanks.
[05:34] <janimo> Keybuk oh and I forgot about automake-1.{X} but I think pitti said it
[05:34] <Goshawk> infinity, not, it do not use modern framebuffer it uses vga16fb (and old one)
[05:34] <infinity> Goshawk: It can use vesafb too.
[05:34] <Keybuk> pitti: fancy designing it with me at the sprint? ;)
[05:34] <infinity> Goshawk: We just use vga16fb by default (intentionally, no we won't change this)
[05:34] <Goshawk> infinity, try to put vga=792 on your grub sources.list
[05:34] <pitti> Keybuk: I basically have the same problem - I so much want it, but ENOTIME :(
[05:34] <Keybuk> *nods*
[05:34] <pitti> Keybuk: let's make it a high urgency dapper+1 spec goal :))
[05:34] <Goshawk> i did not appair on my system with vesa framebuffer
[05:35] <infinity> Goshawk: I run usplash with vesafb.  I also hack usplash, and co-maintain it.
[05:35] <Keybuk> anyway, gonna go hack on laptop for a bit, otherwise I'm not gonna finish this stuff today <g>
[05:35] <Keybuk> ping me if anything urgent, otherwise downstairs
[05:35] <Goshawk> ok so it may be my fault
[05:35] <stratus> infinity, what do you think is easier to hack to run on sarge, usplash or upower?
[05:35] <infinity> Goshawk: If you have bugs to file, file them.  If you want to get upower included in universe, talk to an MOTU and get your packages reviewed.  If you just want to start software wars, please don't do it here.
[05:36] <Goshawk> infinity, sorry ,starting a war was (and is not) my target
[05:36] <Goshawk> this is why now i'll leave from this channel
[05:36] <Goshawk> regards to everyone
[05:36] <Goshawk> bye
[06:01] <mdz> Lathiat: ping
[06:18] <hunger> Isn't pcmcia-cs obsolete with dapper?
[06:19] <hunger> Starting its init-script gives a message to use pcmcia-utils instead.
[06:21] <hunger> bluez-pcmcia-support depends on pcmcia-cs (which in turn *-deskop depends on).
[06:21] <Kamion> hunger: it will be obsolete, but not everything has been moved out of it yet
[06:23] <Kamion> hunger: erk, the scripts in bluez-pcmcia-support really do require pcmcia-cs (/etc/pcmcia/shared); they'll need non-trivial porting
[06:24] <Kamion> that said, I think bluez-pcmcia-support should eventually go away entirely
[06:24] <hunger> Kamion: That is what I had thought. Just stumbled over this when upgrading.
[06:26] <\sh> short question: where can I host some "official bzr archives" for ubuntu packages? is there any way for me to rent space on people.ubuntu.com?
[06:26] <hunger> Kamion: Isen't one of the goals for dapper to trim down main? Somehow the Packages file does not seem to shrink:-)
[06:27] <Simira> it was so old that the lady on the library gave it to me for free
[06:28] <\sh> Simira: my own "adventure game" is named "turbo assembler" running on on c64 or vice  :) quite good to do some nice VIC and SID hacking again in my old days in 6510 :)
[06:29] <\sh> so please welcome xterm-208...hope it's in the archive soon
[06:30] <hunger> Ah... the good ol' days;-)
[06:40] <lamont__> smurf: you around?
[06:40] <Kamion> hunger: that's one of the goals, but there are others
[06:41] <Kamion> \sh: people.ubuntu.com is behind the firewall and is accessible to employees only
[06:41] <Kamion> \sh: I believe there's work progressing on hosting bzr archives on the supermirror
[06:41] <smurf> lamont: ?
[06:41] <lamont__> mad at dappers kbd-chooser
[06:42] <Kamion> \sh: I hear xterm-208's in Debian unstable now; are we nearly at the point of just being able to sync it?
[06:42] <Kamion> well, it's in incoming, anyway
[06:42] <smurf> lamont: anything I can/should help with, or are you just venting? ;-)
[06:42] <lamont__> smurf: installing on a headless system, it gives me the option to say no keyboard present (what it detects), although the default answer is 'type some keys' - which makes you reboot...
[06:43] <\sh> Kamion: that's why I packaged this now again for ubuntu alone...well, i'll try to catch up with the debian maintainer
[06:43] <lamont__> if I select 'no keyboard present', then it exits non-zero, which causes postinst to exit (set -e), which causes that step to fail.
[06:43] <lamont__> smurf: if you're in a position to make it not fail postinst, that'd be cool.
[06:43] <lamont__> for extra credit, if we don't find a keyboard, then 'no keyboard' should be the default answer, not 'type some keys'
[06:44] <Mithrandir> lamont__: there's no way to detect a keyboard on most arches..
[06:44] <smurf> lamont: well, that should be doable
[06:44] <lamont__> Mithrandir: well, there is that...
[06:45] <lamont__> Mithrandir: what are there besides USB keyboards? :-)
[06:45] <Mithrandir> lamont__: however, not defaulting to type some keys probably makes sense on serial installs
[06:45] <smurf> lamont: There's always the "oops, I'd better plug in the keyboard now" use case
[06:45] <lamont__> Mithrandir: that'd work.
[06:45] <lamont__> rivbht
[06:45] <lamont__> right, even
[06:46] <lamont__> but when the user says 'no keyboard here, kthxbye', we shouldn't die.,
[06:46] <Mithrandir> sure
[06:46] <lamont__> because that pushes me back into expert mode, which makes for lots and lots of questions...
[06:49] <jsgotangco> good night
[06:50] <\sh> Kamion: well...our xterm is a native package...could we sync it somehow? and after all debian is missing some patches...i'll file some bugs when I uploaded my bzr archive to tiber
[06:54] <toresbe> janimo: A well-written makefile can be cross-platform. Auto* just ...automates that. In a horrid way, of course.
[06:58] <Kamion> \sh: we can merge that by uploading a package built with -sa based on the Debian package, or else sync it once all our patches are in Debian
[06:58] <\sh> Kamion: k....I'll check again the xterm-208 package from debian incoming 
[06:59] <\sh> or at least I will sync it to debian with 209
[07:01] <Kamion> xterm_208-1.tar.gz != xterm_208.orig.tar.gz so there's no fundamental problem with syncing
[07:01] <Kamion> or merging
[07:01] <Kamion> it's only when filenames actually clash and have different contents that there's a problem
[07:05] <\sh> Kamion: so let's do it for 209...
[07:08] <Kamion> \sh: ok, but why 209 in particular?
[07:08] <Kamion> as in, why do you particularly need a new upstream?
[07:09] <\sh> Kamion: because I want to see if upstream fixes some troublesome bugs...e.g. http://bugzilla.ubuntu.com/show_bug.cgi?id=20037
[07:10] <\sh> Kamion: I actually don't know if it's a "daniels" bug or Thomas' bug
[07:10] <Kamion> ok, fair enough, just making sure it wasn't due to imagined sync problems :)
[07:10] <\sh> Kamion: he isn't quite sure if it's really an xterm or an xorg bug
[07:11] <\sh> Kamion: and right now, debian is not ready for modular xorg...so we are alone at this stage
[07:12] <jblack> Just so you guys know... I just lost my gnome-terminal during apt-get dist-upgrade
[07:15] <Kamion> \sh: not for long
[07:15] <Kamion> (see planet debian)
[07:18] <\sh> Kamion: yes I read it :) but Thomas and/or daniels should have a look at this problem...
[07:24] <Diziet> What a lot of effort to prove that a bug doesn't exist any more.  Oh well.
[07:24] <mdz> Mithrandir: have you thought about how we might deal with network configuration in the live CD if network-manager falls through?  its future is a bit uncertain at the moment
[07:25] <mdz> jblack: you lost it, or it didn't redraw for a whitle?
[07:25] <mdz> s/whitle/while/
[07:25] <\sh> Diziet: you mean /usr/lib/X11/app-defaults? well the prove to do is to install hoary, then upgrade to breezy and then with luck to dapper :) and see if it's magically gone..and it is :)
[07:26] <jblack> It didn't redraw. After approximately 60 seconds I typed blindly, did a ctrl-alt-backspace, and everything came back fine.
[07:26] <jblack> ran apt-get -f install, things seem fine
[07:26] <jblack> firefox still ran, the menus still ran, the task switcher worked.
[07:26] <\sh> Diziet: and therefore I reported the bug, and nobody else could reproduce it, so I think it was my stupidity or something else happened...anyways it's gone..
[07:30] <Diziet> No, not app-defaults.  x-www-browser.
[07:30] <\sh> Diziet: oh :) 
[07:30] <Diziet> And compreg.dat too.
[07:30] <Diziet> I can't reproduce that one but I don't understand where it's coming from so I'm not closing it just yet.
[07:31] <Diziet> Frustrating to spend all afternoon setting up a test rig and then draw a blank.  Oh well, that's software development for you.
[07:31] <\sh> well...I should get up and find something to eat. in the last couple of days I'm alive in the night..looks like that I transform into a vampire or my night life gives me a hint to search a job in the states or canada
[07:32] <Diziet> (a) wards of vampirism (b) is food.
[07:32] <Diziet> s/of/&f
[07:33] <\sh> Diziet: when the garlic is on a pizza together with a lot of spinach I'll eat it :)
[07:34] <\sh> oh well and it looks like gajim has some troubles with our new dbus...or upstream is not up2date somehow
[07:35] <\sh> anyways...I need to get up and grab some food...laters
[07:37] <Diziet> Damn, this computer is too smart for me.  I tried to crash it with the power switch but it's all ATX.
[07:37] <Diziet> And it managed to shut down before I'd held it long enough.
[07:39] <jbailey> Diziet: You don't have a hard on/off switch on the power supply in the back?
[07:41] <Diziet> Not on this one.
[07:41] <Diziet> This time I'm pulling it out of the 4-way.
[07:41] <psusi> press and hold the power button for 6 seconds
[07:41] <Diziet> Yes, but 6 seconds is too long.  It's managed to shut enough stuff down cleanly enough by then.
[07:41] <Diziet> (More like 4 on this motherboard I think.)
[07:41] <psusi> ohhh.... you're trying to simulate a power failure?
[07:42] <Diziet> More or less :-).
[07:42] <Diziet> firefox used to have a stale lockfile bug.
[07:42] <psusi> if your kernel has magic sysreq enabled, hit alt+printscreen+b to instantly reboot
[07:42] <Diziet> Which I think has gone but I want to check.
[07:42] <Diziet> Mains lead is easier :-).
[07:42] <psusi> then try to just kill -9 firefox silly ;)
[07:43] <Diziet> It has more than one process sometimes.
[07:44] <Kamion> kill -9 -1
[07:45] <Kamion> but of course you'll probably need to reboot then anyway, so may as well pull the power in the first place
[07:45] <Diziet> Quite so.
[07:46] <Diziet> Besides, it's a scratch install so I don't care if I break it.
[07:46] <slomo_> infinity, lamont: please give-back gst-plugins-base0.10 on x86... it really works now ;)
[07:48] <Kamion> Is it safe to remove a widget from a GtkContainer while iterating over the items in that container with foreach? (If not, how do I remove all the widgets from a container?)
[07:48] <Kamion> hmm, I could iterate over get_children I suppose
[07:50] <slomo_> you could add all widgets to a list with foreach and delete them afterwards ;)
[07:50] <Kamion> well, that's pretty much what get_children does anyway, so I'll do that
[08:00] <janimo> Diziet I get a weird error after todays ff update: It cannot connect to ubuntu wiki, other sites work fine. It says I should make sure Personal Security Manager is installed
[08:00] <janimo> and This might be due to a non-standard configuration on the server.
[08:00] <janimo> I guess something to do with ssl? links connects fine to same site
[08:06] <dholbach> mdz: ping
[08:09] <Burgundavia> janimo, it might be the wiki. The site changed last night. If you are trying to go to ubuntulinux.org/wiki, it is going to fail
[08:09] <janimo> from links it works
[08:10] <mdz> dholbach: pong
[08:27] <tuhl> seb128: When will we see GNOME 2.13.4 pakcages?
[08:29] <dholbach> tuhl: all tarballs have been packaged and uploaded to dapper already
[08:30] <dholbach> tuhl: gnome-session was just announced, so you can expect that soon too
[08:52] <dholbach> I'll call it the day - have a nice evening.
[08:56] <janimo> night dholbach
[08:57] <sivang> hi all
[09:04] <janimo> Diziet, ping
[09:11] <Riddell> Kamion: any schedule for the next flight CD release?
[09:12] <mdz> not as yet
[09:12] <seb128> tuhl: 4 days ago?
[09:13] <tuhl> seb128: the lastest are 2.13.4 - aren't they?
[09:14] <seb128> tuhl: Ubuntu has current upstream tarballs yep, why?
[09:16] <tuhl> seb128: ok my fault..
[09:17] <seb128> tuhl: I don't get your question to be honest, what is wrong?
[09:18] <tuhl> I was looking for the latest packages - now I see them in synaptic
[09:18] <seb128> k
[09:26] <\sh> re
[09:56] <lamont__> slomo_: done
[10:08] <thierry_> raphink : I've got a problem with my package, the makefile doesn't install the .so file (for shared librairy), I'm using CDBS, how could I fix this?
[10:34] <jbailey> thierry_: Usually the best way is to fix the Makefile and send the patch upstream.
[10:34] <jbailey> thierry_: If it's reasonable that the .so file be installed by default, it's best to make the package actually do that.
[11:17] <segfault> seen mvo?
[11:26] <AstralJava> Hi all, I apologize for a question that is a bit of support-nature, but is there anyone who has battled with irda? If that's the case, would that someone be willing to help just a bit with a problem loading irda modules? Once again, I'm sorry to bother you in this room.
[11:54] <Tm_T> hehe, gnome/gtk filedialog segfaults :p
[11:56] <Tm_T> that means, no artwork... oh well, not yet february ;)
[11:58] <rikai> brb, installing memory <.<;