[00:33] <Riddell> kees: that dosemu diff is really not minimal
[00:33] <kees> Riddell: no?
[00:34] <kees> or is that the one with build cruft?
[00:35] <Riddell> kees: yep
[00:39] <kees> Riddell: I'm open to suggestions on how to avoid the cruft.  seems to show up in my debdiff any time I debuild -S it
[00:40] <LaserJock> kees: filterdiff?
[00:40] <kees> LaserJock: oh, sure, I can manually do it.  :)
[00:41] <kees> but it does represent what's going to happen when it builds
[00:41] <LaserJock> kees: does that matter so much?
[00:41] <LaserJock> what kind of cruft is it?
[00:43] <kees> LaserJock: autoconf joy
[00:43] <kees> Riddell: what would you like me to do?
[00:44] <Riddell> kees: if it's unavoidable I can just look through it
[00:44] <LaserJock> kees: so like config.guess, config.sub?
[00:47] <RAOF> Hm.  Where was that network-manager + WPA-enterprise bug...
[00:48] <slangasek> kees: you're on MIR team now?  Could you take on bug #315403?  looks like cup has been dep-wait on jflex since November
[00:48] <kees> slangasek: I am, but I'm totally underwater at the moment with security work
[00:48] <slangasek> ok
[00:49] <slangasek> lool: how about you?  Any cycles for MIR work? ^^
[00:49]  * slangasek wonders if jflex should replace jlex as a dep of libxsltc-java
[00:57] <RAOF> Woah.  That's got to be the longest bug with a reasonable signal/noise ration on launchpad.
[01:07] <kees> Riddell: thanks
[01:16] <calc> aren't programs that need to save supposed to stop shutdown from happening until you deal with them?
[01:16] <calc> istr this used to happen but now it doesn't for me anymore
[01:17] <calc> i got a bug about OOo not stopping shutdown to save and tested on a vm and it doesn't work even for Gedit for me
[01:17] <slangasek> calc: GNOME upstream broke the use of the standard session protcol
[01:18] <slangasek> calc: so that really ought to be assigned to gnome-session; dunno if a bug is already open
[01:18] <calc> slangasek: ah ok
[01:18] <slangasek> cf. http://np237.livejournal.com/22014.html
[01:19] <calc> slangasek: thanks for the link
[01:25]  * slangasek oohs, noticing that rss-glx is the only thing on the CD using libmagick10 and wondering if he can reclaim 2.4MB by rebuilding it against libmagickcore
[01:28] <slangasek> calc: ooo/amd64 ftbfs?
[01:28] <slangasek> ah, because of libmysqlclient still
[01:28] <slangasek> calc: n/m
[01:29]  * slangasek schedules a retry, since everything seems to be in order now
[01:42] <slangasek> hah, nice; libmagick10 has been split into 'libmagickcore1' and 'libmagickwand1', which... depend on each other.
[01:43] <StevenK> Yes.
[01:43] <slangasek> StevenK: dare I ask why?
[01:43] <slangasek> I knew they were split - why is there a circular dependency?
[01:43] <StevenK> slangasek: Because the Maintainer needs his crack pipe taken away ...
[01:44] <slangasek> well, ok.  It's ImageMagick, so that's par for the course.
[01:44] <slangasek> see also: epochs
[01:44] <StevenK> slangasek: I've been closing my eyes and saying "Lalala" about libmagick10 in NBS since it requires a bunch of source changes and there's a lovely argument going on in the BTS about it ...
[01:44] <slangasek> StevenK: right - I'm going to do rss-glx though, because libmagickcore1+libmagickwand1 is 2.1MB smaller than libmagick10 :)
[01:44] <StevenK> Heh
[01:45] <StevenK> I've been hoping the mess resolves itself, but if it gets much later I'm going to JFDI
[01:45] <slangasek> they must have built it without --enable-inline-fibonnaci-array
[01:45] <TheMuso> cd
[01:45] <slangasek> is the argument in the BTS converging on sanity?
[01:45] <TheMuso> woops wrong tab
[01:46] <StevenK> It wasn't, last I read.
[01:46] <calc> slangasek: yea i just rescheduled armel as well
[01:46] <StevenK> slangasek: I last read the bug in the BTS about a month ago, mind you
[01:47] <slangasek> StevenK: can you nudge it in that direction? :)
[01:47] <StevenK> slangasek: I was staying out of it :-P
[01:47]  * StevenK points to his "Slightly innocent by-stander" hat
[01:48]  * slangasek crosses out "by-stander" and writes in "downstream victim" :)
[01:49] <StevenK> Haha
[03:39] <RAOF> TheMuso: You know how the recent pulseaudio uploads fixed my stutter on HDAs-Intel?  It seems they've transferred them to my USB speakers :(
[03:39] <lifeless> lol
[03:39] <TheMuso> RAOF: That sucks.
[03:40] <RAOF> At least now it correlates with CPU load.
[03:40] <RAOF> Not heavy CPU load, mind.  Just any cpu load.
[03:40] <TheMuso> RAOF: Try alsa-driver 1.0.18 final, if its gone, then its a driver fix we can probably pull to work it out.
[03:40] <TheMuso> Right.
[03:40]  * TheMuso read an interesting tidbit this morning, USB2 is only half-duplex.
[03:41] <RAOF> What's the m-a package for alsa-driver?
[03:41] <TheMuso> RAOF: alsa-source afaik.
[03:45] <RAOF> Mmmm, build-stutter.
[03:45] <LaserJock> can you use sudo to restrict what people can run for stuff that's not for root?
[03:51] <RAOF> Hm.  alsa-source fails to build somewhere.  That's going to be fun for someone not me.
[03:56] <TheMuso> RAOF: Ah ok, will chase that up.
[03:59] <lifeless> r
[03:59] <lifeless> RAOF: how did you go with mono?
[04:00] <RAOF> lifeless: I am, as yet, unable to make it segfault when I'm looking at it.
[04:00] <lifeless> RAOF: ha!
[04:00] <lifeless> RAOF: running under gdb fixes it ?
[04:01] <RAOF> It does indeed.  Well, running the mono commands that the postinst would run under gdb doesn't segfault, at least.
[04:02] <lifeless> RAOF: I will bet that running under valgrind would find it on your machine :P
[04:02] <RAOF> I suppose that if I wanted to be 100% thorough I'd upload a new mono that wraps all executions of mono in gdb, and then build-depend on that new version.
[04:03]  * RAOF wonders if NCommander feels like some more mono pain, with added debug difficulty.
[04:04] <NCommander> AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
[04:04] <NCommander> (no)
[04:04] <RAOF> But this is one that I've only been able to reproduce on the PPA buildds, where we have no access!  What could be more fun than debugging that?
[04:05]  * NCommander turns on the Soyuz light
[04:14] <RAOF> TheMuso: No joy on the alsa-driver 1.0.18 front.  If it's any better, it's not much better.
[04:18] <RAOF> Hm.  What's the easiest way to get a Debian Experimental VM happening in virt-manager?
[04:25] <TheMuso> RAOF: Right, so its probably userspace... again.
[06:27] <superm1> slangasek, i think someone abducted the mythbuntu builds from cdimages.ubuntu.com... there's no ISOs anymore for yesterday or the day before: http://cdimages.ubuntu.com/mythbuntu/daily-live/
[06:27] <slangasek> anything interesting in livefs build logs?
[06:28] <superm1> well there were ISOs before for at least the 12th
[06:28] <slangasek> hmm
[06:28] <superm1> well wait, no i had an 11th downloaded, so i dont know there was for the 12th
[06:29] <superm1> i'll look at livefs build logs
[06:29] <slangasek> it's not a livefs build problem, though there was a livefs build failure on amd64
[06:29] <superm1> (i would have expected that the old one was used anyhow though if later ones were failing)
[06:29] <slangasek> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/jaunty/main/b
[06:29] <slangasek> inary-i386/Packages.bz2  Hash Sum mismatch
[06:29] <slangasek> it's that darn mirroring locking bug
[06:38] <superm1> so likely would affect xubuntu and what not too
[06:39] <slangasek> yes, it's an intermittent thing
[06:39] <dholbach> good morning
[06:39]  * slangasek waves
[06:39] <ion_> Hola
[06:40] <superm1> why did the ISO from the 11th get purged tho if the ones on the 12th and 13th weren't actually made?
[06:40] <slangasek> the script isn't so intelligent that it checks for successful builds before kicking off stale images
[06:40] <slangasek> superm1: there's a 14 now, though :)
[06:41] <superm1> slangasek, well it's unfortunately broke unless it included the xfce4-session build that just finished 7 minutes ago... same for xubuntu.  for some reason it looks like the build was scored really low and didn't build for 8 hours
[06:41] <slangasek> mm
[06:41] <slangasek> well, I was just doing an ISO build anyway, to test that this would work - the livefs still needs rebuilt
[06:42] <superm1> slangasek, yeah i dont think it's even finished the publisher run yet: https://launchpad.net/ubuntu/+source/xfce4-session/4.4.3-0ubuntu2
[06:43] <slangasek> did you happen to take a peek at the amd64 livefs build failure I alluded to?  Anything that needs doing there, or should that sort itself out?
[06:43] <superm1> let me take a look
[06:44] <superm1> hm, very bzr. "                     Depends: update-manager but it is not going to be installed" what would prevent "update-manager" of all things?
[06:44] <superm1> i suspect it should sort itself out, but if it doesnt i can prepare an amd64 chroot sometime tomorrow
[06:55] <liw> hrmph, unable to install hardy this morning, results in grub saying "Error 18"
[06:56] <liw> oh, hm, http://wiki.linuxquestions.org/wiki/GRUB#Error_18
[06:59] <sladen> liw: you needs a /boot somewhere "near" to the start of the disk (<2GB IIRC)
[07:00] <sladen> well, 8GB, according to that URL
[07:01] <liw> sladen, yeah, but I keep being weirded out that a modern motherboard's bios needs that still
[07:04] <sladen> liw: using some low-level ext hackery it would be possible to force certain files below a magic threshold, but I (probably like you) thought it was "fixed" by now
[07:14] <RAOF> Amaranth: bluesmoke?
[07:14] <Amaranth> RAOF: magic blue smoke
[07:15] <Amaranth> RAOF: Your computer makes it when you compile mono too many times
[07:15] <RAOF> Heh.
[07:15]  * RAOF 's box made it without compiling mono _at all_.
[07:55] <ashvala> Hello
[07:55] <ashvala> [ 52.630275] SDA:<4>Driver 'sr' needs updating - please use bus_type methods HELP!
[07:55] <ashvala> please help
[08:39] <slangasek> calc: the fortran stuff cleaned up nicely; the java stuff is still there even on i386 - is that because -l10n hasn't built yet?
[08:51] <voox> is it fairly safe to update from a fresh install with alpha 2?
[08:53] <DktrKranz> bryce: thanks for devscripts! I'll file a wishlist bug in Debian too later this evening. Regarding its merge, I could look at it in the next few days.
[09:20] <lool> slangasek: Reviewed jflex; found a bunch of small issues which can easily be resolved, but I don't think we should block main promotion on them
[10:51] <liw> what's the status of radeon support with free drivers? my RV630 does not seem to work in intrepid, but perhaps jaunty has new goodies?
[11:51] <savvas> Qt will use lgpl: http://www.eweek.com/c/a/Linux-and-Open-Source/Nokia-to-Offer-Qt-Under-LGPL-Licensing/
[12:43] <Keybuk> cjwatson: do we have anything that tries to populate /dev anymore?
[12:47] <Keybuk> (other than makedev itself)
[12:47]  * ogra just wanted to note there are some postinsts that run makedev :)
[12:47] <asac> james_w: i saw that you took over the firebug branch with what comes from debian at some point.
[12:47] <Keybuk> yeah, they'll fail now ;)
[12:47] <Keybuk> (in Debian too)
[12:47] <james_w> asac: yeah
[12:47] <ogra> i saw that (on arm though)
[12:48] <asac> james_w: and changed the binary package name from firebug to iceweasel?
[12:48] <james_w> asac: nope
[12:48] <Keybuk> ogra: I'm wondering whether we should drop makedev
[12:48] <ogra> how is that supposed to work now ?
[12:48] <ogra> calling some udev specific command ?
[12:49] <Keybuk> ogra: the device will already exist ?
[12:49] <ogra> or does it just rely on the kernel creating these devices
[12:49] <asac> james_w: did you try to contact jared first? (who was the original maintainer)
[12:49] <Keybuk> there aren't any devices for which the kernel won't create it first
[12:49] <ogra> ah
[12:49] <james_w> asac: it was a merge from Debian as the Ubuntu package was really out of date, modifications were made from Debian's package to make it work with firefox etc.
[12:49] <james_w> asac: no, I didn't. There was an old upgrade bug open on the package.
[12:50] <ogra> well, people will complain if they dont have makedev anymore ...
[12:50] <asac> james_w: you could have pinged us ;)
[12:50] <asac> ok
[12:50] <james_w> asac: I didn't feel I needed to.
[12:50] <Keybuk> ogra: will they?
[12:50] <ogra> but thats the only drawback i see ... i.e. if you have scripts that use it to create any special devices
[12:50] <Keybuk> makedev is already a no-op with a warning if you try and run it
[12:51] <cjwatson> Keybuk: I don't think so
[12:51] <ogra> oh, and i was talking about mknod :) ignore me :)
[12:51] <cjwatson> I was under the impression that postinsts that run makedev generally had conditionals
[12:51] <asac> james_w: you know that an extension team existed ;)
[12:52] <ogra> i saw a lot of makedev calls building the last arm rootfs tree
[12:52] <ogra> but they usually only warn
[12:52] <james_w> asac: yes, and I updated the branches from the debdiffs that were supplied.
[12:52] <cjwatson> NCommander: bug 316841: don't we need to update finish-install too to set up an upstart job for the serial console?
[12:52] <Keybuk> cjwatson: we end up with a fairly random set of stuff in the "real" /dev
[12:52] <Keybuk> many of which have the wrong names, permissions, etc.
[12:53] <Keybuk> it would be nicer if that just had the most basic devices like console, null, etc. only
[12:53] <asac> james_w: in general all is fine .. i just think that you changed the orig tarball layout to something that cannot be patched without patchsystem
[12:53] <asac> which is somewhat bad ;) ... but now its done, so whatever ;)
[12:53] <cjwatson> debootstrap might populate it a bit, though I thought it had stopped doing that
[12:53] <Keybuk> cjwatson: the makedev postinst itself populates it
[12:53] <james_w> asac: ah, ok, sorry about that.
[12:54] <Keybuk> and there are packages that call makedev if they don't think udev is running
[12:54] <Keybuk> which means it ends up partially populated when installing
[12:54] <james_w> asac: you should probably create a README.Source that you can reference from these packages that explains this stuff.
[12:54] <asac> james_w: we will bring mozilla-devscripts to debian soon ... then firebug guy can use med-xpi-unpack and med-xpi-pack to do that
[12:55] <asac> e.g. creating a good orig
[12:55] <cjwatson> Keybuk: a udev /dev should be bind-mounted during installation though
[12:55] <asac> firebug guy/debian guy/
[12:55] <Keybuk> cjwatson: is it?
[12:55] <cjwatson> we do mount --bind /dev /target/dev
[12:56] <asac> james_w: yeah true ... i just didnt expect someone to go and merge from debian to a previously independent branch ... my wrong
[12:56] <cjwatson> I can't swear that that's present at all possible points but I certainly thought it ought to be
[12:56] <Keybuk> damn, I shall have to figure this bug out harder then ;)
[12:56] <cjwatson> you could add something to makedev.postinst to check for the udevdb
[12:56] <Keybuk> there's something in MAKEDEV itself that does that already
[12:57] <asac> james_w: but lets move on ;)
[12:57] <cjwatson> oh yes
[12:57] <Keybuk> you can't MAKEDEV over the top of udev
[12:57] <cjwatson> do we need to install the makedev package by default any more?
[12:57] <Keybuk> cjwatson: support for making devices other than in /dev ?
[12:57] <Keybuk> (it's a bit of a long stretch)
[12:57] <Keybuk> a few things depend on it
[12:57] <cjwatson> hmm, udev is probably not installed in buildd chroots
[12:57] <cjwatson> historically that has been Painful
[12:58] <asac> james_w: btw, the work you did is much appreciated ;) (in case it sounded different)
[12:58] <Keybuk> why would something need to call makedev during package builds?
[12:58] <Keybuk> that's not even possible surely? :p
[12:58] <cjwatson> it wouldn't, but the buildd chroots probably need at least a few devices present
[12:58] <cjwatson> I don't know if they bind-mount /dev
[12:58] <Keybuk> interesting question
[12:58] <james_w> asac: no problem. I realise that you are trying to do something a bit different and I don't want to make it harder than it has to be for you.
[12:58] <cjwatson> it's nice for debootstrapped chroots to have some useful devices out of the box too
[12:59] <Keybuk> yeah, I was thinking of just going for a more minimal default /dev
[12:59] <Keybuk> without some of the more exotic devices
[13:01] <Keybuk> bryce: around?  (re: sane-backends)
[13:01] <asac> james_w: in fact i dont try to do things different. just wasnt sure (and still nto 100% sure) what to do with debian merges for pre-existing branches
[13:10] <cjwatson> Keybuk: debootstrap appears to do 'MAKEDEV std ptmx fd' and put the result in /dev
[13:11] <cjwatson> which IIRC is not an entirely crazy set
[13:11] <Keybuk> right
[13:11] <Keybuk> that's a pretty reasonable core set
[13:12]  * Keybuk tries to remember why he doesn't just call MAKEDEV to populate /lib/udev/devices
[13:12] <cjwatson> so I think that means makedev may be unnecessary in the required seed
[13:12] <cjwatson> it's explicitly seeded there right now
[13:13] <Keybuk> enough base things depend on it that it'll stay in the seed
[13:13] <Keybuk> but we could probably unseed it and see how long it takes to go away
[13:15] <cjwatson> yeah, that's what I meant
[13:16]  * Keybuk likes discussing changing fundamental things in the middle of an alpha freeze <g>
[13:16] <cjwatson> germinate seems to think that it should at least drop out to standard
[13:16] <cjwatson> which would mean debootstrap would stop installing it
[13:24] <Keybuk> cjwatson: *nods*
[13:24] <Keybuk> a few things seem to hold it in standard
[13:24] <cjwatson> fuse-utils
[13:24]  * Keybuk looks at ogra ;-)
[13:24] <cjwatson> should be easy to address
[13:25] <ogra> hmm, havent touched it for a whil ... i'll look
[13:25] <ogra> *while
[13:25] <ogra> i think that comes from the odd debian postinst scrits we dont use ...
[13:25] <ogra> *scripts
[13:26] <ogra> ogra@osiris:~/Devel/packages/fuse-2.7.4$ grep makedev debian/*.post*
[13:26] <ogra> debian/fuse-utils.postinst:  	# Call makedev and fix perms
[13:27] <ogra> well, that indeed justifies a dependency ... omg ! its mentioned in the comments !!!
[13:27]  * ogra drops :)
[13:28] <asac> james_w: any ideas how i could publish a failed bzr merge? just forcefully committing and requiring developers to uncommit to work on it?
[13:28] <ogra> Keybuk, fix uploaded
[13:29] <asac> james_w: will bzr resolve FILE forcefully resolve a conflict?
[13:29] <james_w> asac: can they not just the merge for themselves?
[13:29] <asac> james_w: but how to publish the "work task" ?
[13:29] <asac> james_w: that would require a separate channel like mailing list etc.
[13:30] <james_w> launchpad merge request?
[13:31] <asac> james_w: yeah. that could be used, but is a bit of a launchpad specific problem to the general problem. but good enough i guess (just have to figure out the xml api i guess)
[13:31] <asac> s/specific problem/specific solution/ ;)
[13:32] <james_w> the API doesn't quite allow you to create merge requests yet I believe
[13:32] <asac> hmm ... that would be a blocker then ;)
[13:32] <james_w> I agree a way of storing a conflicted tree with pending merges might be quite useful
[13:32] <james_w> but force committing it isn't the answer
[13:32] <asac> yeah. thats why i asked ;)
[13:36] <asac> james_w: if i uncommit, i can still refer to that revision right?
[13:36] <siretart> why is there no linux-image-debug-2.6.27-9-generic on security.ubuntu.com? `apt-cache madison linux-image-debug-2.6.27-9-generic` claims it to be produced from the source package linux_2.6.27-9.19, but it does not seem to be published at all!
[13:36] <james_w> asac: yeah, by revid
[13:36] <asac> james_w: but i guess that hidden revision isnt pushed?
[13:36] <james_w> asac: correct
[13:37] <asac> couldnt a similar mechanism be used to publish such broken merge requests?
[13:37] <asac> james_w: ?
[13:37] <james_w> what mechanism?
[13:37] <asac> james_w: to have a revid that represents the broken merge
[13:38] <james_w> not really, as a pending merge/conflicts are working tree things, not revisions
[13:39] <asac> james_w: yes, but if uncommit a merge, isnt the merged tree still reachable through the "hidden" revid?
[13:40] <asac> but well, i better stop talking about things i dont know any details ;)
[13:40] <james_w> yes, you are right
[13:41] <asac> james_w: about the former or the latter ... or both?
[13:41] <asac> :-P
[13:41] <james_w> but it's equally as accessible, more visible, and easier to refer to in the place that you merged from
[13:41] <james_w> heh :-)
[13:41] <james_w> the former
[13:44] <cjwatson> ogra: it wasn't just the comments, note that makedev's executable is in upper case :-P
[13:45] <ogra> argh
[13:45] <cjwatson> but that code path is never executed if udev is active anyway
[13:45] <cjwatson> I'm not sure what would happen if you installed fuse-utils in a buildd chroot, though
[13:45] <cjwatson> we could just make the postinst succeed anyway
[13:46] <cjwatson> lamont`: ah, excellent timing. Do buildd chroots bind-mount /dev from the base (presumably udev)?
[13:46] <ogra> just an || true ?
[13:46]  * ogra would rather comment that line out completely though
[13:47] <lamont`> cjwatson: buidld chroots have proc and dev/pts from the parent
[13:47] <cjwatson> can they have /dev?
[13:47] <cjwatson> or is there a good reason not to?
[14:08] <asac> james_w: 317111
[14:10] <james_w> thanks
[14:20] <superm1> slangasek, it looks like the livefs for mythbuntu still have the old xfce4-session for today.  xubuntu's is good I believe ( cody-somerville can you confirm? ), could you poke it to do one more build?
[14:23] <cody-somerville> superm1, charlie-tca confirms livecd starts fine today
[14:24] <cody-somerville> As for mythbuntu, I don't have access to distro build infrastructure (I'm in OEM Services). slangasek, cjwatson, or evand should be able to help you get you your livefs rebuilt.
[14:24] <superm1> thanks
[14:24] <cody-somerville> superm1, Have you looked to see if maybe your livefs build failed?
[14:25] <BUGabundo_work> cjwatson: ping
[14:25] <superm1> cody-somerville, yeah the last one passed: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/mythbuntu/20090114/ .  I think it was just an inconvenient time that it was cronned before things were published
[14:25] <BUGabundo_work> cjwatson: yesterday daily jaunty installer won't accept a swap + / ext4
[14:26] <BUGabundo_work> plus gparted on the livecd doesn't support et4
[14:26] <BUGabundo_work> *ext4
[14:26] <cody-somerville> BUGabundo_work, are you running Windows at the moment?
[14:27] <BUGabundo_work> yes from another PC
[14:27] <BUGabundo_work> took almorning backing up disk to external driver
[14:27] <BUGabundo_work> uses usbcreator to make a pendrive
[14:27] <BUGabundo_work> and now am stuck with the install!
[14:27] <cjwatson> BUGabundo_work: the gparted bug for ext4 is still open
[14:27] <BUGabundo_work> reporting both bugs on LP
[14:27] <cjwatson> do not report that one again
[14:27] <BUGabundo_work> ok I'll subs to it then
[14:28] <BUGabundo_work> won't!
[14:28] <BUGabundo_work> about the installer cjwatson?
[14:28] <BUGabundo_work> 8GiBs swap + / ext4 is replaced by / ext3 + /Home ext3
[14:28] <BUGabundo_work> very strange
[14:28] <cjwatson> BUGabundo_work: do you mean that you did guided partitioning?
[14:28] <BUGabundo_work> manual
[14:28] <BUGabundo_work> does the guided handle ext4?
[14:29] <cjwatson> no
[14:29] <BUGabundo_work> there you go
[14:29] <cjwatson> so you must have created /home by hand. Do you mean that it did not recognise the existing ext4 partition as being ext4?
[14:29] <BUGabundo_work> old partitions were ext3. one / + one /home plus one swap
[14:30] <BUGabundo_work> I deleted them via installer (which means they are still intact)
[14:30] <cjwatson> BUGabundo_work: so I do not understand your bug. First you say that the old partition was ext4, now you say that it was ext3
[14:30] <BUGabundo_work> and "tried" to create new ones
[14:30] <cjwatson> can you please be more precise?
[14:30] <BUGabundo_work> no no no
[14:30] <BUGabundo_work> old was ext3
[14:30] <BUGabundo_work> and xfs
[14:31] <BUGabundo_work> new schema with deleted old partitions is meant to be 8gibs /swap + / ext4
[14:31] <cjwatson> BUGabundo_work: please file a bug stating precisely what you did, step by step
[14:31] <BUGabundo_work> but the installer replaces that with 8g / ext3 and /home ext3
[14:31] <BUGabundo_work> no swap, no ext4
[14:31] <cjwatson> BUGabundo_work: concentrate on making it possible for me to follow the same steps and reproduce the problem
[14:31] <BUGabundo_work> sure
[14:31] <BUGabundo_work> brb
[14:31] <cjwatson> that's deeply improbable
[14:31] <cjwatson> the installer never creates /home by default
[14:31] <BUGabundo_work> do you have the bug id for gparted?
[14:32] <BUGabundo_work> I know! its strange
[14:32] <cjwatson> no, but it shouldn't take you long to look it up
[14:32] <BUGabundo_work> I can show you via webcam
[14:32] <BUGabundo_work> do you want that ?
[14:32] <cjwatson> BUGabundo_work: is this the alternate installer or the desktop installer
[14:32] <cjwatson> no, I would rather not have a video
[14:32] <BUGabundo_work> humm tried first from the quick installer at livecd boot
[14:32] <BUGabundo_work> then from Full desktop live
[14:32] <cjwatson> so the desktop installer
[14:33] <BUGabundo_work> will reboot, and report the bug, step by step
[14:33] <cjwatson> BUGabundo_work: please attach /var/log/syslog, /var/log/partman, and /var/log/installer/debug *after* reproducing the bug but *before* rebooting
[14:33] <BUGabundo_work> I don't know how you guys call the installer that doesn't boot into desktop
[14:33] <BUGabundo_work> okay
[14:33] <cjwatson> it's the same installer
[14:34] <BUGabundo_work> okay
[14:34] <BUGabundo_work> good to know
[14:37] <BUGabundo_work> cjwatson: I'm still making a webcam cast of the procedure
[14:37] <BUGabundo_work> in case you want to watch it later
[14:37] <BUGabundo_work> http://bambuser.com/node/68590
[14:37] <cjwatson> usually logs are actually more helpful to me, but thank you
[14:38] <cjwatson> once in a blue moon I guess a video would be handy
[14:38] <BUGabundo_work> no prob
[14:40] <BUGabundo_work> ok just reproduced it!
[14:40] <BUGabundo_work> getting logs to a bug
[14:41] <BUGabundo_work> cjwatson: what package?
[14:43] <cjwatson> BUGabundo_work: ubiquity
[14:43] <cjwatson> (it's probably not really there but that's a good starting point)
[14:46] <BUGabundo_work> cjwatson: bug 317124
[14:46] <BUGabundo_work> uploading logs now
[14:47] <cjwatson> thanks
[14:48] <BUGabundo_work> cjwatson: logs sent
[14:48] <BUGabundo_work> bug 317124
[14:48] <BUGabundo_work> ping me for any extra test or info
[14:49] <cjwatson> BUGabundo_work: OK, I'm working on something else right now but will get to this next
[14:50] <BUGabundo_work> thanks
[14:50] <BUGabundo_work> if it gets fixed today, maybe I can still test it again
[14:50] <BUGabundo_work> and get a fresh install
[14:50] <BUGabundo_work> finally
[14:51] <BUGabundo_work> 10GiBs for / is full
[14:53] <BUGabundo_work> cjwatson: are you kamion on LP?
[14:58] <cjwatson> BUGabundo_work: yes
[15:09] <calc> slangasek: yes that would be because of the ooo-l10n afaik
[15:12] <cjwatson> BUGabundo_work: ok, turns out it's nothing to do with ext4 and is a bug that's been fixed in a more recent version of ubiquity
[15:13] <cjwatson> BUGabundo_work: I'd appreciate it if you didn't assign bugs to me in future
[15:13] <cjwatson> my manager gets to do that :)
[15:16] <robbiew> cjwatson: ;)
[15:17] <cjwatson> I must backport that gparted patch though, a lot of people have been asking for it
[15:18] <BUGabundo_work> cjwatson: sorry
[15:30] <Keybuk> not for the first time I wish that dpkg had a command line option to tell you what deps were missing
[15:31] <liw> dpkg -i foo.deb; apt-get -f install # this more or less works as a workaround (Keybuk surely knows this, but others might not have realized)
[15:31] <ogra> Keybuk, ther is that apt thing :)
[15:35] <mvo_> gdebi is also a handy tool for this
[15:38] <Keybuk> liw: that's not quite what I meant
[15:38] <Keybuk> apt attempts to fix it given the known archives
[15:38] <Keybuk> (dpkg --configure -a gives similar output, but also tries to fix things)
[15:38] <Keybuk> all I want to know is what's wrong
[15:39] <liw> Keybuk, ok
[15:39] <liw> apt-get has --no-act, though
[15:40] <mvo_> Keybuk: is gdebi what you want then? it will also look at the known archive but will tell you about stuff it can not find
[15:40] <Keybuk> dunno
[15:40] <Keybuk> it's more the versions
[15:40] <Keybuk> I've installed a bunch of jaunty packages on intrepid
[15:40] <Keybuk> want to know what I need to upgrade
[15:46] <ion_> liw: dpkg --unpack foo; apt-get -f install rather.
[15:49] <joaopinto> Keybuk, the fix attempt from apt-get -f install will show you the problems ....
[15:51] <joaopinto> bue like mvo explained, gdebi will do that on a preventive manner
[15:55] <slangasek> lool: jflex> cheers - do we need to look at getting jlex demoted as well?
[15:56] <slangasek> ogra: hrm, was this fuse upload really warranted during a milestone freeze?
[15:57] <ogra> slangasek, err, i thought we are suposed to upload to have it in the queue
[15:57] <ogra> slangasek, its not urgently needed in the images
[15:57] <slangasek> superm1: yes, mythbuntu livefs respinning now
[15:57] <superm1> slangasek, great thanks
[15:57] <slangasek> ogra: we haven't been using a queue for alpha milestones for 3 release cycles...
[15:57] <ogra> meh, sorry then
[15:58] <ogra> it wont do any harm though
[15:58] <mvo_> slangasek: I have a pending update-manager upload that helps nvidia users, is it ok to still upload ?
[15:58] <slangasek> mvo_: bug #?
[15:59] <mvo_> slangasek: bug #308410
[15:59] <mvo_> slangasek: the "fix" for now is to auto transition the users from nvidia to nv in the xorg conf
[16:01] <slangasek> mvo_: I probably won't respin all the images for the fix (xubuntu/ubuntustudio are already built, and that's clearly an upgrade-only fix so not entirely relevant to milestone ISOs), but yeah, go ahead with uploading
[16:04] <mvo_> thanks slangasek, will do after the meeting (I want to review the debdiff again and run a test just to be sure that I don't do breakage)
[16:08] <seb128> slangasek: hi, could you accept the evolution-exchange intrepid sru? the evolution update broken for exchange users and that one should fix the issue
[16:08] <slangasek> seb128: yes, shortly - in a meeting now
[16:08] <seb128> slangasek: ok thanks
[16:19]  * calc apologizes for interupting the meeting i didn't see what channel my name highlighted in due to irssi screen limitation issues
[16:19] <cjwatson> ogasawara: why does bug 34190 show up in the "other" section of http://qa.ubuntu.com/reports/ogasawara/jaunty-buglist.html? It has the qa-jaunty-foundations tag and should go in the Foundations section
[16:20] <ogasawara> cjwatson: hrm, I'll investigate
[16:21] <ogasawara> cjwatson: you may also want to use http://qa.ubuntu.com/reports/ogasawara/qa-jaunty-buglist.html instead.  Should be the same list, just has a LP look and feel with sortable columns
[16:21] <cody-somerville> mvo_, I'm having trouble with bug #310137. My merge FTBFS because it says the libc6 version is too high although in the newsfile for valgrind, apparently this version added specific support for 2.8. Is it safe to patch it to let it compile with 2.8 or do I have to regenerate the configure file stuff or something? :P
[16:22] <cjwatson> ogasawara: thanks
[16:24]  * lamont` finally gets annoyed enough at cups to file bug 317153
[16:25] <mvo_> cody-somerville: if it works with 2.8 I would say patch it and forward the patch to upstream (might be a oversight or something by upstream)
[16:26] <lool> slangasek: I don't know anything about jlex; if you think it's not needed in main, then I trust you!
[16:26] <cody-somerville> mvo_, k
[16:26] <slangasek> lool: well, the description of jflex is "a reimplementation of jlex"
[16:26] <slangasek> lool: so I guess it would be nice to not have two of them in main
[16:28] <cjwatson> ogasawara: the intention is that simply tagging a bug gets it onto that list, isn't it?
[16:28] <lool> slangasek: Good point
[16:28] <ogasawara> cjwatson: yup
[16:28]  * cjwatson has no problem with jlex being demoted (as the Debian maintainer, although the mists of time have swallowed up why I decided to maintain it)
[16:33] <slangasek> cjwatson: are you in a position to migrate libxsltc-java to jflex?  I haven't looked into what that entails, so far was just asking the question
[16:35] <cjwatson> I'm not sure I could do a good job, but I suppose I can try
[16:36] <cjwatson> I haven't looked at jlex non-trivially in years
[16:46] <cjwatson> slangasek: jflex can handle the .lex file there OK, but I wouldn't even know where to start with testing whether there are any regressions; the generated scanner looks completely different
[16:47] <slangasek> hmm, fun
[16:47] <slangasek> well, we can try it out post-A3 then maybe
[16:48] <cjwatson> I think somebody should ask upstream
[16:48] <slangasek> jflex upstream?
[16:49] <cjwatson> xalan upstream
[16:49] <slangasek> ok
[17:04] <LaserJock> cjwatson: do you know if the supported seed in edubuntu actually used?
[17:05] <sahko> hi, does anyone maybe know the result of the discussion regarding cdrtools inclusion in ubuntu as mentioned here: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-August/000472.html ?
[17:06] <sahko> i asked on the forum too but didnt get an answer so far. sorry if this is outside the purpose of this channel. didnt know where else to ask
[17:08] <cjwatson> LaserJock: supported seeds are necessary for germinate to behave properly
[17:08] <TheMuso> sahko: Afaik its still ongoing.
[17:09] <cjwatson> LaserJock: it puts build-dependencies in their
[17:09] <cjwatson> there (argh!)
[17:09] <cjwatson> sahko: was mentioned in the minutes of yesterday's TB meeting, posted to ubuntu-devel. As TheMuso says, still ongoing.
[17:09] <sahko> TheMuso: so discussion has started. from a;; sodes
[17:09] <sahko> all sides*
[17:09] <sahko> schilling too..
[17:09] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027182.html
[17:10] <LaserJock> cjwatson: ah, right. so is supported automatically generated at all? I'm looking at Edubuntu's and it doesn't seem right
[17:10] <cjwatson> LaserJock: it's probably wrong, but is not very important
[17:10] <cjwatson> looks like an old copy of Ubuntu's with some bits added
[17:10] <LaserJock> yeah
[17:10] <cjwatson> I wouldn't worry about it too much ...
[17:10] <cjwatson> it used to be used for DVDs
[17:10] <LaserJock> but will that prevent demotion?
[17:10] <cjwatson> yes
[17:11] <sahko> cjwatson: thanks. good luck with this to whoever participates. hope cdrtools get included in future versions. the fork is unusable
[17:12] <LaserJock> cjwatson: ok, another quick question related to the DVD if you don't mind, how is the package list then determined?
[17:13] <bryce> Keybuk: yep?
[17:13] <Keybuk> bryce: you appear to have not included the changes I made in my last upload
[17:13] <Keybuk> just the changelog entry
[17:14] <bryce> hm, not by intention, let me doublecheck
[17:14] <sahko> bye
[17:14] <slangasek> calc: OOo-core still depends on librdf0?
[17:15] <slangasek> calc: that's 2MB for librdf0, librasqal1, libraptor1, libmysqlclient15off, libpq5, mysql-common
[17:16] <bryce> Keybuk: weird.  ok I'll look into it
[17:16] <Keybuk> np :)
[17:20] <slangasek> calc: actually, adding in the rdf recommends, that costs us 7MB total... I guess I'll look at whether those recommends can be reasonably demoted
[17:20] <cjwatson> LaserJock: we haven't built Edubuntu DVDs for some time, so "it isn't"
[17:21] <cjwatson> LaserJock: for Ubuntu and Kubuntu, we use a separate "dvd" seed nowadays
[17:21] <LaserJock> cjwatson: right, but I thought you could install edubuntu-desktop for instance from the Ubuntu DVD
[17:21] <bryce> Keybuk: heh
[17:21] <bryce> Keybuk: looks like we both did our uploads at the same time
[17:21] <LaserJock> I haven't personally used the DVD so I don't know for sure
[17:23] <cjwatson> LaserJock: that works by the stupid hack of explicitly seeding the 'edubuntu-desktop' metapackage in ubuntu.jaunty/dvd
[17:23] <cjwatson> see the comment above that seed entry
[17:23] <cjwatson> and feel free to sync that up if necessary
[17:23] <LaserJock> yeah, I see it
[17:24] <LaserJock> and I need to sync that up since I'm dropping the edubuntu-addon bits
[17:24] <LaserJock> cjwatson: ok, thanks, that helped
[17:25] <calc> slangasek: yes and it actually Depends on lpsolve so it will probably break calc for alpha3 but i can see about getting suitesparse broken up into another package for alpha4 so calc won't be broken in it
[17:25] <cjwatson> rickspencer3: do you know if anyone is going to look at bug 288494? it looks like it's missed alpha 3 now
[17:25] <cjwatson> rickspencer3: err, sorry, not alpha 3, I meant to say Ubuntu 8.04.2
[17:27] <slangasek> calc: oh, correcting myself, the {redland,raptor}-utils recommends have only a minor impact on disk space.  librdf0 itself pulls in 6MB of deps.  What do we need that for?
[17:32] <calc> slangasek: redland (librdf) is used to support ODF 1.2 metadata
[17:32] <calc> it doesn't appear to be something that could easily be left out
[17:32] <slangasek> argh
[17:35] <calc> slangasek: rene seems to think reverting to internal would work well enough for now, but may need to switch back to external later (probably when we do split build for jaunty+1)
[17:36] <calc> slangasek: would you like me to reroll it with internal redland and reverting the java change and have you drop help from the cd?
[17:36] <slangasek> what do you mean, "reverting the java change"?
[17:36] <slangasek> oh, re-adding it to help
[17:37] <calc> slangasek: the issue you discussed with rene about help really needing java so help should just be dropped from the cd
[17:37] <calc> yes
[17:38] <slangasek> dropping help from the CD means either getting ArneGoetje to reroll language-support-translations-en, or dropping language-support-en from the CD
[17:38] <calc> ah hmm
[17:38] <calc> ArneGoetje: ping ? :)
[17:39] <cjwatson> dropping language-support-en from the CD will have installer consequences
[17:39] <calc> yea dropping it isn't really an option
[17:39] <slangasek> what sort of consequences?
[17:39] <cjwatson> it will tell everyone that they have incomplete language suport
[17:39] <cjwatson> support
[17:40] <cjwatson> and will prompt them during d-i installations to say that language-support packages are unavailable on the CD
[17:40] <cjwatson> _Description: Download language support?
[17:40] <cjwatson>  The installation CD does not contain full support for your language. Do you
[17:40] <cjwatson>  want to download the required packages from the Internet now? This includes
[17:40] <cjwatson>  spell-checking, dictionaries, and translations for various applications.
[17:40] <cjwatson>  .
[17:40] <cjwatson>  If you do not want to download this now, you may start the Language
[17:40] <cjwatson>  Selector after installation to install complete support for your language.
[17:40] <slangasek> hmm, right
[17:42] <slangasek> cjwatson: what do you think about rerolling language-support-translations-en to not install OOo-help-en-*?
[17:42] <slangasek> each .deb is ~6MB, dunno how much that'll buy us on the liveCD
[17:42] <cjwatson> it's a plausible option
[17:42] <bryce> Keybuk: uploaded.  Sorry bout that, looks like you put in your change right before I posted the merge.  Good timing.
[17:43] <cjwatson> it could be rerolled by hand without the langpack-o-matic infrastructure if you're in a rush, as long as langpack-o-matic gets synced up afterwards
[17:43] <slangasek> right
[17:45] <slangasek> so if we do drop those deps, what will be the right component to pull in the help later for users?
[17:45] <calc> do we even have a mechanism to do that?
[17:45] <slangasek> that's the question
[17:46] <calc> if there is adding all of OOo as an option to show the user would be extremely helpful ;-)
[17:46] <cody-somerville> mvo, I just noticed that jaunty now has glibc 6.9
[17:46] <cody-somerville> er...
[17:46] <cody-somerville> 2.9
[17:48] <slangasek> calc: that's not the kind of mechanism I had in mind; I was more thinking of a way to have the localization pulled in *when* you install the OOo metapackage
[17:48] <calc> ah
[17:50]  * calc thinks the other would be helpful also in other cases of abused Recommends demotion to fit stuff onto CD, etc :-\ Recommends used to mean more than just what we think you should have that also happens to fit on the CD
[17:51] <slangasek> if I make this change, English will be the *only* language for which users don't automatically get OOo help files; and if you reupload -l10n, users of all the other languages get to download the 90MB of java as part of the language support download
[17:52]  * calc still isn't quite sure what the ooo split build will do wrt CD space issues, fun for Jaunty+1 I'm sure
[17:53] <slangasek> "split build" meaning what?
[17:53] <calc> for one we will no longer have any internal libraries, at least afaict
[17:53] <slangasek> well, so far using external libraries hasn't been an improvement
[17:53] <calc> slangasek: splitting the monolithic source into the relevant modules and building without any internal copies of 3rd party libraries, etc
[17:54] <slangasek> since librdf0 for some reason has to pull in libmysqlclient and libpq5 :P
[17:54] <calc> so there will be a writer source, ure source, etc
[17:54] <cjwatson> i.e. "modular OOo" (to go with modular X)
[17:55] <calc> i'm targeting 3.1/3.2 for the switch depending on how the meeting goes at Sun next month
[17:55] <slangasek> and how modular will it really be, given things like "your documents will be corrupted if you don't have -math installed"?
[17:56] <moh_bana> hello, is it true that there's a free ver. of the broadcom drivers?  i've been trying to install this crap for ages with no luck
[17:56] <calc> slangasek: once we get to that point I am hoping upstream will consider those type things to be real bugs
[17:56] <calc> slangasek: currently they expect OOo to be installed, and as its monolithic all of it to be
[17:58] <slangasek> sigh
[17:58] <slangasek> splitting mysql/postgres off of librdf0 would probably also take care of the problem
[17:58] <slangasek> the current size problem, that is
[17:59] <slangasek> we still have the help package problem
[17:59] <calc> well help as it stands doesn't install java now but also means the search doesn't work
[17:59] <slangasek> yeah.
[17:59] <calc> we could punt that decision to later i suppose
[17:59] <slangasek> I'm trying to decide whether I want to mangle redland on the fly here, or wait for another round of OOo build
[18:00] <slangasek> s
[18:02] <slangasek> calc: <sigh> I think we're better off with rebuilding OOo to use internal redland, for now
[18:02] <calc> slangasek: ok
[18:03] <calc> i think that should be fine for this release cycle and then we'll have to see what OOo does in general when it becomes modular
[18:03] <calc> i should have builds of that going by late march i think with 3.1
[18:03] <slangasek> I'm going to file a bug with dajobe about wanting to be able to split off the mysql/postgres storage stuff
[18:03] <calc> ok
[18:04] <calc> slangasek: i'm going to eat lunch quick and then get the new upload done
[18:04] <calc> slangasek: so just the redland change for a3?
[18:04] <slangasek> yes, just the redland change please
[18:04] <calc> ok
[18:04] <calc> bbia 15m or so
[18:04] <slangasek> (also means that we don't have to wait for both OOo and OOo-l10n to build)
[18:15] <cody-somerville> mvo, Are you familiar with the Debian maintainers of valgrind? Do they plan to upload the new 3.4.0 version to enable support for glibc 2.9?
[18:22] <SimoneB> is there a channel about app development in ubuntu? (or, to make it short, is there a genetic algorithm package in the ubuntu's repositories?)
[18:23] <zorglu_> q. what is the default --prefix for ./configure on ubuntu ?
[18:23] <Pici> !info python-genetic | SimoneB
[18:25] <SimoneB> ahum, right. I hoped in a C version, but i'll take a look at that, thanks
[18:26] <Pici> SimoneB: I just searched for 'genetic' in the repos. apt-cache search genetic  spits out a whole bunch of matches
[18:26] <SimoneB> Pici: why did it have just 2 results when i did it? python-genetic and cl-rsm-genetic-alg (a lisp version)
[18:28] <Pici> SimoneB: aptitude search, or apt-cache? aptitude only looks in package names by default
[18:28] <SimoneB> Pici: ahhh! I did aptitude search, infacts. thanks.
[18:37] <calc> back, working on ooo3 redland issue now
[18:45]  * calc needs to run a test build to make sure disabling redland doesn't cause other build issues
[19:08] <BUGabundo1> cjwatson: those the fix of bug 310083 fix the problem I reported today?
[19:08] <BUGabundo1> evand: ping
[19:09] <evand> BUGabundo1: pong
[19:10] <evand> BUGabundo1: can you rephrase your question, I do not understand what you're asking
[19:10] <evand> the bug should be fixed in ubiquity 1.11.3
[19:10] <evand> be sure to check you're using the correct version by running ubiquity --version
[19:11] <BUGabundo1> evand: the bug that you marked as dupe of 310083
[19:12] <BUGabundo1> today I tried to use yesterday live cd
[19:12] <evand> that wont have the fix
[19:12] <BUGabundo1> but ubiquity would change my partition schema
[19:12] <evand> only today's CD does
[19:12] <BUGabundo1> but marked it as a dupe, and I don't see a fix or mention for it in the bug
[19:13] <BUGabundo1> I'll download tomorros (or tonight) daily build and test again!
[19:13] <evand> it's a different symptom, but it's the same bug
[19:13] <BUGabundo1> okay
[19:13] <BUGabundo1> 'cause I never saw any crash!
[19:13] <mvo> cody-somerville: I'm not familiar with the debian mantainer, sorry
[19:19] <ScottK> LaserJock: Do we have any other Jabber servers in Main?
[19:20] <LaserJock> ScottK: we might but I think ejabberd is the preferred one
[19:20] <LaserJock> from what I've seen around the net it's one of the most common
[19:21] <Nafallo> written in erlang ;-)
[19:22] <LaserJock> looks like we have jabberd and ejabberd :-)
[19:22] <ScottK> LaserJock: I think that's the first question.  If we have another one and we should have ejabberd instead, then I suspect it's a relatively easy sell.
[19:22]  * LaserJock suddenly thinks he knows what the "e" might be fore
[19:22] <ScottK> OK.  Well I guess then the question is can ejabberd replace jabberd ...
[19:22] <ScottK> ;-)
[19:22] <LaserJock> ScottK: what do you mean?
[19:23] <LaserJock> why does it need to replace it?
[19:23] <Nafallo> LaserJock: don't forget jabberd2 ;-)
[19:23] <ScottK> So you aren't increasing the amount of stuff in Main.
[19:23] <LaserJock> ScottK: there isn't a jabber server in Main
[19:23] <afflux> what's jabberd? Can find only jabber and jabberd2, both in universe
[19:23] <ScottK> OK.  I misunderstood then.
[19:24] <BUGabundo1> I use ejabberd
[19:24] <BUGabundo1> its quite good!
[19:24] <hwilde> can someone explain how ext4 achieves the promised performance increases?
[19:24] <BUGabundo1> much easier to setup then jabberd2
[19:24] <Nafallo> ScottK: well, ejabberd would drag erlang along with it. not sure what kees have to say about that one ;-)
[19:24] <afflux> I hate erlang, so I use jabberd2 :P
[19:24] <LaserJock> afflux: jabberd is the daemon of jabber
[19:24] <afflux> LaserJock: ah, thought you were talking about pkgnames
[19:24] <BUGabundo1> afflux: I don't care what's under the wood. I just need it to work
[19:24] <ScottK> Dunno.
[19:25] <afflux> BUGabundo1: mine didn't, so I tried debugging, and that somehow just didn't work out.
[19:25] <BUGabundo1> its working right now!
[19:25] <BUGabundo1> from hardy up to jaunty!
[19:25] <Nafallo> sql-backends for ejabberd seems to require unpackaged modules at the moment :-P
[19:25] <BUGabundo1> I have one account f XMPP on my own laptop!
[19:25] <Nafallo> I'm going to switch towards jabberd2 fwiw
[19:26] <BUGabundo1> afflux: I said it *is* easier. I didn't say it was easy! took me 2 days to get it running as I wanted
[19:26] <LaserJock> well, I don't know that we *have* to have ejabberd, it's just sort of the defacto one I think
[19:26] <ScottK> LaserJock: It might be useful to discuss with Server Team.
[19:26] <afflux> yep, it's quite common afaik
[19:27] <BUGabundo1> there goes pidgin. but I'm back
[19:27] <BUGabundo1> what did I loose?
[19:28] <LaserJock> ScottK: in particular I'm not sure about bringing grep-dctrl into Main and lksctp-tools seems interesting as well
[19:34] <LaserJock> so jabberd2 would pull in udns, gsasl, and libntlm
[19:49] <kees> Nafallo: I don't have time to learn erlang at the moment.  ;)
[19:50] <LaserJock> anybody up for some erlang?! :-)
[19:52] <calc> is there a way to search for private bugs on a package that you can see?
[19:52]  * calc wants to make sure that all the ones that should be public are marked that way already
[19:53] <Nafallo> kees: that's about what I hoped you'd say :-)
[19:54] <kees> calc: beg bdmurray to run magic queues for you?
[19:54] <calc> kees: heh ok
[19:55] <calc> i can just look through the list, i was talking about bugs that are marked private that I can see that shouldn't be marked that way
[19:55] <calc> i didn't know if there was some way to search for them via launchpad search page
[20:00] <superm1> can someone with appropriate rights let through mdomsch's post to ubuntu-devel ML?
[20:23] <slytherin> does anyone know why has launchpad eaten squid-common in jaunty? squid is not upgradable (from intrepid version) in current state.
[20:24] <Mithrandir> squid-common | 2.7.STABLE3-1ubuntu2 |        jaunty | all
[20:24] <Mithrandir> it should be there.
[20:24] <Mithrandir> hm, same version as intrepid.  Sure it's not just no longer built?
[20:25] <Mithrandir> slytherin: ah, it FTBFS on i386
[20:27] <slytherin> Mithrandir: I am not using i386, I am on powerpc. If you see launchpad page there is no squid-common binary, only squid and squid-cgi. But the build log for powerpc shows all binaries were built.
[20:27] <TheMuso> slytherin: i386 builds arch all packages.
[20:27] <Mithrandir> slytherin: -common is built on i386, and it's arch: all
[20:28] <slytherin> ahh, didn't pay attention to that. my fault.
[20:28] <Mithrandir> search for "Error 1" in http://launchpadlibrarian.net/21134518/buildlog_ubuntu-jaunty-i386.squid_2.7.STABLE3-2ubuntu1_FAILEDTOBUILD.txt.gz
[21:18] <sconklin> bryce: ping
[21:18] <bryce> sconklin: yes?
[21:19] <bryce> sconklin: in general, it is better to just ask your question rather than pinging, since then you get your response sooner (and it interrupts the pingee only one time)
[21:19] <sconklin> ok right. I'll ask it here again then.
[21:20] <bryce> actually if it's X, come on in to #ubuntu-x
[21:20] <bryce> then if I don't know, maybe one of the other guys there can chime in
[21:22] <sconklin> I can't reproduce it now. It happened twice in a row, now won't fail
[21:22] <bryce> mm
[21:22] <sconklin> sorry for the fire drill
[21:22] <bryce> sometimes those can be intermittent issues, you'll probably see it again
[21:23] <bryce> I can give you a bit more advice if I at least know the driver and/or gfx chipset
[21:23] <sconklin> once it's installed I'll get that and save it, and next time I'll just file a bug and save all the chatter
[21:23] <bryce> okay cool
[21:23] <sconklin> thanks!
[21:24] <bryce> fwiw, for this class of problem there are registry dumping tools (at least, for -intel and -ati) which can be useful for troubleshooting
[21:24] <bryce> also, if you have a digital camera, these kind of issues do well to be photographed
[21:25] <bryce> the upstream guys can recognize different kinds of bugs based on the style of corruption seen on the screen sometimes
[21:25] <bryce> heya Rocket2DMn
[21:25] <Rocket2DMn> hey bryce
[21:29] <bryce> sconklin: btw also check your /var/log/Xorg.0.log.old after rebooting for errors, and/or look in /var/log/gdm/ if the file from the previous boot contains any errors.
[21:29] <sconklin> bryce: this was during an install from cd
[21:29] <bryce> running ubuntu-bug will automatically capture most of this stuff
[21:30] <bryce> ah yes rebooting from that won't help :-)
[21:31] <sconklin> I realized that (I think) both times it failed it had been powered down, but warm started the times it succeeded. I'll have more chances to test again during the next few days
[21:31] <Rocket2DMn> bryce, ive been pretty busy recently and will be for a bit, but im still keeping my eye out for X bugs
[21:33] <bryce> Rocket2DMn: cool.  I got inspired a bit after our last chat and went through all the fully triaged segfaults, and fixed several of them :-)
[21:34] <bryce> sconklin: ah that's a good observation.  It's not unusual for these corruption issues to be correlated to hibernate or suspend, so a correlation with warm-vs-cold boot wouldn't surprise me
[21:35] <bryce> sconklin: DRI being enabled vs. disabled tends to also correlate to some of these
[21:35] <bryce> so that's worth testing too
[21:35] <sconklin> bryce: ok, thanks
[21:36] <Rocket2DMn> bryce, sweet, progress!
[21:45] <calc> ok the build worked so i will be uploading new OOo now
[21:46] <slangasek> calc: ok, thanks
[21:49] <slangasek> calc: btw, for the help stuff (post-A3), what do you think of the possibility of using the bundled lucene, and then help searching is covered by the "for the full suite, you need openoffice.org metapackage and java" warning?
[21:53] <cjwatson> calc: private-ness is apparently not something you can search on (bug 66206) but you could do it, albeit more slowly, with the Launchpad API
[21:56] <cjwatson> superm1: err, while I've approved it, it's totally inapplicable to Ubuntu - we don't use that man implementation
[21:56] <cjwatson> I'll follow up on the list
[21:58] <superm1> cjwatson, okay, i didn't see the contents of it yet myself.  mdomsch wasn't on the list and just asked if i could ping someone about letting it through
[22:06] <calc> cjwatson: ok thanks, if i notice any while going through my bugs i will just work on them as i see them
[22:07] <calc> slangasek: hmm yea that would probably work out ok, i can make that change before i upload if you want
[22:08] <calc> slangasek: i was cleaning the tree and was just about to upload now
[22:09] <bryce> superm1: btw when you get a chance could you doublecheck what I've written for -nvidia status on https://wiki.ubuntu.com/X/Drivers ?
[22:10] <slangasek> calc: no need to change that before this upload, I don't want to wait on OOo-l10n anyway
[22:10] <calc> ok np
[22:11] <RAOF> Hm.  nouveau is still a bit wrong there.
[22:12] <RAOF> nouveau should support everything the nvidia-glx-* supports, barring possibly really new cards.
[22:12] <RAOF> Also, the kernel modules are still in NEW :)
[22:14] <maxb> "nvidia-glx-177 (180.22 - Needs IgnoreABI)" <-- copy/pasto
[22:15]  * RAOF waits for bryce to finish updating that wiki.
[22:16] <maxb> About the vdpau stuff... what happens to the package naming when the next major version comes out?
[22:16] <calc> who do i talk to about an 8.04.2 upload to fix my remaining targeted bugs?
[22:16] <maxb> Perhaps they need to be providing/conflicting a common metapackage?
[22:16] <calc> to verify its ok to do the upload ;-)
[22:18] <bryce> RAOF: ok done, go ahead and edit if you'd like, I can wait :-)
[22:19] <bryce> maxb: good catch, that should be 177.82
[22:20] <bryce> maxb: there is a separate libvdpau-glx-180 package; is that what you mean?
[22:21] <maxb> The thing is, that the files contained by the libvdpau  / libvdpau-dev packages are not named in version specific (or even nvidia-specific) ways, so won't some conflicts be needed somewhere?
[22:22] <bryce> maxb: I don't think they conflict with anything at this point, but would imagine the packaging can be updated if/when that occurs
[22:22] <bryce> maxb: but perhaps I don't understand...  superm1 can speak more definitively on this since he set it up
[22:24] <RAOF> maxb: You're thinking of incompatible ABI changes, right?  sonames and ABI and symbols, oh my!
[22:25] <maxb> Not specifically - I'm just thinking of how things can be arranged such that future versions don't have to list all the previous versions explicitly
[22:25] <RAOF> Hm.  I should mention that nouveau will only be installable once nouveau-kernel-source gets out of NEW.
[22:25] <RAOF> Why would they?  They'd just have a higher version string?
[22:26] <maxb> But, the major number is embedded in the package name: nvidia-180-libvdpau
[22:27] <maxb> For example, the nvidia-glx-NNN all provide and conflict nvidia-glx (though they then do explicitly list all the other versions in Replaces, so that doesn't completely allow them to be ignorant of what other versions are out there)
[22:27] <RAOF> Oh, right.  Yeah.
[22:28] <RAOF> I see what you mean now.  I was set off track by the mention of libvdpau / libvdpau dev.
[22:28] <maxb> Sorry, I was prematurely abbreviating :-)
[22:38] <directhex> :o
[22:39] <directhex> you know what they say about premature optimization
[22:57] <calc> slangasek: done uploading now :)
[22:57] <slangasek> cheers
[23:18] <m3ga> hi all, does anyone know anything about how the ocaml and haskell tools and libraries are snapshotted from debian to go into an ubuntu release?
[23:19] <soren> Hm... My Xorg is eating up all of the one core on my laptop. I imagein this is due to some application flooding it with updates or whatnot. How can I see which application  is causing this?
[23:30] <laprice> in trying to build a package, all of the files named *.ex are ignored right?
[23:30] <laprice> I just need to create the plain versions and that will
[23:31] <laprice> cause them to be built into the final package?
[23:59] <ScottK> m3ga: I know 'not usually in an order that leads them to work', but not much more than that.