[00:09] <TheMuso> crimsun: Right.
[00:14] <bluefoxicy> for fucking fuck's sake >_<
[00:14] <bluefoxicy> there should NOT
[00:14] <bluefoxicy> SHOULD NOT
[00:14] <bluefoxicy> be lock contention in production kernel code >:O
[00:15] <bluefoxicy> this stupid argh
[00:15] <bluefoxicy> there is NO WAY to debug this
[00:15] <bluefoxicy> the damn
[00:15] <bluefoxicy> it
[00:15] <bluefoxicy> damnit
[00:15] <bluefoxicy> it fucking HANGS
[00:15] <bluefoxicy> and sometimes, SOMETIMES comes back
[00:15] <bluefoxicy> sometimes the WHOLE DAMN SYSTEM locks up eventually
[00:15] <bluefoxicy> things start hanging when they try to access disk
[00:15] <bluefoxicy> network activity?  Sure.
[00:15] <bluefoxicy> write to a log file?  Hold on *application window becomes a white blob*
[00:16] <bluefoxicy> oops, X wants to touch the disk
[00:16] <bluefoxicy> nevermind, we're just going to go fuck ourselves now so please hit reset
[00:16] <bluefoxicy> oh, and if you use magic keys, you can still umount and sync disks and not have to fsck the next boot
[00:16] <bluefoxicy> so what the hell
[00:17] <bluefoxicy> apparently the whole kernel isn't locking up, but the application disk scheduler is hosed
[00:17] <bluefoxicy> oddly, setting elevator=as makes it less likely (on the order of every several weeks instead of every few hours or maybe 5 minutes after boot), but it STILL happens
[00:18] <bluefoxicy> oh and since NO APPLICATION can write to disk, or read from disk (I can't run programs), I can't pull ANY debugging information
[00:18] <bluefoxicy> AT ALL
[00:18] <bluefoxicy> wtf is the next release
[00:19] <bluefoxicy> maybe a shiny new kernel will have a distinct lack of fucktarded stupidity
[00:20] <TheMuso> !ohmy | bluefoxicy
[03:10] <NCommander> sebner, vtk built on armel
[03:18] <ScottK> \o/
[03:18] <ScottK> That'll help with NBS.
[03:42] <ScottK> EtienneG, soren, and mdz: Just accepted Eucalyptus.  It should be in the archive after the next publisher run.
[03:44] <L33ckma> hi there
[03:44] <L33ckma> i'm searching for ubuntu kernel 2.6.28-11-generic with debugging symbol
[03:45] <L33ckma> any help?
[04:01] <NCommander> L33ckma, install the kernel debug package (the name escapes me, but there should be a kernel-image-2.6.28-11-dbg or something like that)
[04:03] <L33ckma> NCommander, from what repository?
[04:03] <NCommander> L33ckma, main
[04:09] <L33ckma> hmm
[04:10] <L33ckma> NCommander, i didnt find any kernel-* similar to dbg
[04:11] <L33ckma> but in ddebs I found linux-image-debug-2.6.28-15-generic_2.6.28-15.51_i386.ddeb
[04:11] <L33ckma> at http://ddebs.ubuntu.com/pool/main/l/linux/
[04:13] <L33ckma> which doesn't help me so much
[04:28] <mdz> ScottK: thanks!
[06:24] <dholbach> good morning
[06:24] <dholbach> who can help me debug a not-booting system?
[06:36] <dholbach> the last thing when I boot on the other machine is "ACPI: I/O resource nForce2_smbus [0x1c40-0x1c7f] conflicts with ACPI region SM01 ............. Error probing SMB2"
[06:36] <dholbach> but I get the feeling that that message has nothing to do with the hang on the machine I'm seeing
[06:38] <dholbach> if I boot with bin=/bin/bash the last thing I see is "bash: cannot set terminal process group (-1): Inappropriate iotcl for device" "bash: no job control in this shell"
[06:38] <dholbach> this is the latest karmic with the ubuntu-boot ppa enabled
[06:40] <dholbach> Keybuk: ^ any idea what I could do?
[06:50] <liw> dholbach, did you already boot from a livecd and run fsck on all filesystems, and smartctl on all hard disks?
[06:50] <dholbach> liw: I'll try that now :)
[06:52]  * dholbach does some sponsoring in the meantime
[06:54]  * TheMuso notes that the latest daily livecd reboots itself for some reason, i.e it doesn't get to the desktop, the splash starts showing activity, then things go in reverse, and it asks to press enter after ejecting the disk.
[06:55] <dholbach> TheMuso: oh wow - I'll alpha5 then
[06:57] <liw> TheMuso, might be #429003
[07:09] <TheMuso> liw: Doesn't make sense on a live CD where the nv driver gets used.
[07:10] <soren> ScottK: Ta very much.
[07:11] <ttx> Good morning
[07:21] <NCommander> Can anyone explain to me how the tasks are updated?
[07:22] <dholbach> NCommander: what are you referring to?
[07:23] <NCommander> dholbach, the tasks used by livecd-rootfs and friends; basically the set of packages you get when you do: apt-get install minimal^
[07:24] <dholbach> ah ok
[07:31] <TheMuso> NCommander: afaik the seeds are responsible for that, at least for tasks on disks.
[07:32] <NCommander> TheMuso, I'm just figuring out how long it takes before they are updated from the seed changes
[07:35] <TheMuso> NCommander: As for the archive, I don't know what happens there, probably something in launchpad.
[07:35] <AnAnt_> Hello, debian made a new release of mutt that Recommend default-mta instead of exim4, which means, that it no more needs merge, but sync
[07:40] <soren> ttx: Dude! Welcome back!
[07:41] <ttx> soren: Dude!
[07:41] <pitti> Good morning
[07:41] <pitti> cody-somerville: what is a DCD file?
[07:41] <ttx> soren: how is it going ?
[07:41] <pitti> lool: I saw, thanks
[07:41] <ttx> pitti: good morning !
[07:41] <soren> ttx: Not too bad, not too bad. Good holidays?
[07:41] <pitti> ogra_: sabayon> he mailed me, and said that it's in much better shape, so we'll keep it
[07:41] <pitti> hey ttx
[07:42] <ttx> soren: first I recovered from jetlag, then spent a few days working on the house, finally I travelled for a wedding party. Now I'm back in recovery mode :)
[07:42] <cody-somerville> pitti, Distribution channel descriptor
[07:42] <soren> ttx: Just in time for the Alpha6 rush. Yay.
[07:43] <ttx> soren: yes, best timing ever :)
[07:43] <pitti> cody-somerville: hm, and what is that?
[07:47] <cody-somerville> pitti, https://wiki.ubuntu.com/FoundationsTeam/Specs/OemTrackingId
[07:52] <AnAnt> so, should a sync request be filed for mutt ?
[07:52] <AnAnt> or should that wait till karmic+1 ?
[07:53] <pitti> cody-somerville: hm, first time I hear about that TBH; I don't have that file either, do you?
[07:53] <pitti> cody-somerville: but easy enough to include into Apport
[07:54] <lool> pitti: np
[07:54] <cody-somerville> pitti, I think OEM team is currently the only ones with the spec implemented.
[07:56] <dholbach> liw: the disk and partitions seem to be fine :-/
[07:56] <pitti> cody-somerville: pushed to bzr, thanks
[07:57] <dholbach> if anybody has some more ideas how I could debug my not-booting system, I'd appreciate it
[07:57] <cody-somerville> pitti, I'm curious as to what prompted you to ask me about DCD files.
[07:58] <pitti> cody-somerville| [19:27:10] pitti, Does apport include the
[07:58] <pitti> [...]
[07:58] <pitti> cody-somerville: you asked me over the weekend
[07:58] <cody-somerville> odd, I don't remember doing that. lol
[08:02] <pitti> cody-somerville: my IRC proxy never forgets!!11!
[08:13] <pitti> StevenK: oh, I just stumbled over bug 427709;  is ubuntu-mir supposed to be subscribed there, or is the report not finished yet?
[08:30] <tseliot> doko: upgrading libc6 from 2.10.1-0ubuntu8 to 2.10.1-0ubuntu11 makes my X.org segfault with nvidia and I can't open applications if I enter the gnome-session (with the nv driver). Is it a known problem?
[08:31] <liw> tseliot, might be #429003 ?
[08:32] <tseliot> let me check
[08:33] <tseliot> liw: aah, it was filed against elibc. Now I see why I couldn't find it
[08:42] <StevenK> pitti: I thought lool was handling it, but I'm happy to subscribe ubuntu-mir
[08:42] <pitti> StevenK: last time I started to review such a bug, the reporter told me that "it wasn't ready yet", so I better ask before starting to work on it :)
[08:43] <StevenK> I thought I saw lool attach an MIR to it
[08:43] <StevenK> Hm, no, I'm on crack.
[08:44] <AnAnt> seriously ?
[08:44] <pitti> no, he's just on Vegemite, which is by and large the same
[08:45] <StevenK> Hmph
[08:45] <AnAnt> ok, so should I file a sync request for mutt ?
[08:48] <pitti> AnAnt: Debian took the default-mta change?
[08:48] <AnAnt> yeah
[08:51] <lool> pitti: Report is not complete
[08:51] <lool> pitti: I took responsability to drive it forward and poked Keybuk on Friday hoping he would handle it but I guess he's busy with boot stuff
[08:51] <doko> tseliot: gah ... not owning a nvidia card
[08:52] <lool> StevenK: Happy if you pick it up though
[09:00] <tseliot> doko: even when I used the open source driver I couldn't launch nautilus. Is there anything I can do to help?
[09:03] <tseliot> slangasek: are these paragraphs ok for the release notes? https://wiki.ubuntu.com/X/Config/DontZap#Using GNOME https://wiki.ubuntu.com/X/Config/DontZap#Using KDE or do you want me to rewrite them?
[09:04] <doko> tseliot: please could you install the packages from https://launchpad.net/~doko/+archive/toolchain and see if these work? just one more data point
[09:04] <tseliot> doko: sure
[09:05] <didrocks> slangasek: hey o/ Here is the MIR we talked last week: bug #428793
[09:32] <tseliot> doko: I can't reproduce the problem with libc6 from the toolchain. Does this help?
[09:33] <doko> tseliot: one more data point, let me build some test packages for you to test
[09:34] <tseliot> doko: ok
[09:37] <doko> tseliot: i386 or amd64?
[09:38] <sebner> tseliot: ah I just wanted to ask you if the libc upgrade br0ke the nvidia driver ;D
[09:39] <tseliot> doko: i386
[10:25] <apw> Keybuk, if an mmc card is being detected by the kernel and udev is makeing the mmcblk0p1 devices etc, but then gnome isn't noticing it and mounting and offering it in a window ... what bit is broke... ie where should i file a bug?
[10:32] <AnAnt> LP 429237
[10:41] <zyga-work> mvo: hello
[10:43] <mvo> hey zyga-work! I saw your changes :)
[10:44] <mvo> zyga-work: before I can merge, you would have to sign the canonical-contribuors agreement, see http://www.canonical.com/contributors
[10:56] <zyga-work> mvo: gladly
[10:58] <zyga-work> mvo: I'd like to talk to you about two more things: api for search is crappy ATM, I'd like to refine it to be usable without keeping xapian around
[10:58] <zyga-work> mvo: second thing: transaction API
[10:58] <zyga-work> mvo: I didn't do it (I only had one night hacking time) but I plan to today
[10:59] <zyga-work> mvo: I also like talk about merging, I noticed there are many branches and I fear I could diverge too much fast
[10:59] <mvo> zyga-work: ok, I'm about to head for lunch, but I'm happy to talk about it aftewards :)
[11:00] <zyga-work> mvo: great, please ping me then
[11:00] <mvo> ok
[11:00] <mvo> will do
[11:00] <zyga-work> I'll setup notification (I hope it works correctly)
[11:00] <mvo> :)
[11:03] <soren> Err... Where did removals.txt go?
[11:04] <james_w> soren: Debian's?
[11:04] <soren> james_w: No, ours.
[11:05] <cjwatson> replaced by Launchpad
[11:05] <soren> james_w: http://people.ubuntu.com/~ubuntu-archive/removals.txt used to be the URL, no?
[11:05] <james_w> LP knows why individual package was removed
[11:05] <soren> Oh.
[11:05] <james_w> if you want the list you have to do some work
[11:05] <soren> Ngh...
[11:06] <soren> Ok, thanks.
[11:06] <cjwatson> bug 159585
[11:06] <james_w> what are you looking for?
[11:08] <soren> james_w: Not sure. I'm trying to piece some stuff together.
[11:23] <doko> tseliot: deb http://people.canonical.com/~doko/tmp/eglibc/test1 ./
[11:26] <tseliot> doko: ok, let me try the new packages
[11:37] <tseliot> doko: I can reproduce the problem with revision 12, therefore I had to switch back to revision 9
[11:38] <doko> tseliot: ok, thanks, building another one
[11:38] <tseliot> ok
[11:42] <cjwatson> gah, somebody broke devscripts to always use the most recent thing in debian/changelog, which is wrong for Ubuntu
[11:42] <cjwatson> just because it was last uploaded to jaunty doesn't mean that's the right thing to do now
[11:48] <Laney> which part of devscripts?
[11:52] <cjwatson> dch
[11:52] <cjwatson> bug 429288
[11:54] <asac> YokoZar: thanks for ia32libs update. you think you could check the glib patch i prepared?
[11:55] <YokoZar> asac: I'll test by adding your glib to ppa then adding a hook for it into a new ia32-libs in the same ppa
[11:56] <YokoZar> It'll take me a while to do the uploads though, ia32-libs doesn't like to get uploaded from my house so I need to borrow the a friend's internet
[12:02] <asac> YokoZar: if you could just check that it works i would upload the fix to karmic first
[12:02] <asac> so no hurry ;)
[12:02] <asac> do we want a new bug?
[12:03] <YokoZar> nah I'll just reopen the current one
[12:04] <asac> ok cool
[12:04] <asac> thx
[12:17] <soren> cjwatson: I just tried installing eucalyptus-cc with dpkg (it was not previously installed). I was missing some dependencies, so I went to fix that with "apt-get -f install". It fetched all the packages, installed, and configured. I was never asked about the name of my cluster.
[12:18] <soren> cjwatson: I have this in my /var/log/dpkg.log: 2009-09-14 12:48:10 configure eucalyptus-cc 1.6~bzr672-0ubuntu3 1.6~bzr672-0ubuntu3
[12:18] <soren> cjwatson: That suggests that dpkg considered it an upgrade from the same version, but the check in .config checks for -z "$2".
[12:19] <soren> cjwatson: I'm not sure if dpkg is wrong, your check is wrong, or if everything is intended. I'm almost sure it's not the latter.
[12:21] <cjwatson> soren: are you sure that it wasn't removed-but-not-purged?
[12:22] <soren> cjwatson: /me checks scrollback
[12:22] <cjwatson> the check is standard form for a first-install-only operation, I think ...
[12:22] <soren> cjwatson: dpkg -l euca'*' did not even list it.
[12:22] <soren> cjwatson: I agree.
[12:22] <cjwatson> dpkg.log should say; can I see the whole thing?
[12:23] <soren> cjwatson: My entire dpkg.log? sure.
[12:24] <soren> cjwatson: Will "| grep eucalyptus-cc" do?
[12:25] <cjwatson> yeah
[12:25] <soren> cjwatson: http://paste.ubuntu.com/270820/
[12:26] <soren> cjwatson: From 2009-09-14 13:13:55 onward is me trying to reproduce it.
[12:26] <soren> cjwatson: ...which I can.t
[12:26] <soren> can't, even.
[12:27] <soren> cjwatson: I can't reproduce it now. Very, very annoying.
[12:28] <cjwatson> soren: mm. I don't see any evidence of what might have been wrong. :(
[12:28] <cjwatson> but as long as it works on initial installation, it's ok, right?
[12:29] <soren> Well, that's the thing. It was a fresh install (of that package). It only ended up being a two-stage thing due to a missing dependency (and my using dpkg since I had the deb right there).
[12:29] <soren> But seeing as I can't reproduce it, it's pointless to try to hunt it down.
[12:32] <soren> Bah. Maybe I just got confused. It /does/ happen occasionally.
[13:06] <lool> cjwatson: Hey; we have an issue with the UNR seed / task: abrowser-3.5 has Task: ubuntu-netbook-remix; I downgraded the webfav Depends: abrowser-3.0 | abrowser-3.5 | firefox-3.0 | firefox-3.5 | iceweasel to a recommends a couple of publisher cycles ago
[13:07] <lool> cjwatson: firefox is seeded before webfav in the unr.karmic/netbook-remix seed, and then webfav with a Recommends on abrowser*|firefox*
[13:07] <lool> cjwatson: So I wondered whether there was something clean we could do or whether we should simply seed firefox-3.5 as a workaround?
[13:08] <cjwatson> lool: any reason why webfav's recommends alternatives aren't ordered by desirability?
[13:09] <lool> cjwatson: No reason but they are autogenerated
[13:09] <lool> From xpi:Depends
[13:09] <cjwatson> failing that, seeding firefox-3.5 explicitly is ok
[13:09] <lool> Ok that's what I guessed as well and I dont think it's clean to change the xpi:Depends generation to have the concept of preferred package since it's used in all extensions
[13:10] <lool> asac: ^ but feel free to object
[13:10] <doko> tseliot: deb http://people.canonical.com/~doko/tmp/eglibc/test2 ./
[13:12] <lool> cjwatson: Hmm this is in the seed used for the metapackage; we didn't have germinate workarounds in metas so far and I understand it means that firefox-3.5 will be listed in the dependencies; too bad  :-/
[13:14] <cjwatson> lool: right, but unless firefox-3.5 is listed in the metapackage dependencies, I think there's some chance that apt will do the wrong thing
[13:14] <cjwatson> so you do actually want that to match up
[13:14] <lool> cjwatson: apt-get install ubuntu-netbook-remix worked and apt-get install ubuntu-netbook-remix^ didn't
[13:14] <lool> But yeah
[13:14] <lool> I agree
[13:14] <lool> cjwatson: thanks for your help
[13:15] <soren> How can I dynamically provide a list of Choices for a debconf template?
[13:17] <soren> Ah, db_subst!
[13:17] <soren> Got it.
[13:26] <cjwatson> anyone happen to know offhand a quick way of detecting (unmounted) luks partitions? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546546
[13:26] <hyperair> hmm? i wasn't aware that it hung while configuring
[13:27] <hyperair> cjwatson: go through /proc/partitions and run cryptsetup luksDump on all of them
[13:27] <cjwatson> apparently when os-prober tries to mount them, that produces a password prompt
[13:28] <cjwatson> you might not get it if the partitions were already mounted somewhere
[13:28] <hyperair> i see
[13:29] <hyperair> my luks partition holds a LVM PV
[13:29] <cjwatson> actually, do you happen to know what 'blkid -o value -s TYPE /dev/whatever' says for a luks partition?
[13:29] <soren> cjwatson: I can check.
[13:29] <cjwatson> since we're already running that
[13:29] <hyperair> cjwatson: nothing.
[13:29] <cjwatson> boo.
[13:29] <hyperair> mmhmm
[13:30] <hyperair> perhaps we should fix blkid then?
[13:30] <soren> Err.. not so?
[13:30] <hyperair> soren: what does it say for you?
[13:30] <soren> Mine says: crypto_LUKS
[13:31] <hyperair> exits with error 2
[13:31] <cjwatson> mm, that is indeed what current code in util-linux would suggest
[13:31] <cjwatson> libs/blkid/src/probers/luks.c
[13:31] <soren> hyperair: cryptsetup luksUUID /same/path/to/the/device?
[13:31] <hyperair> hmm strace says that blkid looks in /dev/.blkid.tab
[13:31] <soren> Yes, it caches the info.
[13:32] <soren> -p overrides the cache
[13:32] <hyperair> soren: d201ccfd-6d90-4663-a426-fc14896bdd14
[13:32] <soren> bypasses the cache, I mean.
[13:32] <soren> What about "blkid -o value -s TYPE -p /dev/whatever"?
[13:32] <soren> (i.e. add the "-p" option)
[13:32] <soren> Does that make a difference?
[13:33] <cjwatson> soren's output implies http://paste.ubuntu.com/270858/, which is nice and concise
[13:33] <hyperair> soren: /dev/sda2: ambivalent result (probably more filesystems on the device)
[13:34] <soren> hyperair: How'd you end up with that? :)
[13:34] <hyperair> soren: LVM-on-LUKS
[13:34] <soren> hyperair: Same here.
[13:34] <hyperair> well that's strange
[13:34] <soren> Oh, hang on. That's not true. Not on this box.
[13:34] <soren> I have another one like that, though.
[13:34]  * soren checks there.
[13:35] <soren> /dev/sdb1: UUID="8c555e9d-15fc-4d0c-bc18-267fd2573fe8" TYPE="crypto_LUKS"
[13:35] <soren> That's a LUKS partition that holds an LVM PV.
[13:35] <hyperair> strange.
[13:35] <soren> I wonder what else gets detected on yours.
[13:36] <cjwatson> it may differ depending on whether the LUKS partition has been cryptsetup'ed or not?
[13:36] <cjwatson> I only really care about the ones that haven't been
[13:36] <soren> Keybuk: How to make blkid output all the stuff it detected?
[13:36] <soren> cjwatson: This one has.
[13:36] <soren> cjwatson: and vgchange -ay'ed and mounted, etc.
[13:37] <soren> Keybuk: Instead of just: 12:33:19 < hyperair> soren: /dev/sda2: ambivalent result (probably more filesystems on the device)
[13:37] <hyperair> this one is a root-on-LVM-on-cryptsetup
[13:37] <hyperair> /dev/sda1 is /boot, ext4.
[13:37] <cjwatson> I'm going to go ahead and use the crypto_LUKS check for now, I think
[13:38] <hyperair> cjwatson: could you use cryptsetup luksDump?
[13:38] <soren> hyperair: Mine wasn't cryptsetup'ed from initramfs.
[13:38] <cjwatson> I'd rather not, there are performance concerns here
[13:38] <soren> maybe that makes a difference.
[13:38] <cjwatson> the quicker the check the better
[13:38] <hyperair> cjwatson: is calling cryptsetup that resource hungrry?
[13:38] <cjwatson> people already complain about os-prober being too slow
[13:38] <hyperair> hmm
[13:38] <cjwatson> and calling it on every partition ...
[13:39] <hyperair> i see
[13:39] <hyperair> that's a pain..
[13:39] <cjwatson> admittedly it is pretty quick
[13:39] <cjwatson> (cryptsetup)
[13:39] <soren> Nice:
[13:39] <soren> real	0m0.008s
[13:39] <soren> user	0m0.000s
[13:39] <soren> sys	0m0.010s
[13:39] <cjwatson> maybe I could try that after the existing checks
[13:40] <soren> It spent more time in the kernel than passed in real time.
[13:40] <cjwatson> does luksDump reliably exit 0 for a luks partition?
[13:41] <hyperair> $ sudo blkid -p -u nofilesystem /dev/sda2
[13:41] <hyperair> /dev/sda2: UUID="d201ccfd-6d90-4663-a426-fc14896bdd14" VERSION="256" TYPE="crypto_LUKS" USAGE="crypto"
[13:41] <hyperair> perhaps luksUUID might be faster
[13:42] <cjwatson> I guess I'm OK with using luksDump/luksUUID since it does seem to be quick
[13:42] <hyperair> mmhmm
[13:42] <hyperair> imo it'd be faster than doing a mount
[13:42] <hyperair> very much faster
[13:43] <cjwatson> http://paste.ubuntu.com/270871/
[13:43] <cjwatson> I'll go with that, then. Thanks!
[13:43] <rgreening> pitti: any luck/progress on bug 427358? :)
[13:43] <hyperair> hyperair@ipwn:~$ sudo blkid -p -u nocrypto /dev/sda2
[13:43] <hyperair> /dev/sda2: UUID="791218bf-ae9f-4330-bdd8-f9efce03a495" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem"
[13:43] <hyperair> soren: ^^
[13:44] <hyperair> soren: with nocrypto, it thinks it's ext3. why is that, i wonder? =\
[13:44] <hyperair> i have no more ext3 partitions
[13:44] <hyperair> only ext4
[13:45] <hyperair> hmm actually come to think of it..
[13:46] <soren> Ah, the plot thickens.
[13:46] <hyperair> before i switched /dev/sda2 to a luks partition, it was ext3, i think.
[13:46] <hyperair> is the ext3 superblock in front or behind?
[13:46] <hyperair> luks's is in front, at least
[13:46] <liw> ext[234] have copies of the superblock all over the filesystem
[13:46] <liw> often at every 8192 blocks
[13:47] <hyperair> heh
[13:47] <hyperair> okay, that means it's everywhere
[13:47] <liw> it's a bit! it's a byte! no, it's superblock!
[13:48] <hyperair> haha
[13:48] <hyperair> i guess if i pvmove things around i'd erase the old superblock =\
[13:49] <hyperair> unless it's sitting around in the middle of the cryptsetup superblock
[13:49] <asac> lool: yes thats ok i think
[13:51] <hyperair> cjwatson: blkid -u crypto or -u nofilesystem works.
[13:51] <cjwatson> I just went for cryptsetup in the end
[13:52] <hyperair> heheh
[13:57] <cody-somerville> pitti, speaking of apport, apport incorrectly detects the window manager and GTK theme. I'll file a bug for you.
[14:07] <loic-m> My Karmic fails at boot since a few hours updates, then next boot is an fsck issue (Superblock last time is in the future - ext4 fs), rinse and repeat - what errors logs should I look at to troubleshoot the issue?
[14:08] <loic-m> Is that it? > gdm-simple-slave[4684]: DEBUG(+): GdmSimpleSlave: server died with signal 11, (Erreur de segmentation)
[14:08] <ogra> sounds like your hwclock is broken somehow
[14:08] <ogra> *hwclock
[14:09] <cjwatson> loic-m: probably bug 427822
[14:09] <pitti> rgreening: sorry, I didn't work on this yet
[14:10] <pitti> cody-somerville: apport detects a theme?
[14:10] <cody-somerville> pitti, bug #429357
[14:10] <cody-somerville> pitti, bug #428969 for an example
[14:11] <loic-m> cjwatson: thanks. That wouldn't explain why it fails to boot at restart after an fsck though, would it?
[14:12] <cjwatson> why would it not?
[14:13] <pitti> cody-somerville: could you please make bug 428969 public?
[14:13] <loic-m> because there's no fsck pb afterwards, the boot seem normal but the screen blanks just before gdm should start (and no console access either)
[14:13] <cody-somerville> pitti, sure
[14:13] <cjwatson> loic-m: that I don't know
[14:13] <cjwatson> I imagine you have two separate bugs
[14:13] <loic-m> ok, thanks
[14:14] <james_w> could an archive-admin more knowledgeable than me please confirm my assessment of the spring packages that I just sent to ubuntu-archive@?
[14:15] <rgreening> pitti: any chance you could take a peek today? :) I'd really appreciate it :)
[14:15] <james_w> or refute it for that matter :-)
[14:16] <pitti> rgreening: I wouldn't hold my breath for it; figuring out the intltool changes and getting them upstream will take a while
[14:17] <pitti> rgreening: is there a tool you know of which extracts translatable strings from KDE .ui files?
[14:18] <cjwatson> soren: opinions on http://paste.ubuntu.com/270894/, re bug 425922?
[14:19] <jpds> Is compiz being removed for anyone else on Karmic? http://paste.ubuntu.com/270895/
[14:19] <rgreening> pitti: using a seperate Messahe.sh and calling extract-messages.sh in the update-po of the makefile, however, how to I ensure merging of the gtk generated po and the kde one? that's where I am stuck now...
[14:19] <ogra> hmm, yelp seems to have exploded on all arches
[14:19] <rgreening> Messages.sh ... ^
[14:19] <pitti> rgreening: msgcat doesn't work?
[14:20] <rgreening> pitti: I admit I only tried quickly, but I had no success...
[14:22] <jpds> mvo: Have seen this? http://paste.ubuntu.com/270895/
[14:22] <Riddell> pitti, rgreening: I just committed a way of extracting the KDE strings in usb-creator
[14:22] <rgreening> oh.. and merges with the gtk?
[14:23] <Riddell> rgreening: yes, you were calling msgcat wrong
[14:23] <rgreening> wheeee
[14:23] <rgreening> :)
[14:23] <cjwatson> compiz was in binary NEW until a couple of hours ago - wouldn't be something to do with that, plus an out-of-date mirror?
[14:23]  * rgreening gets so confused with translations.. 
[14:24] <free> hi folks, I'm looking for the LP bzr branch of the source package of "smart", it's not in lp:ubuntu/karmic/smart, maybe it hasn't been imported at all?
[14:24] <cjwatson> actually, no, just looks like nobody's uploaded libcompizconfig to match yet
[14:24] <cjwatson> free: in many cases there simply isn't a branch yet
[14:24] <jpds> cjwatson: I'm using gb.archive personally, and it looks like the last upload was 5 hours ago.
[14:24] <rgreening> Riddell: ty. have you tested also?
[14:24] <cjwatson> yeah, hence my next comment :)
[14:25] <free> cjwatson: I see
[14:25] <Riddell> rgreening: nope
[14:25] <rgreening> ha
[14:25] <Riddell> rgreening: but when you're as good as me you don't need to test right? :)
[14:25] <rgreening> oh my
[14:25] <free> cjwatson: so the import must be somehow triggered by hand? at least at first
[14:26] <cjwatson> free: I don't believe so, more likely to be either a bug in the importer or just that it's running behind - but james_w would know better
[14:26] <james_w> hi free
[14:26] <james_w> I'll have a look in a minute for you
[14:26] <free> hey james_w
[14:26] <free> james_w: thanks!
[14:27] <free> james_w: (in this specific case I'd need the branches from intrepid and jaunty, for an SRU)
[14:27] <dpm> hi mvo. We're having an Ubuntu Global Jam in October, and one of the activities locos will be involved in will be translation jams. I suggested some translations teams could focus on, and the DDTP were some of them. They are a good target, since I thought we could sync them to Debian once the jam is finished. I'm assuming this still works and that I could simply ask you to perform a sync when the time comes. Is that still the case? (I've just been talk
[14:27] <dpm> ing about this with sianis, who's now in the channel as well)
[14:27] <tseliot> pitti: any ideas as to why hal seems to ignore my fdi file? /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi   In particular this doesn't seem to work <match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" string="Inspiron 1011">
[14:31] <pitti> tseliot: did you check that info.capabilities has "input.touchpad" and input.x11_driver == 'synaptics'?
[14:33] <tseliot> pitti: yes, I did and it has both
[14:33] <pitti> cody-somerville: followed up
[14:33] <mvo> dpm: hey! ddtp sync is working, but debian asked me a while ago to not send the sync stuff back because there is a missing feature in the ddtp scripts in debian to avoid duplicated entries
[14:34] <mvo> dpm: I need to inquire grisu about it, my side is ready otherwise
[14:35] <tseliot> mvo: I can't get the size of the temporary file which dkms creates but you should make sure that there's enough space for /var/lib/dkms/$MODULE_NAME (whose size can range from ~3MB to ~49MB)
[14:35] <tseliot> mvo: but it can be even bigger
[14:36] <tseliot> pitti: is there some log I can look at to see what hal does?
[14:36] <mvo> tseliot: thanks - is there no way to say that it should not clean its build-dir? (I assume it does build in /tmp? I got a bugreport about that)
[14:37] <pitti> tseliot: you can start it in debug mode, see https://wiki.ubuntu.com/DebuggingHal
[14:37] <tseliot> mvo: it does that in  /var/lib/dkms/$MODULE/$VERSION/build e.g. /var/lib/dkms/nvidia/185.18.36/build
[14:37] <tseliot> pitti: nice, thanks
[14:39] <mvo> tseliot: thanks
[14:40] <tseliot> mvo: also, dkms will create a directory about the current kernel with the modules it builds (in /var/lib/dkms/$MODULE/$VERSION/$(uname -r) )
[14:41] <pitti> tseliot: so, admittedly I don't have an off-hand idea why it doesn't match
[14:41] <pitti> tseliot: the rule looks fine
[14:42] <pitti> james_w: hm, is "are requested" a "must" or a "should"? I think a "should" would be okay
[14:42] <pitti> james_w: also, the MD5 clause sounds more like a trademark restriction to me
[14:43] <pitti> james_w: but I'm not sure about this at all, I'm afraid
[14:43] <tseliot> pitti: ok thanks. This is weird as I'm sure it used to work (at least when I uploaded the synaptics driver)
[14:43] <james_w> pitti: it's in the middle of the license, which is always a risky area. I would read it as a "should", but I'm not sure what the legal reading would be
[14:47] <pitti> james_w: my feeling is that the "plz send patches" thing is okay, but I don't feel confident enough to judge the trademark issue
[14:51]  * YokoZar thinks its kind of late in the dev cycle for nautilus to be crashing...
[14:53] <soren> cjwatson: --register-sc doesn't look right.
[14:53] <dpm> mvo: thanks for the info. Do you think you could contact grisu before the jam to clear this out? It would be quite cool we could give a lot of translations back to Debian. Or perhaps is there any way the translations team can help?
[14:53] <dpm> sianis: ^
[14:54] <sebner> james_w: would a source package which got renamed in Debian (still same upstream sources) and synced over to ubuntu need a FFe?
[14:54] <cjwatson> soren: oh?
[14:54] <mvo> dpm: I will ping him and see what is the status - he is usually very busy unfortunately
[14:56] <soren> cjwatson: Sorry, my mistake.
[14:56] <dpm> mvo: thanks for that
[14:56] <mvo> dpm: I send him a IM now :)
[14:57] <ogra> mvo, compiz-fusion-plugins-extra not building and breaking the livefs builds is on your radar i assume ?
[14:57] <cjwatson> soren: can you follow up to RT#35130 with an answer to Paul's question?
[14:58] <mvo> ogra: is it in depwait still?
[14:58] <soren> cjwatson: /me looks
[14:58] <mvo> ogra: hm, bugger - I check it out
[14:58] <mvo> ogra: thanks
[14:58] <ogra> http://qa.ubuntuwire.com/ftbfs/ seems not
[14:58] <james_w> sebner: I don't think so, but check with the release team
[14:59] <soren> cjwatson: Oh, right. I will.
[14:59] <sebner> james_w: kk, thx
[15:01] <mvo> pitti: could the build-score for compiz-fusion-plugins-extra be pimped please? its really in depwait for compiz-fusion-plugins-main (but it thinks its ftbfs)
[15:03]  * pitti sobs at lazr.restfulclient.errors.HTTPError: HTTP Error 503: Service Unavailable
[15:04] <pitti> mvo: ^ hm, I get LP errors, too, when I rescore in the web UI, sorry
[15:05] <pitti> oddly enough it does work for some archies
[15:05] <seb128> use non edge?
[15:06] <pitti> doesn't help
[15:07] <seb128> ok, no luck for mvo ;-)
[15:09] <pitti> mvo: so, I rescored it on everything but i386 and amd64, those keep failing
[15:09] <pitti> I mean, rescoring fails
[15:10] <mvo> pitti: thanks for trying it :/ so we have to wait a bit longer I guess
[15:11] <pitti> mvo: hah, it worked now (don't ask me why)
[15:11] <zyga-work> mvo: about the contributor agreement, I piped the document thru samsung legal dept, I'll keep you updated but it should be accepted in a couple of days
[15:12] <mvo> zyga-work: cool, thanks
[15:12] <mvo> zyga-work: its a good one, I hope its uncontroversial
[15:12] <ScottK> pitti: Looks to me like no new builds have been started in quite some time (~an hour at least, I'd guess)
[15:12] <pitti> argh, again?
[15:12] <pitti> lamont: ^ help please
[15:13] <zyga-work> mvo: can we talk about the stuff I said earlier?
[15:14] <mvo> zyga-work: the search api, give me a sec, I look at the diff
[15:14] <zyga-work> mvo: cool, thanks
[15:14] <ArneGoetje> Hey guys! What would be a good language fallback setting for en_CA? Is en_US or en_GB preferred by Canadian users?
[15:15] <zyga-work> mvo: basically please give me some feedback on the changes I did
[15:17] <mvo> btw, has anyone seen a autotools releated failure like this: http://launchpadlibrarian.net/31687373/buildlog_ubuntu-karmic-i386.kexec-tools_20090000-2.0.0ubuntu12_FAILEDTOBUILD.txt.gz ? that used to work with the previous auto*
[15:21] <tseliot> pitti: it looks like the line about the Dell in the fdi works only if I comment out the one about the HP Mininote
[15:21] <superm1> pitti, in #ubuntu-motu we were trying to figure out the root cause of why image-size got pulled from the archive on 9-11. it caused some unnecessary churn with requiring to pull in a new source package, because it got renamed in debian and there were still rdepends on it that broke.  it looks like you had requested deletion according to https://edge.launchpad.net/ubuntu/+source/image-size/3.2-1/+publishinghistory .  was this an oversight th
[15:21] <superm1> at it got pulled with rdepends after the autosync phase was up, or is there possibly an error with a script?
[15:22] <sistpoty|work> mvo: while I haven't seen that yet, this somewow smells like a missing quote or bracket somewhere
[15:23] <free> james_w: had a chance to check for that LP bzr branch for the smart source package?
[15:23] <mvo> sistpoty|work: thanks, that is a good hint, my autofoo is weak unfortunately
[15:23] <zyga-work> mvo: if you can open the configure file in some editor it's easy to check, just seek to the place where it prints that stuff and check for stuff sistpoty|work mentioned
[15:23] <pitti> superm1: right, seems we need to sync libimage-size-perl source from Debian?
[15:23] <pitti> superm1: just an oversight
[15:24] <ScottK> pitti: I did it yesterday.
[15:24] <superm1> pitti, yeah, we did this over the weekend as it broke live cd builds
[15:24] <mvo> zyga-work: thanks, I check, but oyur branch first :)
[15:24] <ScottK> It's now more a question of doing an autopsy so it doesn't repeat.
[15:24] <pitti> ScottK: thanks
[15:24] <pitti> sorry for the trouble
[15:28] <zyga-work> mvo: I'd really like the api to be sensible because then we can experiment with the backend and have everything else use it
[15:29] <zyga-work> and besides: model got detached from the view :-)
[15:30] <mvo> zyga-work: about the interface, I like it so far, I think for ISearchQuery the from_partial_term is not strictly needed, from_text sounds like it is enough for now
[15:30] <mvo> zyga-work: yeah, the decoupling is a important step
[15:30] <zyga-work> mvo: yeah ISearchQuery sucks right now - it's just what I created based on the GUI
[15:30] <zyga-work> I think we should have something like;
[15:30] <zyga-work> ISearchQuery.from_text(text, flags=[])
[15:30]  * mvo nods
[15:31] <mvo> yeah, flags sounds like the right solution
[15:31] <zyga-work> and flags can have stuff like ISearchQuery.FLAG_APPLICATION FLAG_PACKAGE
[15:31] <mvo> ++
[15:31] <zyga-work> because the only use case of from_query_and_query is to create a query for applications and then a second query for the name of the application
[15:32] <zyga-work> that is just low level  - I realized that on the following day (finished coding in the morning)
[15:32] <zyga-work> I really like xapian but I don't feel it's good to expose full xapian API in the interface
[15:32] <mvo> zyga-work: we will also need "get_applications_for_package()" in the store
[15:32] <mvo> zyga-work: xapian> agreed
[15:32] <zyga-work> if we ever switch to packagekit or some other infrastructure it will be a pain
[15:33] <zyga-work> mvo: IApplication?
[15:33] <zyga-work> mvo: right now IPackage is both - in a way
[15:33] <zyga-work> mvo: IPackage.pkgname i is the package itself while IPackage.name is "application name"
[15:33] <zyga-work> mvo: do we have a true list of applications in our database/
[15:34] <mvo> zyga-work: yes, we know what packages provide desktop files and consider those "applications"
[15:34] <mvo> zyga-work: we also have the pkges in the DB
[15:34] <mvo> zyga-work: a package may contain multiple "applications" (e.g. gnome-games)
[15:35] <zyga-work> mvo: what information we have about an application?
[15:35] <zyga-work> mvo: do we have any unique id?
[15:35] <zyga-work> I'd like to have something like org.gnome.games.somegame
[15:35] <zyga-work> (even though all of them are in one package0
[15:36] <mvo> zyga-work: right now they are not uniq, but they will be (today or tomorrow)
[15:36] <zyga-work> tomorrow? like 24hrs?
[15:36] <mvo> zyga-work: its going to be something like (appname##pkgname) for the internal id
[15:36] <zyga-work> mvo: oh, good
[15:36] <mvo> zyga-work: yeah, its a pretty anoying bug in the system right now
[15:36] <mvo> and I marked it for alpha6 I think
[15:36] <zyga-work> mvo: appname is "full name with spaces?"
[15:36] <mvo> yes
[15:37] <zyga-work> mvo: this could be ugly - what about translations and package renames?
[15:37] <zyga-work> mvo: I realize we don't have that data for each app but I think we could encourage unique application name based on domain name or something similar
[15:37] <mvo> zyga-work: its just internal to make sure its uniq, the translated name is stored as a additioanl field in the db
[15:37] <zyga-work> hmm
[15:38] <zyga-work> mvo: sorry I'm a bit ignorant on what is in xapian right now (or how it actually works)
[15:38] <mvo> zyga-work: right, that would be great (and a prefered way). but it would requiring adding that data to all desktop files
[15:38] <zyga-work> mvo: could you please give me a 3 minute intro into what we currently have and how xapian links it together?
[15:40] <mvo> zyga-work: its a document database. we currently store "name from desktop file" as data. we also add "values" for pkgname, archive section, category, type, repository (e.g. archive.canonical.com), gettext-domain, ppocon
[15:40] <zyga-work> is it like a big python dictionary? from string keys to "documents" (objects
[15:40] <mvo> zyga-work: right now it queries using the application name (e.g. Terminal) but that is buggy because its not uniq, so I need to fix that to make it uniq
[15:40] <zyga-work> and documents are again dicts?
[15:41] <mvo> zyga-work: its like a list of items (documents) that you can query very fast for certain terms (like packagename, appname)
[15:42] <zyga-work> so you can find a document and then get a property from that document fast, right?
[15:42] <zyga-work> (or basically do that for a list of documents that match some query)
[15:42]  * ojwb is reminded that a good introduction to Xapian's "data model" would be useful...
[15:43] <mvo> zyga-work: yes
[15:43] <zyga-work> what about "joins"?
[15:43] <zyga-work> or
[15:43] <zyga-work> indices
[15:43] <zyga-work> let's say you want to find an app that has the translated name "Termina"
[15:43] <mvo> ojwb: if you want to give that, that would be great, I'm sure I did a very clumsy job here
[15:43] <zyga-work> do you just search for that property in the "database" of all "application documents" ?
[15:43]  * ojwb meant a document doing that
[15:43] <mvo> zyga-work: you can chain queries
[15:43] <zyga-work> is it anything like coutchdb?
[15:43] <mvo> ojwb: aha, ok :)
[15:43] <zyga-work> couch-db
[15:44] <mvo> I don't know enough about counch-db to judge
[15:44]  * ojwb neither
[15:44] <zyga-work> okay let's skip this - I'll read more about it
[15:44] <ojwb> it's not (and doesn't strive to be) an RDBMS
[15:44] <zyga-work> it's just an implementation issue now
[15:44] <mvo> zyga-work: you can search for "all applications AND termina in name"
[15:44] <zyga-work> I'm asking because I wanted to know if the code behind UbuntuSoftwarePackage is sensible
[15:45] <zyga-work> I'll read about it later and we can fix anything
[15:45] <zyga-work> real question: do we need IApplication and if so what should it contain?
[15:46] <mvo> zyga-work: my gut feeling is that it would be nice to have, then it would contain a ref to ISoftwarePackage
[15:46] <mvo> zyga-work: and we could ask a ISoftwarePackage for its applications
[15:46] <zyga-work> right
[15:47] <zyga-work> okay I'll fix that
[15:47] <mvo> zyga-work: thanks
[15:47] <mvo> zyga-work: unfortuantely I can only merge when I got the contributor agreement :(
[15:47] <zyga-work> I see, well I hope it will be there soon
[15:47] <zyga-work> in the meantime I'll be a fork :-)
[15:47] <mvo> :)
[15:48] <zyga-work> what about transaction API?
[15:48] <zyga-work> I wanted to hide aptdaemon behind the store backend too
[15:48] <zyga-work> I was thinking about registering callbacks for transaction changes
[15:48] <zyga-work> and add some API for doing things
[15:48] <zyga-work> so that you could get ISoftwarePackage.install()
[15:48] <mvo> I think that is a good thing, so that we could more than just aptdaemon
[15:49] <zyga-work> and it would give you an IPackageManagerTransaction or something smilar
[15:49] <zyga-work> that would map nicely to pkgkit later
[15:49] <mvo> I like that
[15:49] <zyga-work> I should probably look at their api because it's probably sensible already
[15:49] <mvo> it would start right away by default
[15:49] <james_w> free: the branches should show up in a few minutes
[15:49] <zyga-work> I was thinking about two things: downloading/installing/removing, other stuff is useless for the "store level api"
[15:50] <free> james_w: nice! tnx
[15:50] <zyga-work> mvo: yeah - transactions are running in their own "time"
[15:50] <zyga-work> mvo: I noticed there is some code that allows you to stop a transaction but I didn't read it carefull enough
[15:51] <zyga-work> can I assume that you can only stop the download phase?
[15:51] <mvo> zyga-work: all we need here I think is a cancel() method to the IPackageManagerTransaction
[15:51] <zyga-work> (so install/remove are atomic at transaction level)
[15:51] <mvo> zyga-work: yes
[15:51] <zyga-work> mvo: and UniterruptibleTransactionError
[15:51] <mvo> zyga-work: cancel should fail then
[15:51] <zyga-work> right
[15:51] <zyga-work> ok
[15:52] <mvo> mvo: aptdaemon emits a signal when a transaction stops being interruptable
[15:52] <zyga-work> do you want to show separate "transactions" for getting dependencies?
[15:52] <mvo> no
[15:52] <zyga-work> does aptdaemon show this information in some way?
[15:52] <mvo> I think that is too granular, it should be one thing "get FOO installed"
[15:52] <zyga-work> show -> expose
[15:52] <mvo> I don't think it exposes it to that level
[15:52]  * mvo need to be away for 5min 
[15:53] <mvo> (doorbell)
[16:03]  * mvo is back
[16:04] <zyga-work> mvo: can aptdaemon say how much stuff is going to be downloaded for installing FOO?
[16:05] <mvo> zyga-work: yes, it got its own api for this, its pretty cool, it will emit signals for the current status and in what "role" its currently working
[16:05] <zyga-work> so I can do aptdaemon.install("foo")
[16:06] <zyga-work> and it will signal like ("downloading", some-bytes)
[16:06] <zyga-work> ("installing", some-progress-level)
[16:06] <zyga-work> etc?
[16:06] <mvo> zyga-work: yes, that will give you a tansaction and you can connect signals to that
[16:06] <mvo> zyga-work: yes
[16:06] <mvo> zyga-work: (on the transaction level, not on the client level)
[16:07] <zyga-work> ok
[16:07] <zyga-work> I think I know enough now, I'll update the rest of the app to support apps and transactions
[16:08] <zyga-work> cool
[16:08] <zyga-work> this hints back at one more thing
[16:08] <zyga-work> remember our discussion last time:
[16:08] <zyga-work> maybe packages vs stuff you install can be cleaned up easier now
[16:08] <zyga-work> packages provide stuff
[16:08] <zyga-work> and stuff are (right now) IApplications
[16:09] <zyga-work> later on we could do services
[16:09] <mvo> right
[16:09] <zyga-work> or developer libraries
[16:09] <mvo> or just packages :)
[16:09] <tseliot> pitti: it turns out the fdi was correct but the fdi cache wasn't updated, maybe because the mtimes were preserved (?)
[16:09] <zyga-work> so a developer could use the store to get what they want
[16:09] <mvo> zyga-work: for people who want to get all the details
[16:09] <pitti> tseliot: oh, that again :-(
[16:09] <zyga-work> well just packages is not good for apps :-)
[16:09] <tseliot> pitti: is it a known problem?
[16:09] <pitti> tseliot: we have a workaround in the postinst to delete it when another package ships another fdi file
[16:09] <zyga-work> but then you need synaptic _again_ and that is ugly
[16:09] <pitti> tseliot: I got some reports about it
[16:10] <zyga-work> you have to have "normal view" that shows applicatios
[16:10] <zyga-work> and "advanced" view that shows packages
[16:10] <tseliot> pitti: ok
[16:10] <pitti> tseliot: but nobody really is interested in fixing those small issues any more, since most things moved away from hal
[16:10] <mvo> zyga-work: yeah, the end should be to be able to deal with packages if you want, but the default should be apps (and maybe services)
[16:10] <zyga-work> and you _will_ have to show packages in some corner cases so the user is not shielded from package management anymore
[16:10] <tseliot> pitti: apart from X :-(
[16:11] <tseliot> except for X
[16:11] <pitti> yeah, that's still on the list
[16:11]  * mvo nods
[16:11] <mvo> zyga-work: great, I think it all fits together now
[16:12] <zyga-work> mvo: will the store ever show the terminal ?
[16:12] <zyga-work> like what snaptic currently does to configure some mess and to show you apt output?
[16:12] <mvo> zyga-work: probably not, it will deal with debconf/conffile however
[16:12] <zyga-work> oh, how?
[16:12] <mvo> zyga-work: aptdaemon supports terminals, but I don't think we want
[16:13] <zyga-work> silent mode?
[16:13] <mvo> well, most stuff is done via debconf nowdays, that a terminal is needed is a exception
[16:13]  * zyga-work thinks that we should be terminal-less at all costs
[16:13] <mvo> but conffile+debconf is important
[16:13] <mvo> terminal-less> absolutely agreed :)
[16:15] <zyga-work> mvo: what do you think about showing "delta" view by default, like most users see on typical windows system in add/remove programs
[16:15] <zyga-work> the stuff I added to my system since clean install
[16:15] <zyga-work> (I'm not sure about the stuff that the user removed)
[16:15] <mvo> zyga-work: I think there should be such a view, not sure if it should be default
[16:16] <zyga-work> does any apt infrastructure provide such data now?
[16:16] <mvo> zyga-work: we will have the installer write out some info then, but I think that is perfectly doable
[16:16] <zyga-work> like what was installed, when etc?
[16:16] <zyga-work> installer?
[16:16] <mvo> zyga-work: sort-of, but not in the level of detail/machine-readability that we need
[16:17] <zyga-work> hmm
[16:17] <zyga-work> pkgkit maintains its own data I guess
[16:17] <zyga-work> does the 2 year plan for the store include the pkgkit transition, if it happens?
[16:18] <mvo> the problem with packagekit is really that upstream is unwilling to support debconf and conffiles
[16:18] <mvo> that is a pretty big problem for us, otherwise we would have selected it
[16:18] <mvo> right from the start
[16:18] <zyga-work> I see
[16:19] <zyga-work> I remember some debian issues in general when I last inspected pkgkit
[16:19] <zyga-work> but debconf is going to be switched to "silent" mode right?
[16:19] <zyga-work> so the store never configures packages at install time by asking the user questions, right?
[16:19] <kagou> hi
[16:19] <mvo> zyga-work: yes, siwtches to noninteractive and uses --conf-old
[16:20] <cjwatson> noninteractive doesn't always work
[16:20] <zyga-work> well let's not think about that too much
[16:20] <mvo> zyga-work: well, aptdaemon does support debconf, so for that we are fine
[16:20] <zyga-work> if debian switches
[16:20] <zyga-work> or ubuntu
[16:20] <zyga-work> we'll reiterate
[16:20] <cjwatson> in particular packages that use the standard approach for licence questions will just fail with noninteractive
[16:20] <zyga-work> I think that we have an API close enough for making this possible
[16:20] <mvo> and the way we do it for aptdaemon would work fine for packagekit
[16:20] <mvo> but its not wanted (unfortunately)
[16:20] <cjwatson> and there are plenty of upgrade cases where zapping debconf will produce a broken system
[16:20] <kagou> I don't know who to contact, but since 2 days, daily-live iso have a problem. (squashf error)
[16:20] <zyga-work> cjwatson: I think that the store could have support for EULAs
[16:21] <zyga-work> and support installing such stuff
[16:21] <cjwatson> you can't handle the upgrade cases sanely
[16:21] <cjwatson> not without debconf
[16:21] <zyga-work> if you ever want to be a _store_ not a _pile_ of software for free ;-)
[16:21] <cjwatson> of course if the store never upgrades anything then that may not matter :)
[16:21] <cjwatson> but it sort of sucks to have to reimplement the EULA code already in the packages, doesn't it?
[16:22] <zyga-work> upgrades are a separate issue but I agree that debconf fills an important requirement
[16:22] <zyga-work> cjwatson: already present?
[16:22] <zyga-work> cjwatson: I think there is only a handful of apps that have eulas
[16:22] <cjwatson> yes
[16:22] <zyga-work> and the really proprietary apps could just standardize on the store API
[16:22] <cjwatson> small but non-zero
[16:22] <cjwatson> they need to still work with apt-get
[16:22] <cjwatson> for those in multiverse or whatever
[16:23] <zyga-work> cjwatson: I think that it's better to describe the EULA in some metadata
[16:23] <zyga-work> and allow the apt or any other frontend to display the EULA or not
[16:23] <zyga-work> so that the store just shows the same EULA in a nice way
[16:23] <zyga-work> and then install the package with some --eula-accepted switch
[16:23] <cjwatson> sure, but with the basic package management tools, the only sane approach is with debconf
[16:24] <zyga-work> so then the store needs to have a hook for debconf, EULA mode, and expose it somehow
[16:24] <zyga-work> does debconf support EULA or just random questions 'yes no' ?
[16:25] <james_w> it's just a "yes no" question
[16:25] <cjwatson> man debconf-devel
[16:25] <zyga-work> then it sucks and doing it right is better
[16:25] <cjwatson> I think we differ on our suck index
[16:26] <zyga-work> to have a good gui for EULA case you need to understand that it's really an EULA, not some yes/no question
[16:26] <zyga-work> I think that the store touches many technical and perhaps ideological issues with package managemenet in general
[16:27] <zyga-work> and unless we want to just make a better synaptic or some other thing we need to be able to change at the low level
[16:27] <zyga-work> otherwise the user experience is just going to stay the same
[16:27] <cjwatson> that's fine - but if you want to be able to integrate properly with things like the installer, attention to backward compatibility as well will pay dividends
[16:30] <mathiaz> james_w: hi!
[16:30] <james_w> hey mathiaz
[16:30] <mathiaz> james_w: I'm trying to import a new package from a new upstream tarball and ran into this error: http://paste.ubuntu.com/270995/
[16:30]  * james_w thinks he knows what this will be about
[16:30] <james_w> oh
[16:30] <mathiaz> james_w: this is on karmic with 2.2~ubuntu2
[16:31] <zyga-work> cjwatson: I fully agree with making changes in a compatible (at least upwards) and sensible way
[16:32] <james_w> mathiaz: I'm sure I uploaded the fix for that :-/
[16:33] <james_w> mathiaz: I'll check that it is indeed fixed, and then upload current trunk to karmic
[16:33] <james_w> mathiaz: sorry for the trouble
[16:33] <mathiaz> james_w: I'm running with a 2a loca repo - if that matters
[16:33] <james_w> not for this
[16:33] <mathiaz> james_w: np - I'll workaround it
[16:33] <james_w> it's just a simple programming bug
[16:36] <mvo> cjwatson: a quick question, I want to solve #387112 by providing generic patching support in u-m - because patch is not in the default install I will use "patch --ed" and run ed on from within the release-upgrade. or can you think of a better way to solve it?
[16:42] <cjwatson> mvo: are you not concerned about the lack of context in ed diffs causing misapplications?
[16:43] <mvo> cjwatson: the format is "_path_to_file.$md5sum" (or sha1 I guess these days). it does only apply if the hash matches
[16:43] <mvo> cjwatson: the format I want to use I should say
[16:43] <cjwatson> mvo: I think in this specific case sed would be usable and probably better - in general, if you're going to have to change u-m anyway is it not possible to depend on patch? or is it in the blob downloaded from the archive?
[16:44] <mvo> cjwatson: its a blob downloaded from the archive, I could make it install patch before anything else, but that would be a bit ugly as well (from a UI POV)
[16:47] <cjwatson> 'sed -i s/^use I18N::Langinfo;/d' or whatever seems simpler
[16:48] <mvo> cjwatson: ok, I think that is fine. my initial plan was to have a generic patch facility because there is a similar problem with install-docs that we will have to deal with for the next lts upgrade
[16:48] <mvo> cjwatson: but then, that can be done with sed as well :)
[16:49] <pitti> cjwatson: btw, seb128 and I reviewed ~ubuntu-desktop, and cleaned it up, so that the remaining members are all trusted by us to upload packages (just in case you want to flip the uploaders soon)
[16:50] <mvo> cjwatson: many thanks, I will implement it using the sed approach)
[16:51] <cjwatson> pitti: thanks, I've sent mail
[16:51] <cjwatson> mvo: cool
[16:58] <cjwatson> superm1: mythbuntu rebuilt
[16:58] <superm1> cjwatson, great thanks.
[17:14] <free> james_w: bzr checkout lp:ubuntu/intrepid/smart still fails, should I just wait a bit more?
[17:14] <james_w> bzrlib.errors.DuplicateKey: Key new-338 is already present in map
[17:15] <james_w> so there's something funky going on here
[17:15] <james_w> you may be better off going the old source package route, as I wouldn't want you to have to wait until I figure that out to get on with your work
[17:15] <free> james_w: sure
[17:16] <sladen> kirkland: rumour has it there's a virtualisation survey doing the rounds.  How do you get a link that can be posted to a mailing list (to many people)
[17:17] <free> james_w: anyway, bzr branches for source packages are very cool to have, so I hope this gets eventually sorted
[17:17] <james_w> free: I agree :-)
[17:17] <free> james_w: if you wish I can open a bug for it
[17:18] <james_w> it will get sorted, it's just that I have no idea what would be causing that error, it will require me to read some bzr source code
[17:18] <free> alright
[17:18] <kirkland> sladen: round 1 is directed toward Canonical Ubuntu engineers, as a fairly small sample set;  based on the feedback, we're going to refine the questions and send out to the rest of the community
[17:18] <james_w> free: it's on a list already, so a bug isn't necessary
[17:19] <james_w> thanks though
[17:19] <kirkland> sladen: ie, it's not yet ready for consumption on a massive scale
[17:33] <kees> soren: what, exactly was the reason for the testsuite fix in axis2c?  msg[10] isn't big enough for that strcpy...
[17:36] <LaserJock> anybody know what the timezone on cdimage.ubuntu.com is?
[17:37] <cjwatson> LaserJock: London, IIRC
[17:44] <LaserJock> cjwatson: I don't suppose the .iso builds put the bzr branch revision they were created from anywhere do they?
[17:48] <mathiaz> slangasek: hi!
[17:49] <mathiaz> slangasek: could you have a look at bug 423865?
[17:49] <mathiaz> slangasek: and let me know if there is any information missing for the FFe request?
[17:53] <cjwatson> LaserJock: no, sorry
[17:54] <rickspencer3> hi cjwatson
[17:54] <rickspencer3> I see that you are assigned to bug #424541
[17:54] <rickspencer3> cjwatson, is this on your list for A6?
[17:54] <LaserJock> cjwatson: np. the manifest files seem to be time-stamped ~ 2 days prior to the .isos, is there some lag on those or are the timestamps somehow wrong?
[17:55] <cjwatson> LaserJock: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ start here
[17:55] <cjwatson> rickspencer3: I hope so but I'm not sure yet - why do you ask?
[17:56] <rickspencer3> cjwatson, because I'm supposed to be tracking this list for mdz while he is gone
[17:56] <rickspencer3> cjwatson, is it just your workload, or is there something I can do to unblock it?
[17:56] <cjwatson> ah
[17:56] <slangasek> mathiaz: hrm, that bug doesn't tell me what the changes are that are being made, what the possible risks are of those changes
[17:56] <cjwatson> just my workload, I'm juggling eucalyptus and grub2
[17:56] <rickspencer3> (this list, btw: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=eucalyptus)
[17:56] <rickspencer3> cjwatson, ok
[17:56] <rickspencer3> thanks for the update
[17:56] <rickspencer3> :)
[17:57] <cjwatson> and euca is generally a right pain to test, multiple vms etc.
[17:57] <cjwatson> so tends to take a while :(
[17:57] <cjwatson> I'll try to move it up a bit
[17:57] <rickspencer3> cjwatson, ok
[17:58] <rickspencer3> I see you have a few assigned to you
[17:58] <rickspencer3> is there anything I can do to make the testing less of a pita?
[17:58] <cjwatson> that's more a reflection of the fact that I need to do some clearout of my assigned list
[17:58] <rickspencer3> :)
[18:00] <LaserJock> cjwatson: so is http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/edubuntu/latest/livecd-20090914-i386.out a bad sign?
[18:00] <cjwatson> LaserJock: yes, but I understand that was fixed by a bash upload
[18:01] <cjwatson> rickspencer3: thanks for the offer, but probably not really
[18:01] <mathiaz> niemeyer: 12:56 < slangasek> mathiaz: hrm, that bug doesn't tell me what the changes are that are being made, what the possible risks are of those changes
[18:02] <niemeyer> slangasek: This is a new feature being introduced to add support in Eucalyptus to download and register images automatically through the Eucalyptus admin interface itself
[18:02] <cjwatson> LaserJock: I expect the next rebuild will clear that particular one up, but I'm holding off on rebuilds at the moment as compiz has been busted today
[18:03] <cjwatson> LaserJock: live filesystem builds tend to be pretty sensitive to breakage unfortunately
[18:03] <niemeyer> slangasek: A bad scenario for this feature is to not work at all, but this won't mean that other parts of the system would stop working
[18:03] <slangasek> niemeyer: well, which parts are new?  The bug description talks a lot about "system requirements", but I'm pretty sure most of these are already present by default?
[18:03] <niemeyer> slangasek: So the risk is self-contained, IMO
[18:03] <niemeyer> slangasek: Right.. the only new part is the image-store-proxy itself
[18:04] <slangasek> niemeyer: and that's going to be shipping where?  in the server images?
[18:04] <niemeyer> slangasek: Right, next to Eucalyptus
[18:05] <niemeyer> slangasek: For the Image Store UI that is now in Eucalyptus to work at all, this proxy is needed
[18:05] <niemeyer> slangasek: So there should be a mutual dependency between them
[18:10] <mathiaz> niemeyer: does image-store-proxy daemonize correclty?
[18:10] <mathiaz> niemeyer: or is it just meant to run in the foreground?
[18:10] <niemeyer> mathiaz: Hmm, at the moment I believe it can only be run in foreground by itself
[18:11] <mathiaz> niemeyer: ok
[18:11] <niemeyer> mathiaz: Does it need to do daemonization by itself, or can you handle this in the initscript for now?
[18:12] <mathiaz> niemeyer: I'm looking into handling it via the initscript
[18:12] <niemeyer> mathiaz: Awesome, thanks!
[18:13] <slangasek> niemeyer: which twisted modules are used, specifically?
[18:13] <slangasek> mathiaz: use an upstart job instead, then you don't have to worry about handling it? :)
[18:14] <mathiaz> slangasek: hm - oh - good idea
[18:14] <mathiaz> slangasek: are there any examples I could look at?
[18:14] <niemeyer> slangasek: twisted.web, twisted.internet.defer, twisted.internet.threads, twisted.python.failure,  twisted.internet.address, twisted.trial.unittest
[18:15] <niemeyer> I believe that's it
[18:15] <slangasek> ok
[18:16] <slangasek> mathiaz: whatever's in the ubuntu-boot PPA, I think :)
[18:19] <Matt_91> HI every one
[18:19] <Matt_91> I'm Italian and my Italian is very bad.
[18:19] <Matt_91>  when the file system for ubuntu (only the partition where the OS is installed) is full, instead of coming out a message
[18:19] <Matt_91>  ! attention to the file system is full!
[18:19] <Matt_91> (says nothing and there is tremendous slowdown, problems some programs are crap and you lose initilmente time (me) to know what the hell's got into Ubuntu, then go and find out that my sister had put a folder on film Desktop and filled the partition, I do not know if it makes the idea, but the user does not know that the devil takes to his computer, but if you make him appear a notification message, then the user knows what he and his computer solv
[18:22] <Matt_91> Sorry I made a mistake, I rewrite
[18:22] <Matt_91>  when the file system for ubuntu (only the partition where the OS is installed) is full, instead of coming out a message
[18:22] <Matt_91>  ! attention to the file system is full!
[18:22] <Matt_91> (says nothing and there is tremendous slowdown, problems some programs are crap and you lose time in vain (I) to find out what the hell's got into Ubuntu, then go and find out that my sister had put a folder on film Desktop and filled the partition, I do not know if it makes the idea, but the user does not know that the devil takes to his computer, but if you make him appear a notification message, then the user knows what he and his computer solve
[18:25] <directhex> there should be a notify-osd message
[18:25] <directhex> i thought there was anyway
[18:25] <LaserJock> cjwatson: if the livefs build fails does the .iso build just use the latest one? I'm wondering why I have a DVD for the 14th when the livefs build failed.
[18:25] <ScottK> KDE has a warning.  I get pinged at 200mb left
[18:26] <Matt_91> no, ubuntu don't coming out a message
[18:27] <Matt_91> and I don't undestand te cause of my problems
[18:27] <Matt_91> directhex: ^^
[18:29] <Matt_91> I use GNOME
[18:29] <zyga> mv
[18:29] <zyga> ls
[18:31] <NCommander> slangasek, james_w did either of you just do NBS recently? My rootfs's just stopped being able to be built within the last hour or so with the kernel headers going poof
[18:32] <slangasek> not I
[18:32] <pitti> not me
[18:32] <slangasek> and such packages generally only get NBSed when they have no more reverse-deps?
[18:32] <Matt_91> My question was this: is possible insert a warning system (Windows is it) that when the user fills in the file system warns ubuntu?
[18:33] <NCommander> slangasek, right, sorry, stupid quesiton, but I can't see a package disappearing from the archive randomyl except via NBS :-/. Currently debugging
[18:33] <NCommander> thanks
[18:33] <slangasek> you didn't mention a package name?
[18:33] <Matt_91> ciao->hello!!
[18:34] <NCommander> slangasek, linux-mvl-dove-headers-2.6.31-204
[18:35] <slangasek> NCommander: hum, ok
[18:37] <NCommander> slangasek, the kernel is depending on that is a bug in its own right, but it doesn't explain why my rootfs's suddenly went poof
[18:43] <kees> Keybuk: what tool can I use to ready labels and uuids from filesystems now that vol_id has vanished?
[18:44] <ion> Warez at launchpad.net :-) https://bugs.edge.launchpad.net/ubuntu/+source/picard/+bug/357279
[18:44] <slangasek> kees: 'blkid'
[18:44] <kees> slangasek: ah-ha!
[18:45] <Keybuk> kees: blkid ;)
[18:45] <Keybuk> kees: btw, I have absolutely no idea what you did, but your udev update never hit the archive
[18:45] <kees> Keybuk: I was noticing that this morning as my karmic VMs hung again.
[18:46] <kees> Keybuk: anyway, since you didn't want it uploaded anyway, I guess that's good.  Shall I revert the bzr tree or re-upload?
[18:46] <ion> kees: Would you say your VMs are well hung?
[18:46] <kees> ion: more with every ssh connection
[18:46] <Keybuk> kees: I'll handle the bzr tree, it'll get smashed when I git update anyway
[18:46] <kees> okay cool
[18:46] <Keybuk> we need some testing before doing a udev 147, so I'll release current git head to the ubuntu-boot PPA
[18:52]  * robbiew straps in for Keybuk's ude release
[18:52] <robbiew> :P
[18:52] <robbiew> s/ude/udev
[18:53] <sebner> NCommander: still around?
[18:54] <NCommander> sebner, yes
[18:55] <sebner> NCommander: what about vtk? the armel fix seems to work. Are you capable of fixing the other FTBFS or shall we upload to the archive?
[18:55] <NCommander> sebner, just upload, I won't be able to look at it for quite awhile
[18:56] <sebner> NCommander: kk, thx
[19:05] <kees> ogra: do you have any more details about the chroot issue?  or a machine I can see it happening on?  I couldn't reproduce it.
[19:06] <ogra> kees, you need an i386 machine, use qemu-arm-static to build an armel chroot, chroot into that and install a mono package
[19:07] <ogra> mono fires off its assembly installer from postinst of any -cil package
[19:07] <ogra> and usually hangs then with no return
[19:07] <kees> ogra: is it specific to the armel chroot?
[19:07] <ogra> yes, its specific to stacked binfmt execution
[19:08] <kees> "stacked"?
[19:08] <ogra> i have an armel chroot in which every binary is executed through binfmt with qemu-arm-static
[19:08] <kees> ogra: is there documentation on setting up the armel chroot?
[19:08] <ogra> if i execute a mono package in this chroot it executes the i386 mono
[19:09] <ogra> i added it to the bug this morning
[19:09] <ogra> install qemu-arm-static, run build-arm-chroot (its a wrapper to debootstrap and takes identical args)
[19:10] <ogra> then just chroot into the chroot you built
[19:15] <jono> hey
[19:15] <jono> I just dist-upgraded and I have no panels, no window manager
[19:15] <jono> anyone else getting this?
[19:16] <smoser> given a package name and consistent apt-cache data how can i figure out what packages came from universe, multiverse, or main
[19:17] <smoser> i want to do a "for package in installed_packages() { print "$package:${where-it-came-from}\n"; }
[19:18] <pochu> smoser: apt-cache show $package | grep ^Section
[19:20] <jono> seb128, I am not getting any panels after a recent upgrade in karmic, is this known?
[19:21] <jono> and I see compiz is held back
[19:22] <slytherin> Can anyone help me debug this problem. Commercial DVD (CSS protected) is not getting mounted at all on karmic. This is dmesg output - http://paste.ubuntu.com/271106/
[19:26] <kirkland> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/429443 again ...
[19:26] <kirkland> cjwatson: what do you think about /usr/bin/kvm-ok -> util-linux ?
[19:31] <kirkland> cjwatson: Daviey suggested util-linux, i took a quick look, and it seems reasonable to me
[19:31] <kirkland> cjwatson: i thought you might weigh in;  if you're at least +0, I'll upload a fix from Daviey
[19:31] <Daviey> \o/
[19:48] <Amaranth> waiting for a build on ia64 wouldn't stop publishing a new version of a package, would it?
[19:48] <Amaranth> since ia64 isn't supported or whatever
[19:49] <slytherin> Amaranth: publish on other architectures?
[19:50] <Amaranth> slytherin: right, compiz is uninstallable because compiz-fusion-plugins-main update is missing
[19:50] <Amaranth> but it built like 6 hours ago on everything except ia64
[19:50] <slytherin> Amaranth: Then probably the archive mirror you are using has not yet updated.
[19:51] <Amaranth> slytherin: Well the guy having problems is using archive.ubuntu.com
[19:51] <Amaranth> I was using our PPA so it doesn't bother me that my mirror is outdated
[19:52] <Amaranth> hmm, lauchpad says it was published though
[19:52] <slytherin> Amaranth: Then probably it is problem with packages.
[19:52] <jono> how on earth do I make a bug that I reported as private (apport crash) public?
[19:52] <Amaranth> so he must be mistaken and is using a mirror
[19:52] <Amaranth> slytherin: nope, it built fine and didn't have to go through binary NEW or anything
[19:52] <Amaranth> guy is just using a mirror and doesn't know it or hasn't updated his Packages recently
[19:53] <Amaranth> jono: I can do it for you if you give me the number
[19:53] <Laney> jono: there's a box somewhere on the right
[19:53] <slytherin> Amaranth: If he is using us.archive.ubuntu.com then that mirror is known to cause problem from time to time.
[19:53] <Laney> "this bug is private" or so
[19:53] <Amaranth> jono: otherwise there should be a little yellow symbol next to where it says it is private
[19:54] <jono> Amaranth, odd I dont see the symbol
[19:54] <jono> Amaranth, https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/429566
[19:54] <Amaranth> oh man, compiz bug
[19:54]  * Amaranth leaves it private :P
[19:54] <Amaranth> huh, won't let me see it at all
[19:54] <Amaranth> that would me it's marked as a security issue, not a regular private bug
[19:55] <seb128> jono, not a known issue and should not be due to compiz
[19:55] <Laney> because the crash bug triagers aren't subscribed yet
[19:55] <Amaranth> s/me/mean/
[19:55] <Laney> i bet
[19:55] <Amaranth> or that
[19:55] <seb128> jono, is the guest session working? or do you get the panel if using alt-f1 or clicking?
[19:55] <jono> seb128, if I kill the panel process it reloads
[19:56] <kees> wow, I can't see that bug either
[19:56] <jono> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/429570
[19:56] <seb128> jono, it's not a gnome-panel issue for pretty sure
[19:56] <jono> seb128, could it be because of the panel background I am using?
[19:57] <seb128> jono, can you click on those? if you start a non GNOME session from gdm can you run gnome-panel manually?
[19:57] <jono> there were bugs with panel backgrounds, right?
[19:57] <seb128> nothing recent
[19:57] <seb128> gnome-panel didn't change for a week
[19:57] <jono> odd
[19:57] <jono> the only other session I have in gdm is xterm I believe
[19:58] <jono> seb128, I emailed kenvandine my .xsession-errors too if that helps
[19:59] <Amaranth> jono: you should be able to start gnome-panel from the xterm session, see if it is working
[19:59] <jono> I cant check right now, have to head to a call
[19:59] <jono> will test in a bit
[20:00]  * Amaranth has a feeling compiz is involved somewhere, cries a little
[20:00] <Amaranth> don't we still have the failsafe GNOME session?
[20:00] <seb128> jono, try dist-upgrading again current compiz updates should be there
[20:00] <seb128> Amaranth, there is no such entry in the new gdm in karmic
[20:00] <jono> seb128, I am not sure if they are on my mirror yet
[20:01] <seb128> use the main archive rather than a mirror and upgrade? ;-)
[20:01] <Amaranth> seb128: hrm, that's bad
[20:01] <Amaranth> failsafe GNOME would start without compiz, was a great way to see if compiz was at fault
[20:01] <seb128> Amaranth, not sure the failsafe session is really useful but patches are welcome
[20:02] <Amaranth> seb128: the only thing it did was start without compiz because compiz-wrapper checks for the failsafe ENV variable and falls back to metacity
[20:10] <GobiTheGoblin> Hi all! =) I kinda messed my 9.10 netbook-remix totally. Metacity wont start, I have to run progs, with alt-f2. Is this place to ask help how I can fix this?
[20:11] <GobiTheGoblin> Problem is my my estimate the nvidia drivers, which I installed, and after latest updates it didn't work no more
[20:11] <GobiTheGoblin> problem is in*
[20:13] <GobiTheGoblin> no one?
[20:14] <GobiTheGoblin> well... it was kinda a long shot
[20:14] <GobiTheGoblin> bb
[20:25] <soren> kees: I /removed/ that msg[10].
[20:25] <soren> kees: I have no clue what it was doing there. It's part of the upstream test suite.
[20:25] <soren> kees: Yes, they added a msg[10], copy a static string into it (which is IIRC 13 characters long) with strcpy and don't check anything about it. It's got "WTF" written all over it.
[20:25] <kees> soren: no, it seems that it got into the diff.gz (and then got patched out).  take a look at the diff.gz.  :P
[20:26] <soren> ?!?
[20:26] <soren> kees: It was there to begin with from upstream.
[20:26] <soren> I certainly didn't add it :)
[20:26] <kees> soren: http://launchpadlibrarian.net/31785577/axis2c_1.6.0-0ubuntu4_1.6.0-0ubuntu5.diff.gz
[20:26] <kees> that diff shows it being added?
[20:26]  * kees goes to download
[20:27] <soren> kees: Ah, that's apparantly just me messing around with quilt.
[20:27] <soren> kees: The first I heard about this was lool trying to enable the test suite, which then failed at that line.
[20:27] <kees> soren: Ah!  I see now
[20:28] <kees> soren: the diff.gz contains:
[20:28] <soren> kees: Sorry about the confusion.
[20:28] <kees> --- axis2c-1.6.0.orig/util/test/util/test_util.c
[20:28] <kees> +++ axis2c-1.6.0/util/test/util/test_util.c
[20:28] <kees> -    char msg[10];
[20:28] <kees> so, it still needs to be cleaned up?
[20:28] <kees> oh, no, I unpacked ubuntu4
[20:28] <kees> wheee
[20:28] <soren> kees: I was under the impression that ttx fixed it all today?
[20:29] <kees> soren: all is well, it seems I radically confused myself by only looking at the diff between ubuntu4 and ubuntu5
[20:29] <soren> Heh :)
[20:29] <soren> It really is a puzzling little artifact, that msg[10].
[20:30] <kees> soren: yeah, that's _really_ weird.  should ask upstream about that.  Likely just a debugging hiccup that fortify caught
[20:30] <soren> "Oh, let's add this completely unrelated and useless thing so that our test suite will fail horribly."
[20:34] <smoser> slangasek, so if everything is working under xen, should 'ldd' in bash indicate a usage of stuff in /lib/tls/i686/nosegneg
[20:34] <slangasek> smoser: yes
[20:34] <smoser> regarding bug 427288. i'm not seeing that.
[20:34] <slangasek> smoser: and you should not get the dmesg noise
[20:34] <smoser> i do not get dmesg noise
[20:34] <slangasek> smoser: you have libc6-xen and libc6-i686 installed?
[20:34] <slangasek> smoser: at what versions?
[20:35] <smoser> http://paste.ubuntu.com/271157/
[20:36] <smoser> slangasek,
[20:37] <slangasek> smoser: cat /etc/ld.so.conf.d/xen.conf?
[20:37] <slangasek> smoser: also, ldconfig -p | grep nosegneg?
[20:38] <slangasek> smoser: finally, ls -l /etc/ld.so.nohwcap
[20:38] <smoser> /etc/ld.so.conf.d/xen.conf has
[20:38] <smoser> hwcap 1 nosegneg
[20:38] <smoser> ' ldconfig -p | grep nosegneg' output is empty
[20:39] <smoser> $ ls -l /etc/ld.so.nohwcap
[20:39] <smoser> -rw-r--r-- 1 root root 0 2009-09-14 18:39 /etc/ld.so.nohwcap
[20:39] <smoser> (zero length file)
[20:39] <slangasek> hmm
[20:39] <cjwatson> kirkland: I guess that's ok ... I'd recommend trying to get it upstream though
[20:39] <slangasek> smoser: so, that file is disabling all hwcap extensions; it's added during package upgrade, and supposed to be removed once all the libc6-* variants are back at the same version
[20:40] <slangasek> smoser: do you have any other libc6-* packages that are *not* in state 'ii'?
[20:40] <smoser> dpkg -l 'libc6-*' shows only those 2
[20:41] <slangasek> smoser: gar, buggy maintainer scripts, missing substitution in libc6-xen.postinst
[20:42] <slangasek> (it says "CURRENT_VER", where it's supposed to actually give the version :P)
[20:42] <smoser> whoops.
[20:42] <slangasek> smoser: please sudo rm /etc/ld.so.nohwcap and double-check both ec2 and uec
[20:42] <slangasek> I'll work on fixing the package
[20:43] <kirkland> cjwatson: understood, and I agree
[20:43] <kirkland> Daviey: okay, util-linux sounds reasonable; please forward you changes upstream as well
[20:44] <smoser> slangasek, removed the file, then immediate 'ldd /bin/bash' shows
[20:44] <smoser> libc.so.6 => /lib/tls/i686/cmov/libc.so.6
[20:44] <Daviey> kirkland: wilco
[20:44] <slangasek> smoser: that's ec2 or uec?
[20:44] <smoser> ec2
[20:45] <smoser> i dont have a uec up at the moment, (and will likely just test this under kvm -- which is what uec is)
[20:45] <slangasek> smoser: ok; please do a sudo ldconfig as well
[20:45] <smoser> that fixed it
[20:45] <slangasek> (that's the sequence things are supposed to happen in the postinst; rm -f /etc/ld.so.nohwcap, then ldconfig)
[20:45] <slangasek> ok
[20:45] <slangasek> then once we fix the maintainer script, we should be golden
[20:48] <smoser> updated bug
[20:54] <slangasek> smoser: different bug, technically; this was fixed, then eglibc got merged from Debian and regressed :P
[20:55] <smoser> so you want a new bug opened ? i'm fine with whatever.
[20:55] <slangasek> "technically"
[20:56] <smoser> so do you technically want a new bug or do you want a new bug
[20:56] <slangasek> I may be venting rather than talking about anything that matters
[20:57] <smoser> i really dont care. i'll flip that back to fix-released and open a new bug, or leave it as 'in-progress' . slangasek its your call.
[20:57] <smoser> (since you're the one doing the work)
[20:57] <slangasek> smoser: well, it's not worth /your/ time to open a new bug if the other bug's already been reopened
[20:59] <smoser> then we leave it.
[21:02] <cjwatson> bug 424541 - does the address of the node's bridge interface need to be unique across the cluster, or is it not visible outside that one machine?
[21:03] <nxvl> lamont: hi!
[21:03] <nxvl> lamont: xdelta is unstalable in karmic
[21:03] <nxvl> lamont: it's depending on libglib1.2ldbl, which isn't in the archive anymore
[21:08] <mathiaz> bdmurray: hi
[21:08] <mathiaz> bdmurray: I've written some more scripts based on the multi-package-fixed-bug script you gave me at the sprint
[21:08] <mathiaz> bdmurray: and I'd like to run these on a regular basis (ie cron job)
[21:09] <mathiaz> bdmurray: what would it take to have these scripts run on qa.ubuntu.com?
[21:09] <mathiaz> bdmurray: (or the server when other launchpadlib scripts are run)?
[21:10] <nxvl> slangasek: did you know what is the reemplacement for glib1.2?
[21:10] <bdmurray> mathiaz: do you see them changing much or at all?  If not I could set them up / run them for you there.
[21:10] <slangasek> nxvl: ... glib2.0?
[21:10] <mathiaz> bdmurray: I don't expect a lot of change in the long term
[21:11] <nxvl> slangasek: but it has no ldbl  binary
[21:11] <mathiaz> bdmurray: may be a few details to be updated while we're testing their lists in the few weeks
[21:11] <mathiaz> bdmurray: in the coming weeks
[21:11] <slangasek> nxvl: what problem are you trying to solve?
[21:11] <cjwatson> nxvl: forget ldbl
[21:12] <slangasek> nxvl: glib1.2 is obsolete, and anything that depends on it needs to be ported to a modern library or dropped
[21:12] <cjwatson> ldbl was an ABI breakage in libglib1.2 that needed a new package name as a result - it isn't relevant to glib2.0
[21:13] <nxvl> slangasek: Bug #429619
[21:13] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490257
[21:13] <cjwatson> so it probably just needs bug 429493 to be actioned
[21:13] <cjwatson> which I'll take care of now
[21:14]  * nxvl HUGS cjwatson 
[21:17] <slangasek> Keybuk: er, you're missing the point
[21:18] <slangasek> Keybuk: the LSB headers *document* what the dependencies are - I'm asking whether these dependencies are still being *satisfied* in UpstartLand
[21:19] <Keybuk> slangasek: in the sense that those services, if converted to Upstart, are already started before rc2 is run, yes
[21:19] <slangasek> ok, that was the question
[21:19] <slangasek> thanks for confirming :)
[21:19] <Keybuk> Upstart runs the sysv-rc stuff as a "I'm done, what about you" kinda thing
[21:19] <slangasek> ok
[21:20] <slangasek> I thought that was the plan, but didn't want to make any assumptions
[21:20] <slangasek> Keybuk: uploading, then? :)
[21:20] <bdmurray> mathiaz: okay, I think I could do that for you
[21:20] <Keybuk> slangasek: have a couple of bits to fix, another test run
[21:20] <Keybuk> then yes
[21:20] <slangasek> ok
[21:20] <Keybuk> certainly will be uploading this evening
[21:20] <mathiaz> bdmurray: great - I'll clean my scripts and push it lp
[21:21] <mathiaz> bdmurray: I'll let you know when I have a branch ready
[21:29] <slangasek> Keybuk: so cryptsetup itself doesn't seem to be on your list for the freeze exception; are you planning an upload there for alpha 6, or should I pick that up if I want my own boot to not regress? :)
[21:29] <Keybuk> slangasek: it shouldn't regress
[21:29] <Keybuk> you should still get a prompt, just not via usplash
[21:29] <slangasek> ugly == regression
[21:29] <slangasek> :-)
[21:29] <Keybuk> no ugly != regression
[21:30] <slangasek> right, so I should upload
[21:30] <Keybuk> if you like
[21:30] <Keybuk> you need to ship a file in /etc/initramfs/conf.d with USPLASH=y in it
[21:30] <slangasek> yep
[21:31] <Keybuk> I can add it to the FFe for tracking purposes
[21:31]  * slangasek makes noncommittal hand-wavy gestures
[21:31] <Keybuk> also on the "cryptsetup implies usplash" issue ...
[21:31] <Keybuk> cryptsetup implies a slow boot as everything gets decrypted too
[21:31] <Keybuk> so you probably want it anyway <g>
[21:32] <slangasek> heh
[21:32] <Keybuk> (the missing bit for auto-starting usplash btw is that I want it to show up with "status usplash"
[21:33] <Keybuk>  and that requires a bit of a hack :p)
[21:35] <mathiaz> bdmurray: https://code.launchpad.net/~mathiaz/+junk/multi-package-bugs-fixed/
[21:35] <mathiaz> bdmurray: these are the scripts
[21:35] <ion> keybuk: Did i get this right, you want Upstart to start usplash on ‘status usplash’?
[21:35] <Keybuk> ion: no, report its pid with status usplash
[21:35] <Keybuk> ie. think it's running with the pid that was started from the initramfs
[21:36] <Keybuk> so "stop usplash" will work
[21:36] <Keybuk> and, more importantly
[21:36] <ion> Ok
[21:36] <mathiaz> bdmurray: I'll send you an email outlining which scripts should be run and how often
[21:36] <Keybuk> "stop on starting (gdm or kdm)" in the usplash.conf file will work :p
[21:51] <kirkland> pitti: ping
[21:51] <kirkland> pitti: i've been pulled in different directions
[21:54] <slangasek> the kirkland taffy pull
[21:56] <kirkland> slangasek: heh :-)
[22:01] <slangasek> smoser: and is libc6-xen being installed by default now in the UEC builds?
[22:09] <pdf> Hello, can someone tell me if the last ubuntu dist-upgrade break something    ?
[22:09] <Keybuk> pdf: how about you tell us that the last ubuntu dist-upgrade you did broke something? :)
[22:10] <pdf> the last one was nice
[22:10] <pdf> just noticed that it removes compiz
[22:10] <james_w> well don't do that then
[22:11] <james_w> you caught it at a bad time, and the point of dist-upgrade is that you are supposed to check what will be removed
[22:12] <dan4dm> hi folks, i have a question about how i can fix a farm build on launchpad. is this the right channel?
[22:14] <slangasek> doko: you know that core-dev isn't a member of ubuntu-toolchain?
[22:16] <mathiaz> kirkland: hey - I've got a new package ready for your review: http://people.canonical.com/~mathiaz/packages/
[22:17] <doko> slangasek: should it be?
[22:17] <doko> we don't have a ubuntu-foundations ...
[22:17] <slangasek> doko: you complained about people not committing their changes to bzr :)
[22:18] <slangasek> core-dev has access to upload the package - core-dev should have access to commit
[22:19] <doko> hmm, I added you, I don't like the idea of whole core-dev ...
[22:20] <Keybuk> doko: why not?
[22:20] <Keybuk> they can upload
[22:20] <Keybuk> if you'd like to change the permissions of who can upload the toolchain, you'd need to talk to the Ubuntu Technical Board
[22:22] <Keybuk> kirkland: do you plan to send kvm-ok to util-linux upstream?
[22:22] <kirkland> Keybuk: yes, absolutely
[22:22] <Keybuk> ok, shiny
[22:23] <Keybuk> if you need any help, I'm happy to review for you etc.
[22:23] <doko> Keybuk: yes, but let's delay that for the next uds
[22:24] <Keybuk> actually, now would be better, since the discussion about the formation of package sets is ongoing *right now*
[22:26] <doko> Keybuk: pointer?
[22:27] <Keybuk> doko: tech board meeting minutes
[22:28] <doko> let's see if I find some time ...
[22:37] <Keybuk> doko: in the meantime, you should do ask slangasek suggests and add ubuntu-core-dev to your bzr tree
[22:37] <Keybuk> otherwise you're just making work for yourself, since you'll have to check the archive for any upload, and merge them in, and commit every time you want to commit to bzr
[22:38] <doko> Keybuk: I disagree, non-membership doesn't hinder anybody to check pending changes and upload these
[22:39] <slangasek> well, no; in this case what hindered that was that it was a blatant violation of the feature freeze
[22:39] <Keybuk> doko: why should they bother to help you if you're not bothering to help them
[22:40] <doko> no, I don't consider a package split a violation of feature freeze
[22:40] <kirkland> Keybuk: what we really need is a sanity check on the replaces/conflicts
[22:40] <Keybuk> kirkland: first get the tool upstream
[22:40] <Keybuk> then we'll consider the packaging
[22:41] <kirkland> Keybuk: ah
[22:41] <Caesar> Sanity check: you have to restart udev when you add or change the rules, don't you?
[22:41] <Keybuk> Caesar: no
[22:42] <slangasek> doko: then you should reconsider, because it is, and *you introduced a regression* when you did it
[22:42] <slangasek> see latest bzr commit
[22:42] <robbiew> doko: The Release Team makes the call of whether or not something violated FeatureFreeze
[22:42] <kirkland> Keybuk: hmm, okay, so is this conceivable to get upstreamed, and into karmic?
[22:42] <Caesar> Keybuk: it just automagically deals with the rule change?
[22:42] <kirkland> Daviey: note Keybuk's comments; he wants to see it upstreamed first
[22:43] <Keybuk> kirkland: it's one of the set of packages that we (along with other distros) promise not to ship patches or extras for that are not upstreamed
[22:43] <Keybuk> Caesar: yes
[22:43] <Caesar> Keybuk: thanks
[22:43] <robbiew> doko: which is why they process the FFEs
[22:43] <kirkland> Keybuk: fair enough, good to know ;-)
[22:43] <Daviey> Keybuk / kirkland: noted
[22:43] <doko> robbiew: in this case every change has to be approved by the release team, unless there are clear guidelines. and I still don't see that a package split is a violation of feature freeze
[22:43] <Daviey> Keybuk: are you aware util-linux currenty FTBFS on karmic?
[22:44] <Keybuk> Daviey: it built for me
[22:44] <robbiew> doko: "At this point we stop introducing new features, *packages*, and APIs, and concentrate on fixing bugs in the development release. "
[22:44] <Keybuk> it looks like it's built in the archive too
[22:44] <Daviey> Keybuk: try it now.. i've tried the archive version in both LP ppa and cowbuilder
[22:44] <Keybuk> Daviey: why don't you tell me how it failed instead?
[22:45] <robbiew> so with this split...did we get a new package? or just update an existing one?
[22:45] <Daviey> Keybuk: that isn't the arcive versio.. but shows the same error
[22:45] <Daviey> http://launchpadlibrarian.net/31797090/buildlog_ubuntu-karmic-amd64.util-linux_2.16-1ubuntu2_FAILEDTOBUILD.txt.gz
[22:45] <Keybuk> Daviey: that's a glibc bug
[22:45] <Daviey> Keybuk: i reverted a patch, and it works
[22:45] <slangasek> robbiew: it's a new binary package, a split that only benefits multiarch... which we're obviously not doing for karmic
[22:45] <Daviey> Keybuk: wait for glibc to fix, or suggest a patch?
[22:46] <Keybuk> Daviey: glibc changed the API of a bunch of functions "to match POSIX", breaking a large number of things
[22:46] <Keybuk> Daviey: afaik, glibc refuse to accept that it's a bug
[22:47] <Daviey> Keybuk: nice!
[22:47] <robbiew> slangasek: okay...so by definitiion (https://wiki.ubuntu.com/FeatureFreeze)...the upload broke the freeze
[22:47] <robbiew> right?
[22:47] <slangasek> yes
[22:48]  * ScottK grumbles about Eucalyptus.
[22:48] <Daviey> Keybuk: reverting debian carried patch in mount/lomount.c #ifndef HAVE_VERSIONSORT solves it.. but perhaps fixing the def HAVE_VERSIONSORT would be cleaner.
[22:48] <slangasek> the upload also merged in a variety of /other/ things that don't pass for bugfixes
[22:48] <Keybuk> Daviey: you're barking up the wrong tree
[22:49] <soren> ScottK-desktop: What's up?
[22:49] <Daviey> *woof*
[22:49] <soren> ScottK: What's up?
[22:49] <ScottK> soren: There was grumbling about late splitting of packages.  I thought I'd toss it on the pile.
[22:49] <ScottK> Not a big deal.  I gather it worked out.
[22:49]  * soren reads a bit of scrollback for context
[22:50] <Daviey> Keybuk: got a suggestion for a tree i should raise my leg on.. or would you prefer i left it with you?
[22:50] <soren> ScottK: Ah. Hm. Yes, I suppose an FFe would have been in order.
[22:51] <Keybuk> Daviey: I'm not going to do anything about it
[22:51] <Keybuk> it's a glibc bug
[22:51] <doko> robbiew, slangasek: well, ok, I wasn't ware of the "packages"
[22:52] <Daviey> Keybuk: if i get this kvm-ok into Debian, won't that leave us in a bad position - or do you suspect glibc will get a grip before then?
[22:53] <Keybuk> Daviey: what's Debian got to do with it?
[22:53] <Keybuk> I said *UPSTREAM*
[22:53] <Daviey> oh, sorry..
[22:53] <Keybuk> util-linux-ng@vger.kernel.org FWIW
[22:53] <Daviey> Keybuk: thanks
[23:05] <doko> slangasek: do you refer to 429003 by mentioning the regression?
[23:06] <slangasek> doko: no, not that one; there was a regression directly related to the libc-bin package split, which I just found by reviewing diffs
[23:06] <slangasek> doko: libc-bin holds the trigger, but the postinst handling was still in the libc6 package
[23:06] <doko> ack
[23:06] <slangasek> so ldconfig would never be triggered
[23:09] <dtchen> i was just going to mention that!
[23:14] <ccheney> shtylman: ping
[23:16] <ccheney> has the location for the next UDS been determined yet?
[23:16] <soren> No.
[23:19] <soren> I know I really should have figured this out by now, but when does the soft freeze for A6 kick in?
[23:19] <slangasek> soren: 0000UTC tonight
[23:19] <pwnguin> need a calendar for evolution for this ;)
[23:20] <ccheney> so in 1:40
[23:20] <soren> slangasek: ah.
[23:22] <soren> slangasek: Ok. Well, as long as any uploads I do from then until Thursday is bringing us closer to a good alpha, I'm in the clear, right?
[23:23] <soren> slangasek: Also, should I change the status of bug 425914 to catch the release team's attention, or is it only "In progress" that you guys ignore?
[23:26] <slangasek> soren: the definition of "bring us closer to a good alpha" is "fix milestoned bugs, uninstallables, or out-of-date packages and not disrupt the CD builds" :)
[23:26] <soren> slangasek: I can work with that :)
[23:29] <soren> slangasek: Do you think there's any hope I can get that FFe approved within the next 10-15 minutes? Otherwise, I'll go pass out.
[23:30] <slangasek> soren: sorry, what FFe?
[23:30] <soren> 22:23:51 < soren> slangasek: Also, should I change the status of bug 425914 to catch the release team's attention, or is it only "In  progress" that you guys ignore?
[23:30] <soren> That one :)
[23:30] <soren> Sorry, I
[23:30] <soren> m really not being very clear today.
[23:30]  * soren is feeling a bit under the weather.
[23:31] <slangasek> soren: heh - yes, I ignore anything "confirmed" or above
[23:31] <soren> slangasek: /me sets it "new"
[23:31] <soren> There.
[23:36] <soren> slangasek: So.. Do you think there's any hope I can get that FFe approved within the next 10-15 minutes? :)
[23:46]  * soren guesses not and goes to pass out
[23:51] <slangasek> soren: oof, sorry
[23:52] <slangasek> soren: if you're still around: what are the risks of this change?
[23:55] <cjwatson> the alphasort thing is a POSIX regression, sadly, not a glibc regression. http://austingroupbugs.net/view.php?id=142
[23:56] <cjwatson> I suspect they're caught between rock and hard place because this appears to be a BSD vs. SysV thing
[23:56] <cjwatson> or at any rate Solaris is on the side of the coin we're currently on