[01:19] <lifeless> msw: thank you
[01:20] <Kamion> ThunderStruck: libbonobo wouldn't be able to stop you booting. It might stop the desktop coming up properly.
[01:21] <ThunderStruck> Kamion: correct well thats what bothered me than he said due to no net connection he couldnt boot i threw up my hands on him
[01:21] <ThunderStruck> libbonobo caused panels to not show up
[01:22] <Kamion> that's certainly possible in edgy
[01:22] <ThunderStruck> it did it to me today but only once
[01:22] <Kamion> (in the sense that anything's possible in edgy. I don't know anything about this specific issue.)
[01:23] <ThunderStruck> i have a feeling its related to a few icons breaking but havent looked into it yet
[01:27] <mdz> totem still doesn't build, even with fixed xine-lib
[01:27] <mdz> http://librarian.launchpad.net/3419820/buildlog_ubuntu-edgy-i386.totem_1.5.4-0ubuntu1_FAILEDTOBUILD.txt.gz
[01:28] <mdz> the error doesn't make much sense though
[01:28] <mdz> /usr/include/i486-linux-gnu/asm/errno.h:4:31: error: asm-generic/errno.h: No such file or directory
[01:28] <mdz> those are both in linux-kernel-headers
[01:35] <mdz> what's worse, it builds fine for me locally
[01:36] <mdz> oh, wait, linux-kernel-headers may have changed since I upgraded
[01:40] <ThunderStruck> they were updated today
[01:43] <Seveas> mdz, there are other things missing from l-k-h too according to malone
[01:50] <mdz> Seveas: I filed bug #53028
[01:50] <Ubugtu> Malone bug 53028 in linux-source-2.6.17 "linux-kernel-headers regressions" [High,Unconfirmed]  http://launchpad.net/bugs/53028
[01:51] <mdz> marking bug #51369 as a duplicate even though it's older because mine is more complete ;-)
[01:51] <Ubugtu> Malone bug 51369 in linux-source-2.6.17 "Changes root device path without migrating fstab" [High,Confirmed]  http://launchpad.net/bugs/51369
[01:52] <Seveas> mdz: bug 52990
[01:52] <Ubugtu> Malone bug 52990 in linux-source-2.6.17 "asm-generic missing from linux-kernel-headers" [High,Unconfirmed]  http://launchpad.net/bugs/52990
[01:52] <mdz> right I meant bug #52990
[01:52] <Ubugtu> Malone bug 52990 in linux-source-2.6.17 "asm-generic missing from linux-kernel-headers" [High,Unconfirmed]  http://launchpad.net/bugs/52990
[02:16] <Kamion> mdz: meh, BenC knew the problem from mine anyway ;)
[02:16] <Kamion> mdz: he tried to upload to fix it already, but unfortunately since the kernel uses the host compiler for a few userspace programs during the build it needs a manual bootstrap
[02:16] <Kamion> (he did try to hack around that requirement but it apparently didn't work)
[02:17] <mdz> gar
[02:17] <Kamion> infinity: you aren't around yet by any chance are you?
[02:17] <mdz> it's infinisaturday
[02:18] <mdz> meanwhile, my laptop freezes up hard while loading gdm for some reason
[02:18] <mdz> the X server on its own starts fine
[02:18] <mdz> now I know how I'll spend the evening before my next flight
[02:19] <Kamion> anyway, until the kernel bootstrap happens, edgy is basically wedged solid
[02:19] <mdz> indeed
[02:20] <mdz> one might even say "fux0red"
[02:25] <mdz> oh, good, 2.6.17-5.9 fixes my laptop freeze
[02:25] <mdz> hmm, or not.  it fixed it in single-user
[03:34] <bluefoxicy> You know what would be nice?
[03:34] <bluefoxicy> http://neosmart.net/gallery/v/os/ROS/Booting.png.html  If we had a boot screen like this
[03:35] <bluefoxicy> The Ubuntu bootsplash theme is very light, simple, easy on the eyes.. I wonder if there's any merit to being a little flashy about it some time down the road.
[03:35] <Burgundavia> bluefoxicy: the issue is older machines
[03:36] <bluefoxicy> Burgundavia:  well, I'm thinking a static image, not i.e. Xubuntu pops up and there's 6 mice running in hamster wheels and rolling around with eachother on the screen fully 3D accelerated :P
[03:36] <Burgundavia> still run into older machines
[03:36] <bluefoxicy> not enough color display?
[03:36] <bluefoxicy> Burgundavia:  how old are we talking about btw?
[03:36] <Burgundavia> I don't know
[03:36] <bluefoxicy> I've used Ubuntu Dapper on a 350MHz K6-2 with 192 megs of ram
[03:36] <Kamion> new laptops - use anything but vga16fb and you break suspend/resume
[03:37] <Kamion> it's not really an old-machines issue at all
[03:38] <bluefoxicy> it took about 6 tries to get it installed, it takes it 15 minutes to boot the install livecd, the installation kept failing (I had to kill off all of gnome and then get X to start with just a terminal, kill some startup services), took it about half an hour to copy all files, and about 2 minutes to load openoffice.org once I rebooted into the system.
[03:38] <bluefoxicy> Kamion:  nods
[03:38] <bluefoxicy> so only want to display 16 colors
[03:39] <bluefoxicy> Kamion:  the current is only vga16fb though right?
[03:40] <Kamion> yes
[03:40] <bluefoxicy> mmm.  I miss Kdrive, did that project die?
[03:41] <bluefoxicy> Kdrive was great for doing little hacks like full X11 boot screens ;)
[03:41] <bluefoxicy> (since it fit in ... oh.... 300k, and pushed most everything it could into video memory before XFree86 started doing that)
[03:42] <bluefoxicy> More stuff that'll never happen.
[03:45] <johanbr> bluefoxicy: I think the GPE graphical environment for handheld devices still uses Kdrive.
[03:45] <jdub> kdrive definitely didn't die
[03:47] <Viper550> Hello everyone
[03:48] <Viper550> I've got a great new spec for your examination today!
[03:49] <Viper550> anyone>
[03:49] <Viper550> ???
[03:50] <Lathiat> Viper550: just fire away 
[03:50] <Viper550> https://launchpad.net/distros/ubuntu/+spec/desktop-slab
[03:58] <Viper550> So, your thoughts?
[04:02] <bluefoxicy> johanbr:  I was thinking of an Ubuntu Kdrive package, with a rescue mode that tries to get gtk+ kdrive Xlibs working
[04:03] <bluefoxicy> johanbr:  in VESA only of course.  I figured compressed all the needed libs come under 2 megs, minus glibc and busybox
[04:03] <johanbr> bluefoxicy: Ah, okay. Don't know anything about its current status in ubuntu.
[04:04] <bluefoxicy> I do that a lot, there's a lot of neat ideas bouncing around in my head that'll never go anywhere.  And I think Kdrive doesn't even have a Debian proper package in sid, much less Ubuntu universe package.
[04:05] <bluefoxicy> tseng has recommended numerous times that I get a blog
[04:05] <tseng> if only so I could filter it out
[04:06] <bluefoxicy> tseng:  as noisy as I am, I do try to be quiet when there's actual useful conversation around :)
[04:07] <zul> tseng: you need the charlie brown bassoon
[04:07] <tseng> zul: im not familiar
[04:08] <zul> tseng: when peppermint patty always talk to the teacher in peanuts its a basson
[04:08] <tseng> oh right
[04:08] <tseng> wamp-wa-wamp-waa
[04:10] <bluefoxicy> and they always talk back to her like normal
[04:10] <bluefoxicy> that was the first time I got smacked as a child, you know that?
[04:10] <bluefoxicy> I said "what the hell?" and my daddy smacked me.
[04:10] <bluefoxicy> (no not really)
[04:11] <bluefoxicy> anyway /me goes back to trying to do something useful.
[04:15] <bluefoxicy> .... unless anyone wants to explain to me why hitting "ok" in network-admin results in a 64-bit Athlon 3000+ with 512 megs of ram, freshly booted, sitting around for over a minute and not actually setting my gateway until the end of that time, just for a default gateway device change.
[04:15] <zul> no not really
[07:08] <whiprush> jdub: hey did you get my response to fridge-devel wrt. silbs' email?
[07:48] <Hobbsee> how close is the knot 1 cd?
[07:59] <orpheus> hookay, so I've got a question:
[07:59] <orpheus> say i have a package
[08:00] <orpheus> and i want to play with the source of that package
[08:00] <orpheus> 'cause there's a thing or two I'd like to chance
[08:00] <orpheus> *change
[08:00] <anibal> busybox 1:1.1.3-2ubuntu1 and swapspace 1.6-2 FTBFS similarly on ia64 and sparc, I've compared the failed build logs with the i386 one to no avail, could someone have a look at this problem? Alternatively, how can I get access to both sparc and ia64 devel machines?
[08:01] <orpheus> and i'd like to play with it the source 'the ubuntu way' ('the debian way' )
[08:01] <orpheus> what magic do i need to know?
[08:01] <orpheus> i'm presented with a source package with 30-some patches
[08:02] <orpheus> and as i understand it, the patches are applied .. in order... and thus... depend on being applied only in that order
[08:03] <orpheus> so if i play with any of the source before dpkg-buildpackage'ing it, no matter how minor the change, one of those patches is bound to fail
[08:04] <orpheus> and then i get a source tree with some patches applied and some not, and it gets rather broken
[08:04] <orpheus> soo... what's the right way to play with the source of a package?
[08:07] <Hobbsee> anibal: create a chroot with ia64 or sparc architecture?
[08:09] <infinity> Hobbsee: You should probably re-read what you typed and think about that for a second. :)
[08:10] <infinity> anibal: Try not to ask the same question in multiple channels, so I don't have to answer you twice. ;)
[08:10] <Hobbsee> infinity: oh bleh.  yeah, probably.
[08:10] <Hobbsee> dont pick on me :P
[08:10] <anibal> infinity, sorry, ta anyway :)
[08:12] <anibal> Hobbsee, for the record: from infinity to anibal: It's a known bug in linux-kernel-headers and gcc, it's being sorted, don't worry about it.
[08:12] <Hobbsee> anibal: okay then
[08:15] <Hobbsee> wonder why my --update-config parameter doesnt work
[08:16] <Hobbsee> er, override-config
[09:11] <fabbione> morning guys
[09:12] <jdub> mdz: ping
[09:14] <Hobbsee> hi fabbione, jdub 
[09:15] <Hobbsee> jdub: isnt it too early for that?
[09:15] <fabbione> hey Hobbsee 
[09:16] <jdub> probably
[09:16] <Burgundavia> very much so, unless mdz is still up (midnight here)
[09:18] <Hobbsee> heh
[09:18] <Hobbsee> hi Burgundavia 
[09:18] <Burgundavia> hey Hobbsee
[09:19] <Hobbsee> jdub: seems that you lost that interview from your hard drive - yay!
[09:19] <jdub> Hobbsee: ha ha, no
[09:19] <Hobbsee> jdub: damn!
[09:19] <Hobbsee> jdub: whyever not?
[09:19] <jdub> for some reason it was saved as penis.spx
[09:20] <Hobbsee> only because you saved it like that.
[09:26] <StevenK> jdub: Will this interview be made public?
[09:30] <jdub> StevenK: probably
[09:43] <Hobbsee> unless you happen to accidently delete it
[09:43] <jdub> seriously
[09:43] <jdub> who is going to accidentally delete a file called penis.spx?
[10:39] <Tmob> any acpi-support devs around?
[10:39] <Hobbsee> Tmob: it's a saturday. most unlikely.
[10:39] <Tmob> Hobbsee, geeks have holidays?
[10:40] <Hobbsee> Tmob: they have weekends sometimes
[10:40] <Tmob> heh.. just made a patch for sleep.sh for acpi event jitter.. was curious if anyone can comment
[10:40] <Tmob> Hobbsee, any idea who is the maintainer?
[10:40] <jdub> Tmob: you're looking for mjg59, pretty much
[10:40] <Hobbsee> there you go :P
[10:41] <Tmob> okeydok
[10:41] <Tmob> anyway.. posted a bug report and on -devel list.. will wait
[10:41] <ogra> ugh
[10:42] <ogra> plese dont abuse -devel for bugs
[10:42] <Tmob> ogra, hm? bug-fixes?
[10:42] <ogra> we have a bugtracker
[10:42] <Tmob> awww :/
[10:42] <Tmob> well i tought patches are posted on the devel list
[10:42] <Hobbsee> hi ogra 
[10:43] <Tmob> whats the devle list for then
[10:43] <ogra> https://launchpad.net/distros/ubuntu/+filebug
[10:43] <ogra> development related discussion
[10:43] <ogra> hey Hobbsee :)
[10:44] <Hobbsee> ogra: i've been killing things again :)
[10:45] <ogra> Hobbsee, i just saw your kid was accepted ... :)
[10:45] <Hobbsee> ogra: yeah, finally.
[10:50] <ogra> Mithrandir, around ? my ltsp fixes would be ready for upload ...
[11:15] <hunger_>  Yeah! kernel 2.6.17-5-686 boots again! Any chance of getting the restricted modules and stuff for that soonish?
[11:16] <ogra> hunger, its weekend ... 
[11:17] <ogra> give us a chance to recover :)
[11:17] <Hobbsee> ogra: doesnt give you guys the excuse to take a holiday
[11:17] <Hobbsee> ogra: how'd you get back out of /dev/null?
[11:17] <ogra> more more!
[11:17] <jsgotangco> doh!
[11:17] <Hobbsee> um, scary.
[11:17] <ogra> :)
[11:18] <jsgotangco> would you rather want RichEd to do that to you?
[11:18] <ogra> Hobbsee, i crawled indeed ... holding tight on a stream coming from /dev/zero
[11:18] <Hobbsee> ogra: hehe
[11:18] <hunger> ogra: Oh, I thought all those things get rebuild automatically nowadays...
[11:19] <hunger> ogra: Sorry, I was not implying that you boys (and girl) are lazy:-)
[11:19] <ogra> jsgotangco, well, lets see :)
[11:19] <ogra> hunger, i know :)
[11:19] <Hobbsee> hunger: heh.  the one girl, all alone.
[11:20] <Hobbsee> hi lifeless_
[11:20] <hunger> Hobbsee: Yeap, I was refering to you;-)
[11:20] <Hobbsee> hunger: i figured that :P
[11:20] <Hobbsee> hunger: although, does ogra count as vaguely girly with his ponytail?
[11:21] <infinity> A lot of us have pony tails, not sure that counts for much.
[11:21] <hunger> Hobbsee: See, this time I remembered you were on of those mysterious other kinds of human beings rumored to exist somewhere.
[11:21] <ogra> Hobbsee, i'm way to beardy to be counted as a girl today :)
[11:21] <Hobbsee> hunger: heh
[11:21] <Hobbsee> ogra: haha
[11:21] <Hobbsee> infinity: i know, i was teasing :P
[11:21] <Hobbsee> oh shoot - glad i didnt hit y!
[11:22] <Hobbsee> Sure you want to delete all the files in /home/sarah [yn] ? n
[11:22] <ogra> y
[11:22] <ogra> *g*
[11:22] <infinity> That prompt really needs to be [ynm] 
[11:22] <infinity> Indeterminate computing rules.
[11:22] <Hobbsee> hehe
[11:25] <sivang> re dudes
[11:27] <ogra>   File "setup.py", line 52, in ?
[11:27] <ogra>     from zope.app.locales import extract
[11:27] <ogra> ImportError: No module named zope.app.locales
[11:27] <ogra> grmpf
[11:27] <Hobbsee> hi sivang 
[11:36] <sivang> hey Hobbsee 
[11:36] <sivang> ogra: schooltool ? :-)
[11:38] <Kamion> infinity: any chance of a mass give-back now that l-k-h is fixed?
[11:38] <infinity> Kamion: Define "fixed".
[11:39] <Kamion> "it is possible to compile C programs again"
[11:39] <infinity> Kamion: sparc/ia64 still seem buggered, and linux-source is now FTBFS.
[11:39] <Kamion> yeah, but mesa and xine-lib would be worth a shot at least
[11:39] <infinity> Kamion: doko's uploading yet another lkh fix.  Not sure what that will un-fuck.
[11:39] <Kamion> powerpc should be happier, and it has some serious problems
[11:39] <Kamion> s/has/had/
[11:40] <infinity> Well, I can certainly do a mass-give-back.
[11:40] <infinity> I'm sure we'll need another this weekend.
[11:40] <Kamion> yeah - just want to see if we can get up to python-gnome-based stuff being installable on powerpc
[11:40] <Kamion> which should (I think) be possible now and would help matters a lot
[11:41] <doko> Kamion, infinity: please wait a bit, it looks like linux-source -5.11 "fixes" the include dir, but our compilers don't know about it
[11:41] <doko> and working on the ia64 fix now
[11:41] <infinity> Kamion: Nevermind, can't do a mass-give-back.
[11:41] <Kamion> doko: what's wrong with the current l-k-h on powerpc?
[11:41] <infinity> Kamion: Requires direct DB access.
[11:41] <infinity> Kamion: But we can cherry-pick a few things you think might be in better shape.
[11:41] <doko> Kamion: doesn't have a /usr/include/powerpc64-linux-gnu
[11:42] <Kamion> wow, https://launchpad.net/distros/ubuntu/+source/xine-lib is confused
[11:42] <Kamion> doko: what does that actually break?
[11:43] <infinity> Kamion: Oh, cool.  Looks like the ACCEPTED clash led to no build records for the upload that won..
[11:43] <infinity> \o/
[11:43] <doko> Kamion: AFAICS linux-source -5.11 changes that from ppc64 to powerpc64, breaking all our compilers
[11:43] <infinity> Or, at least, ones I can't get to from the web UI...
[11:44] <infinity> https://launchpad.net/distros/ubuntu/edgy/+builds?build_state=failed&build_text=xine-lib
[11:44] <infinity> That'll do.
[11:44] <Kamion> doko: -5.11 hasn't built anywhere
[11:44] <Kamion> so that doesn't matter
[11:45] <Kamion> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/2.6.17-5.11
[11:46] <Kamion> infinity: mesa/amd64 and mesa/powerpc would be nice, certainly
[11:46] <infinity> Yeah, working on those.
[11:46] <Kamion> noting doko's concerns but it really can't hurt to try
[11:46] <infinity> Just watches xine-lib fail because of those being out of sync.
[11:46] <infinity> s/watches/watched/
[11:46] <Kamion> if mesa builds, xine-lib then totem then gnome-python-extras, iirc
[11:47] <doko> In file included from scripts/mod/../../include/linux/input.h:19,
[11:47] <doko>                  from scripts/mod/file2alias.c:40:
[11:47] <doko> include/asm/types.h:31: error: redefinition of typedef '__u8'
[11:47] <doko> scripts/mod/file2alias.c:34: error: previous declaration of '__u8' was here
[11:47] <doko> include/asm/types.h:34: error: redefinition of typedef '__u16'
[11:47] <doko> scripts/mod/file2alias.c:33: error: previous declaration of '__u16' was here
[11:47] <doko> include/asm/types.h:37: error: redefinition of typedef '__u32'
[11:47] <doko> scripts/mod/file2alias.c:32: error: previous declaration of '__u32' was here
[11:47] <doko> make[4] : *** [scripts/mod/file2alias.o]  Error 1
[11:47] <doko> make[3] : *** [scripts/mod]  Error 2
[11:47] <doko> make[2] : *** [scripts]  Error 2
[11:47] <doko> hmm, powerpc, with Ben's fixed lkh ...
[11:47] <Kamion> yeah, but that's in the kernel and IIRC is due to the extra -I he put in as a workaround
[11:48] <infinity> Kamion: How quickly is mesa expected to fail if it does?
[11:49] <Kamion> infinity: either as soon as it tries to compile something written in C, or about 20 minutes in
[11:49] <infinity> Okay, well the former hasn't happened.  Let's sit back and wait for the latter.
[11:50] <Kamion> before my recent fix, it took 27 minutes to fail
[11:50] <Kamion> https://launchpad.net/+builds/+build/228411
[11:50] <infinity> I'm offended that we have packages that take 27 minutes to build at all.
[11:50] <Kamion> it's a hell of a lot slower on my laptop :(
[11:50] <Kamion> took hours to build far enough for me to test the fix
[11:50] <sivang> Kamion: is this a new mailing list?
[11:51] <Kamion> sivang: yes
[11:51] <infinity> I'm registering a spec for edgy+1 to remove all sources that can't be built in the space of a publisher run.
[11:51] <Kamion> ask Keybuk for the details
[11:51] <infinity> Hopefully that doesn't turn into an LP spec to make the publisher slower.
[11:51] <sivang> Kamion: cool, thanks
[11:52] <infinity> Kamion: Which laptop is this that's that slow?  Mine's gnerally faster than the buildds (except on really disk-intensive stuff)
[11:53] <infinity> Of course, I specced it to be "faster than a buildd" intentionally, noting what I do for a living.
[11:53] <infinity> Hunting build failures on slow hardware is teh suck.
[11:53] <Kamion> my G4. I think it mostly needs more RAM.
[11:53] <Kamion> its processor may not be brand new but it isn't THAT bad
[11:55] <Kamion> and the disk is newish so it's probably not that, though I do give it quite a beating
[11:55] <infinity> Although, there is something to be said for the skills acquired through using REALLY slow hardware.
[11:55] <doko> hmm, no access to chinstrap again?
[11:55] <infinity> m68k failure tracing has led me to be able to wrest all sorts of info from build logs that surprises even me.
[11:56] <infinity> doko: /topic in #canonical
[11:56] <Kamion> you mean "no, don't run a full build from scratch when you change one file"?
[11:56] <doko> infinity: ok, seen
[11:56] <infinity> Kamion: I mean "don't rebuild at all, just read logs and divine the problem, as if by magic or sheer luck".
[11:57] <infinity> Kamion: Well, then the "don't rebuild the whole bloody thing, argh" bit follows. :)
[11:57] <Kamion> ah yeahh
[11:57] <infinity> Kamion: But the Adam of 3 years ago would look at the Adam of today as if he was some kind of mind-reading wizard.  Necessity may or may not be the mother of invention, but she certainly gives birth to rapid learning of bizarre skillsets.
[11:58] <Kamion> you do have a tendency to glance at build logs and go "oh yeah, it's that bug"
[11:58] <ogra> Kamion, i see the same slowness on my ibook ... pbuilder-satisfydepends takes 45min for gnome-power-manager here
[11:58] <Kamion> it's quite distressing until one works out that that's because it's the 175th instance of that problem you've seen
[11:59] <Kamion> ogra: mine is not that slow
[11:59] <ogra> well, yours is a bit more powerfull :)
[11:59] <Kamion> I would strace it if I were you; 45 minutes is obscene
[11:59] <ogra> it only happens on ppc
[11:59] <Kamion> then again strace is my hammer I apply to all problems, regardless of the cause
[11:59] <ogra> same build on i386 is done in 4 min
[12:00] <ogra> well, i tooke the easier way and bought a new laptop :P
[12:00] <ogra> -e
[12:02] <doko> hmm, maybe I should use the time until BenC gets awake for the gcc include dir fixes, once and forever ...
[12:02] <Hobbsee> doko: or just call him and make him fix the world now, immediately :P
[12:03] <infinity> Okay, mesa failes in ia64 due to the known lkh/gcc disagreement.  That's no surprise.  Still going on amd64/i386/sparc (I assume sparc will fail too?)
[12:03] <doko> infinity: new lkh uploaded, which should fix that
[12:03] <infinity> s/failes/failed/
[12:03] <infinity> doko: Oh, keen.  I'll retry it later, then.
[12:03] <doko> I don't know much about the sparc failures
[12:03] <infinity> Where "later" is "when I pass by my laptop again"...
[12:03] <Kamion> er - mesa/i386 didn't need rebuilding
[12:04] <infinity> Err, amd64/powerpc/sparc
[12:04] <infinity> Brain wrong, soyuz right.  Honest.
[12:04] <infinity> (This time)
[12:04] <Kamion> not sure about sparc - it hit the same mesa-specific problem as powerpc earlier
[12:05] <infinity> Ahh, cool.  Then maybe it'll complete too.
[12:05] <Kamion> depends exactly how broken l-k-h is there at the moment
[12:05] <infinity> It had "some breakage", but I'm slipping in my old age and illness.
[12:05] <infinity> And maybe it's happy with the current version.
[12:06] <infinity> amd64 successful.
[12:09] <doko> hmm, looking at sparc now ...
[12:13] <siretart> Kamion: re: launchpad beeing confused by xine-lib, shall I do another upload?
[12:13] <infinity> siretart: No, it's just the UI that's confused.
[12:13] <infinity> siretart: The archive and the queues seem fine.
[12:13] <siretart> allright
[12:14] <infinity> powerpc successful
[12:16] <siretart> infinity: i'm a bit confused that it still hasn't been built
[12:16] <infinity> siretart: Working on that now.
[12:21] <Kamion> siretart: build-wise, the whole world has been very confused since then
[12:22] <siretart> oh darn..
[12:22] <Kamion> but should be more sorted now
[12:27] <Kamion> infinity: sparc's got past the previous failure
[12:27] <infinity> Siffy.
[12:27] <infinity> spiffy, too.
[12:28] <infinity> Looks successful even.
[12:30] <infinity> Now to go do girly things like dye my hair and shower while I wait for publisher goodness.
[12:30] <doko> infinity: so sparc looks fine, or does it still need some fixes?
[12:31] <infinity> doko: Looked happy building mesa.  If it needs fixes, I'll let people argue about it on Monday.
[12:31] <Kamion> let's just hope that mesa doesn't hit NEW on those arches
[12:31] <infinity> Oh, ugh.
[12:31] <Kamion> hasn't seemed to on powerpc, anyway
[12:31] <infinity> We still can't actually manipulate the queue via the web UI, can we?  Only view it?
[12:31] <Kamion> right
[12:31] <infinity> Dang. :)
[12:32] <infinity> Here's hoping, then.
[12:46] <jono> hey
[12:46] <sivang> hey jono , what's cracking?
[12:47] <jono> sivang, nothing much, just catching up on mail before I run out
[12:48] <sivang> jono: planning to do some stuff out and about? :-)
[12:48] <jono> sivang, walk dogs, watch superman, have bbq - thats the sum of today :P
[12:48] <jono> sivang, you up to much ?
[12:49] <ogra> dogs ? 
[12:49] <ogra> you have multiple ?
[12:49] <sivang> ogra: he has few of that :)
[12:49] <ogra> cool 
[12:49] <sivang> jono: Watching some DVDs, maybe some walks outside we'll see :-)
[12:50] <jono> ogra, two mini-daschunds :)
[12:50] <sivang> ogra: I have a boxer mixed with a cocer spinal at my parent's house :)
[12:50] <sivang> he's a mad-dog! was crazy like hell when he was a pupp
[12:51] <ogra> jono, heh
[12:51] <ogra> jono, but youre not a secret german, are you ? ;)
[12:51] <jono> ogra, not that I am aware of :P
[12:51] <ogra> heh
[12:52] <ogra> in germany the dachshund owners are the guys who mow their lawn with a nail scissor :)
[12:53] <ogra> i only met sane non german dachhund owners in my life :)
[01:14] <infinity> doko: Oh, the sparc issue is missing sparc64/asm stuff.  See the build failure for gcj-4.1:
[01:14] <infinity> http://librarian.launchpad.net/3421827/buildlog_ubuntu-edgy-sparc.gcj-4.1_4.1.1-8ubuntu2_FAILEDTOBUILD.txt.gz
[01:15] <doko> infinity: yes, that was the old lkh, should be fixed now.
[01:15] <infinity> doko: Fixed as of -5.10.1?
[01:15] <doko> -5.10 
[01:16] <infinity> That build used -5.10
[01:16] <doko> hmm 
[01:21] <doko> starting a test build. it *should* work
[02:09] <Hobbsee> Launchpad will be going offline for maintenance in nine minutes.
[03:16] <elmo> *.ubuntu.com, launchpad.net etc. are going offline for a couple of minutes for some necessary maintenance
[03:18] <elmo> (back)
[03:23] <mjg59> Would people please stop assigning bugs to "acpi"?
[03:23] <mjg59> apt-cache show acpi should give you a clue as to why this is a bad idea
[03:23] <Lathiat> heh
[03:25] <ogra> hmm, with ohci_hcd loaded my lappie only does usb 1.1 ... with ehci_hcd loaded it does 2.0 ... with both loaded it does 1.1 only and ignores the ehci driver completely ... weird  
[03:30] <sladen> ogra: which order did you load them?
[03:30] <ogra> sladen, the kernel (or udev ?) did
[03:31] <ogra> i didnt load them at all ... but if i remove both and load ehci it works fine ...
[03:32] <ogra> seems i'm not alone 
[03:32] <ogra> http://www.linuxquestions.org/questions/showthread.php?t=446472
[03:32] <ogra> same laptop, same prob
[03:34] <ogra> intrestingly *everything else* on this laptop works, even the hotkeys etc .. out of the box in edgy... the above actually seems to be the only problem
[03:40] <sladen> ogra: have you had a peek in the kernel to see if any of the other HP's already have workarounds 
[03:40] <ogra> nope
[03:41] <ogra> not yet ... 
[03:54] <ogra> doko, any thoughts about http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227#c8 ? kino suffers from it ... will it be reverted in gcc or do we have to wait for a kino rewrite ? 
[03:54] <Ubugtu> gcc.gnu.org bug 27227 in c++ "[4.0 Regression]  rejects valid code with some extern "C"" [Normal,New]  
[04:26] <ogra> Keybuk, 
[04:26] <ogra> good afternoon :)
[04:27] <Keybuk> hidihi
[04:27] <ogra> did you ever boot with splash and quiet options turned off since the switch to dash ? 
[04:27] <ogra> i have a ton of "open: failed" messages here
[04:28] <Keybuk> "failed" ?
[04:28] <ogra> havet dug deeper yet
[04:28] <ogra> something like that
[04:28] <Keybuk> I fixed the last round of "No such file or directory" errors, I thought
[04:28] <ogra> i havent got the original message here
[04:28] <ogra> but it seems to affect every bootscrpt
[04:29] <Keybuk> yeah. it'd be usplash_write bitching
[04:29] <ogra> so i suspect something like the lsb functions that is in every script
[04:29] <ogra> or usplash :)
[07:03] <Kamion> ahh, totem/i386 built finally
[07:03] <Kamion> so after this publisher run, gnome-python-extras/powerpc can be given back
[07:04] <ogra> sigh, and i still dont know what to do about kino
[07:05] <Kamion> is it that hard to fix?
[07:05] <ogra> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[07:05] <Ubugtu> gcc.gnu.org bug 27227 in c++ "[4.0 Regression]  rejects valid code with some extern "C"" [Normal,New]  
[07:05] <Kamion> yes I know
[07:05] <ogra> its not a kino bug imho
[07:05] <Kamion> that's not my reading of the bug
[07:06] <Kamion> the point being made there is that gcc point releases shouldn't reject previously working code
[07:06] <ogra> well, the bug is to introduce breaking changes in a minor version bump
[07:06] <Kamion> nobody is suggesting (AIUI) that the rejection is invalid
[07:06] <Kamion> so it is BOTH a gcc and a kino bug
[07:06] <ogra> sure
[07:06] <ogra> but at the moment my reading is that gcc is at fault
[07:06] <infinity> So fixing kino is still worth the effort anyway.
[07:06] <Kamion> fastest course of action from your point of view is to fix kino
[07:06] <Kamion> and that's also the best long-term action
[07:06] <infinity> gcc is not at fault for the code being broken, only for the FTBFS happening a few months sooner than you'd hoped.
[07:07] <Kamion> ogra: no, BOTH gcc and kino are at fault
[07:07] <ogra> yes
[07:07] <ogra> but if we use gcc we shouldnt introduce that "feature" 
[07:07] <ogra> we reverted stuff in other areas before because of this ... i.e. the next-server option in dhcpd
[07:08] <Kamion> I'm not arguing that the gcc change shouldn't be reverted - I don't have enough knowledge there really - but you should definitely fix kino, and there should be no harm in just doing it now
[07:08] <infinity> Err, even if the change gets reverted in gcc-4.1.2, it WILL land in 4.2.0
[07:08] <Kamion> ogra: there's no excuse for not bothering to fix stuff like this near the start of a release cycle, honestly
[07:08] <infinity> So either way, kino needs to get fixed.
[07:08] <Kamion> if it were near the end, I'd agree with you
[07:08] <ogra> Kamion, i dont say kino should stay buggy :)
[07:09] <Kamion> yes you do, repeatedly
[07:09] <Kamion> you keep saying it's gcc's fault, and that it should be reverted, and that you don't know what to do
[07:09] <infinity> You seem to be implying that gcc should get reverted, and you should sitck your head in the sand about the kino bug until upstream deals with it.
[07:09] <infinity> I'm saying that both should get fixed.
[07:09] <infinity> I'm sure doko will revert the gcc change, but that's no excuse for not fixing kino.
[07:10] <Kamion> it's 13 packages according to tbm, that's easy to blitz
[07:10] <Kamion> then no more problem when gcc 4.2 arrives
[07:10] <ogra> sure
[07:11] <ogra> what i meant is that i'd prefer upstream to dea with it (kino upstream is usually responsive) instead of introducing a patch we dont need *yet*
[07:11] <ogra> sure kino should also be fixed
[07:12] <Kamion> the big blocks of code inside extern "C" in kino are a bit weird, I must say
[07:13] <ogra> yep
[07:13] <Kamion> my C++ is not what it used to be, but that's not the way I'd have done it ...
[07:14] <Kamion> hmm, I wonder what to do about libfam0 showing up in anastacia output
[07:14] <Kamion> it's because gamin's shlibs got changed to say libfam0 for linkage against libfam
[07:14] <ogra> do any KDE parts still use it ?
[07:14] <ogra> ah
[07:14] <Kamion> maybe change the shlibs to say libgamin0 | libfam0?
[07:16] <Kamion> it can sort of be worked around in the seeds but not really - fam would still get pulled into main due to build-depends
[07:16] <Kamion> (just tried that)
[07:16] <mjg59> Oh argh.
[07:16] <mjg59> New hal needs new udev = pain
[07:16] <Kamion> Scott's working on new udev
[07:16] <ogra> oh fun
[07:16] <mjg59> Yeah
[07:16] <Kamion> but post-knot-1 I think
[07:17] <mjg59> I was sort of planning on doing upstream hal hacking, but that looks awkward right now
[07:17] <ogra> Kamion, wasnt there some corner case with nfs mounted home or something wheer you needed fam for nautilus instead of gamin ?
[07:17] <Kamion> dunno ...
[07:17] <mjg59> If you want notifications for file alterations over nfs, you need fam
[07:17] <Kamion> I suppose getting gnome-vfs2 to explicitly use libgamin would work too, maybe, but I don't know enough for that
[07:17] <mjg59> On both server and client
[07:18] <ogra> yep, thats what i remember ... there was a reason for fam in main ...
[07:18] <Kamion> fam isn't in main
[07:19] <Kamion> it hasn't been in main since warty
[07:19] <ogra> oh
[07:19] <mjg59> Oh, maybe I can just get away with volumeid
[07:19] <ogra> the i remember wrong i guess ...
[07:20] <Kamion> no symbol differences between libfam.so.0 and libgamin-1.so.0
[07:21] <Kamion> I'll wait until seb128 is around and ask him, I guess
[07:32] <Kamion> anyone doing l-r-m for -5?
[07:33] <fabbione> Kamion: gamin and fam exports the exact same API/ABI
[07:33] <Kamion> yeah
[07:33] <fabbione> only the underneath code is different
[07:33] <fabbione> i am 100% sure about it
[07:34] <Kamion> well, I've filed a bug, seb128 can look when he's back
[07:35] <Kamion> (l-r-m> I just realised it's blocking d-i)
[07:37] <Kamion> oh well, sucking down the source package ...
[07:37] <fabbione> iirc l-r-m only needs one change in the debian/rules for the ABI
[07:38] <Kamion> nod
[07:38] <fabbione> i didn't touch that stuff in ages tho
[07:38] <fabbione> there are some scary things like control.stub control.in and control
[07:41] <Laser_away> hmm, these Debian .pdiffs seem to make update'ing significantly longer if you have updated for a while
[07:46] <Kamion> ok, l-r-m source uploaded
[07:47] <HiddenWolf> Kamion, so get offline, like sensible people do
[07:47] <HiddenWolf> Kamion, check out the sun, you know
[08:05] <AlinuxOS> mjg59, hello
[08:05] <AlinuxOS> mjg59, ping (can I disturb you in private?)
[08:34] <doko> hmm, BenC did wake up sooner than I thought ...
[08:35] <doko> ogra, infinity, Kamion: 27227 is reverted for the next upload, will wait for the new linux-kernel-headers first
[08:36] <ogra> doko, that means before the CD ?
[08:37] <doko> well, Mithrandir is not online, we're technically frozen ... so maybe Kamion could give an opinion ...
[08:39] <BenC> is there a quick fix for the missing "fixed fonts" x problem?
[08:39] <sladen> BenC: for breezy->dapper it was just the case of a symlink;  the same should probably work
[08:40] <sladen> BenC: I think it's just down to the fonts landing in a different location 
[08:40] <ogra> BenC, run mkfontdir in /usr/share/fonts/X11/misc/
[08:40] <ogra> sladen, nope
[08:40] <ogra> its a missing font.dir file 
[08:40] <sladen> ogra: ooh, even simpler.
[08:41] <BenC> ogra: yay, that worked...thanks
[08:41] <ogra> update-font-dir ignores the new paths
[08:42] <BenC> time to switch to X
[08:42] <doko> hmm, that was short ...
[08:46] <doko> BenC: does the linux-source upload include the /usr/include/{ppc64,powerpc64}-linux-gnu directories?
[08:46] <Kamion> doko: go ahead if that's the only change
[08:46] <BenC> doko: no, for ppc there is only asm/
[08:47] <BenC> since it's all the same directory, that's the way hdrinstall creates it
[08:47] <doko> BenC: so there's nothing installed in /usr/include/{ppc64,powerpc64}-linux-gnu ? ok.
[08:47] <doko> and on ia64 and hppa?
[08:48] <BenC> the only arches that have multiple asm is x86_64, i386 and sparc
[08:48] <doko> BenC: and sparc includes all headers this time?
[08:48] <BenC> yeah
[08:48] <doko> cool
[08:49] <BenC> hdrinstall actually uses the stub asm files like sparc used to, where asm/foo.h will include asm-sparc/foo.h or asm-sparc64/foo.h depending on a compiler define
[08:49] <BenC> same for x86_64/i386
[08:50] <BenC> it builds the files like that and i just copy {asm*,linux} to get everything needed
[08:50] <doko> Kamion: there are other changes, I'll test-build the compiler on sparc, ppc64 and amd64 first.
[08:51] <BenC> 4 arches building, and no failure yet, so I'm hopeful this will be good :)
[08:52] <doko> BenC: not for now, but I would like to see lkh still built as a separate source package, so I don't have a kernel dependency when bootstrapping the toolchain. would that be doable?
[08:54] <BenC> doko: if we split the source, then we should have stuck with the lkh package we had, but I'm not opposed to something build-dep'ing on linux-source-2.6.17 .deb and using that to create it
[08:56] <BenC> it's easy to do something like "make -C /usr/src/linux-source-2.6.17 O=build-tmp/ ...", which is how I'm creating the stuff now (you could rip my make rules for linux-kernel-headers and use them standalone)
[08:57] <doko> BenC: ok. not for now, just in the case we want to rebuild the archive with a clean/new toolchain
[08:58] <doko> I thought that the current lkh packages were built not directly from the linux-source package, but were modified
[09:30] <ThunderStruck> BenC: i opened that kernel panic bug up cause its happening on 2.6.17-5 but following the instructions you gave on it worked again ;) ty
[09:31] <ThunderStruck> bug 52416
[09:31] <Ubugtu> Malone bug 52416 in kernel-package "Kernel panic on startup" [Untriaged,In progress]  http://launchpad.net/bugs/52416
[09:37] <BenC> Thunder: ok, thanks
[10:15] <mdz> ubuntu-desktop ought to be installable on amd64 again after this publisher run
[10:15] <mdz> working on powerpc now
[10:17] <Fjodor> Has anything been changed in update-grub lately? It seems to disregard my defaultopts and set it back to quiet and splash. Has a report been filed about that?
[10:18] <mdz> Fjodor: make sure you've read the comments in the file
[10:18] <mdz> bug 21412
[10:18] <Ubugtu> Malone bug 21412 in grub "Default update-grub behaviour is not intuitive" [Medium,Confirmed]  http://launchpad.net/bugs/21412
[10:22] <Fjodor> Hmmm, this time no foul. Could it be related to the fact that I build edgy kernel packages? As the comments say, I edit #defoptions, which should stay the same, and be applied to all default entries
[10:25] <Fjodor> So, what I gather from the bug reports is, that most (me at first too) edit the entries directly. I don't (anymore)
[10:27] <Fjodor> Anyway, I'll report back, when  my next kernel build is done and installed, since the problem didn't arise on a random update-grub with no new kernels installed. Thanks so far
[10:35] <Fjodor> Hmmm, seems like the problem disappeared again. How about that, huh. But thanks for your help
[10:36] <danny> hello how to find the maintainer of a package if the one referenced is the wrong person e.g. the original debian developer
[10:36] <Riddell> danny: we don't have maintainers, the changelog is a good indication of people with experience
[10:37] <danny> where i find the changelog ?
[10:38] <sladen> danny: debian/changelog in the package  or   http://changelogs.ubuntu.com/
[10:39] <sladen> did the linux-headers issue get fixed, and if so what's the best way to force a rebuild of a package so that it doesn't FTBFS now?
[10:39] <sladen> upload a   ...build1 ?
[10:40] <ogra> ask a ubuntu-archive admin to give it back ?
[10:41] <Riddell> sladen: ping keybuk or infinity, or upload build1 if they're not around and you can't wait until monday
[10:41] <ogra> (if it doesnt get retried automatically anyway, LP has fancy new features there iirc)
[10:42] <danny> well the chanlogs also reference allways the debian maintainer and reflect also the new versions which seem not availible through apt
[10:43] <sladen> danny: what package are you looking at?
[10:46] <danny> grsync
[10:48] <ogra> thats only maintined in debian ... its not been touched by any ubuntu deveoper
[10:48] <ogra> *developer
[10:49] <danny> well but it is in an ubutu repository and only with an old version
[10:50] <ogra> 0.4.3-2 is the latest we have
[10:50] <crimsun> new version will be synced in. We've been blocked on kernel+libc+lkh issues, so I wouldn't hold my breath for the new version to be available in Edgy quite yet.
[10:50] <ogra> https://launchpad.net/distros/ubuntu/+source/grsync shows that it isnt built yet
[10:51] <ogra> oh, no, i'm wrong it is
[10:51] <danny> I see only 0.1.2
[10:51] <ogra> https://launchpad.net/+builds/+build/225389
[10:52] <ogra> dapper has only 0.1.x
[10:52] <danny> is there any problem updating this?
[10:53] <ogra> which the above url tells you 
[10:53] <ogra> well, we usually dont upgrade packages in a release without a very hard reason ... (i.e., the current versin wipes your HD)
[10:53] <ogra> but you can ask the backports team 
[10:54] <crimsun> file a bug on the source package, subscribe ubuntu-backports
[10:54] <ogra> https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[10:54] <ogra> or mail them ;)
[10:55] <danny> well if dapper has support for the next 5 years, i don't understand why not the repository is constantly updated... this is what i would expect
[10:56] <crimsun> LTS != constantly updated.
[10:58] <danny> and what does the term backport mean? I would expect features which hae exist in older ubuntu versions to be backported to the new... what has this to do with normal software matureing processes?
[10:58] <BenC> danny: You can't keep something stable by constantly updating it
[10:59] <ogra> danny, backporting == building a package from a newer version for an older system
[10:59] <BenC> danny: our normal development cycle is for people that want "new features", LTS is for people that want a stable and consistent platform for a long term commitment
[11:00] <danny> hmm... doesn't 0.4.3 sound better than 0.1.3?
[11:00] <BenC> we don't have "sounds good" as a reason in our bug reporting system
[11:01] <danny> when I install grsync 0.1.3 and want to have 0.4.3 - can i yust try to compile myself (and overwirting the 0.1.3 files with make install)?
[11:01] <BenC> you could get the 0.4.3 package and recompile on your system
[11:01] <BenC> that's basically a backport
[11:01] <ogra> i'd rather take the source package from edgy and build that
[11:02] <danny> how to do that?
[11:02] <crimsun> #ubuntu-motu can help with that
[11:02] <BenC> there's lots of docs in ubuntu and debian on how to rebuild packages
[11:02] <danny> what is this motu channel for?
[11:03] <crimsun> packaging software in universe and multiverse components
[11:03] <danny> ok... thanks for now
[11:09] <JanC> danny: there is a manual for (re)building packages on help.ubuntu.com
[11:10] <Kamion> http://librarian.launchpad.net/3426551/buildlog_ubuntu-edgy-i386.linux-restricted-modules-2.6.17_2.6.17.1-6_FAILEDTOBUILD.txt.gz <-- gar
[11:11] <Kamion> similarly amd64
[11:11] <BenC> where did that build come from?
[11:11] <crimsun> Kamion did
[11:11] <BenC> I'll check it out
[11:12] <BenC> oh wow, that's an ugly build
[11:12] <Kamion> I did, but it was just s/4/5/ on the abinum
[11:12] <BenC> ok, I'll do a build here and see what's up
[11:12] <Kamion> /build/buildd/linux-restricted-modules-2.6.17-2.6.17.1/debian/build/2.6.17-5-386/madwifi/ath_hal/../include/compat.h:71:22: error: asm/page.h: No such file or directory
[11:12] <Kamion> is the first failure
[11:13] <Kamion> I also believe that's the largest number of compiler errors I've ever seen on a single file
[11:14] <crimsun> wow.
[11:24] <sladen> ...all from just   #include <linux/module.h>
[11:26] <Kamion> ogra: re kino, it builds fine if you just stick extern "C" { ... } around the KinoCommon *common declaration in src/kino_common.h; I don't know if that's the best fix and it should certainly go upstream for comments, but that fix should be workable for now
[11:27] <Kamion> (oh, you should test that it works too after that - I haven't)
[11:27] <ogra> Kamion, ok, will fix it if i arrive in the old house ... i'll do my weekly drive through the country soon ...
[11:38] <Kamion> mdz: damn, if you'd said, I'm pretty sure I could have resurrected gnome-applets on powerpc
[11:39] <Kamion> unfortunately I didn't notice until after your upload, so never mind now
[11:39] <Kamion> it's sitting in /srv/launchpad.net/builddmaster/accepted/20060713-160720-227962-183933/
[11:49] <doko> Kamion: please requeue gcc-3.4 on powerpc and sparc, xulrunner on amd64
[11:51] <sladen> Kamion: and wxwidgets2.6 on all
[11:53] <mdz> Kamion: that's odd; locate on drescher didn't find it