[00:11] <slangasek> smoser: incidentally, does the UEC image generation process also create a file list for the image?
[00:12] <slangasek> if so, it would be nice to have that published next to the images, so we can see when things are out of date
[00:12] <smoser> slangasek, you mean like 'find /' ?
[00:12] <smoser> it does not
[00:12] <slangasek> smoser: a list of the .debs that went into it
[00:12] <slangasek> (with versions)
[00:12] <slangasek> this is standard output for the livefs buildd jobs
[00:12] <slangasek> so perhaps it exists somewhere but you're just not grabbing it at present
[00:13] <slangasek> (they're called foo.manifest when they're generated with the livefs)
[00:13] <smoser> i dont know. i'll poke around.
[00:13] <smoser> eu karmic-x86_64-alpha5: ami-9e6249ea
[00:14] <smoser> eu karmic-i386-alpha5: ami-986249ec
[00:14] <smoser> slangasek, ^^ (those are eu ami ids)
[00:14] <slangasek> posted to the tracker
[00:14] <slangasek> how's the image testing going, so far?
[00:15] <slangasek> (no results posted to the tracker, so I have no idea if these images are good or if we're facing more re-rolls and a delay in the alpha publishing)
[00:21] <smoser> slangasek, i really have only sniff tested so far. been struggling with the publish and such. i will run through the testing.
[00:21] <smoser> and updated tracker
[00:21] <slangasek> ok
[00:43] <slangasek> cody-somerville: xubuntu images are available for testing for alpha5, if you haven't seen
[00:43] <cody-somerville> thanks
[00:44] <slangasek> luisbg, TheMuso: likewise for ubuntustudio
[00:44] <slangasek> superm1: and also for mythbuntu
[00:44] <TheMuso> slangasek: Saw the tracker email earlier, getting ready to test now.
[00:44] <slangasek> ok
[00:59] <slangasek> smoser: you consider http://iso.qa.ubuntu.com/qatracker/result/2960/339 a failed test due to bug #419306?
[01:00] <slangasek> smoser: is there no workaround for that bug?
[01:00] <slangasek> (or did the test fail for other reasons?)
[01:01] <smoser> slangasek, it is easily worked around
[01:02] <smoser> how do i show that?
[01:02] <smoser> i was really just trying to mark a bug. and hit save to say "known bug" . but i think i registered 'fail'
[01:02] <slangasek> smoser: there's a "Result:" field, click it to 'passed' instead of 'failed'
[01:02] <slangasek> (and then put something in comments, if you like)
[01:03] <smoser> am i able to edit existing ? or does each time i do it add a new 'run' of the tests?
[01:03] <slangasek> smoser: it only lets you edit the existing
[01:03] <slangasek> (AFAIK)
[01:03] <slangasek> oh, or you may need to click on the magnifying glass on the far end of the row
[01:03] <slangasek> smoser: ^^
[01:04] <slangasek> LaserJock: hi - you disappeared before I could respond to your edubuntu seed inquiry this morning
[01:04] <LaserJock> slangasek: sorry about that
[01:04] <slangasek> LaserJock: are the current seeds suitable for testing as an alpha5 candidate?
[01:05] <LaserJock> slangasek: not really
[01:05] <LaserJock> the problem is that the Edubuntu DVD is just building from Ubuntu's DVD seed
[01:05] <slangasek> oh, there's not a separate edubuntu seed pod?
[01:06] <LaserJock> as edubuntu.karmic doesn't yet have it's own seed (that's what I'm trying to add)
[01:06] <LaserJock> there is
[01:06] <LaserJock> but it depends on Ubuntu's seed pod
[01:06] <LaserJock> or inherits is maybe a better term
[01:06] <slangasek> adding edubuntu.karmic doesn't seem like it should disrupt anything else?
[01:07] <LaserJock> edubuntu.karmic exits, it just doesn't have a dvd seed in it
[01:07] <slangasek> (if there's cdimage work to be done yet to get it working correctly, we may run out of time for including it in the alpha; but it doesn't sound like you're changing things that will disrupt other images)
[01:07] <LaserJock> so I *think*, worst case scenario, I screw up the seed and the Edubuntu DVD build is crap
[01:07] <slangasek> right
[01:07] <LaserJock> the cdimage work is already done
[01:07] <slangasek> I think you should definitely go for it then
[01:08] <LaserJock> ok
[01:08] <LaserJock> let me know though if for some unforeseeable reason it causes a problem
[01:09] <slangasek> if you need to make changes to the *ubuntu* seed pod, we should discuss specifics first
[01:09] <slangasek> but if you're only changing your own, go for it
[01:09] <LaserJock> yeah, only edubuntu.karmic
[01:12] <slangasek> smoser: thanks for the comment there - it seems like this is something we probably want to include in the Tech Overview as errata, yes?
[01:13] <smoser> absolutely
[01:13] <smoser> zul, http://iso.qa.ubuntu.com/qatracker/build//all
[01:13] <smoser> slangasek, so why does that say 1(2)
[01:14] <slangasek> smoser: there are two tests for the image, we have test results for one of them
[01:15] <slangasek> (I guess you mean "1/2" rather than "1(2)", right?)
[01:15] <smoser> ah. ok. i was thinking that was 1 of 2 failed
[01:15] <smoser> y
[01:15] <slangasek> failures are put in parens afterwards if any
[01:22] <zul> The requested instance type's architecture (i386) does not match the architecture in the manifest for ari-8e9bb3fa (x86_64)
[01:23] <slangasek> zul: what ami is that?  That's not one of the ones posted to the tracker for alpha5
[01:23] <zul> slangasek: its the eu one smoser is looking at it
[01:24] <slangasek> zul: ari-8e9bb3fa is not the eu one smoser gave me to post to the tracker
[01:25] <smoser> slangasek, zul's pasted the ari
[01:26] <smoser> but the ami needs to be 'fixeed'. i must have published it wrong
[01:26] <smoser> i'll fix that
[01:26] <slangasek> ah
[01:49] <TheMuso> s it just me, or is grub not responding to an escape key press?
[01:49] <cjwatson> hold shfit
[01:49] <cjwatson> shift
[01:49] <TheMuso> oh ok
[01:49] <cjwatson> and see https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicBootExperienceDesignSpec#Bootloader
[01:51] <superm1> slangasek, unfortunately will need a re-roll after mythtv publishes again.  there was a problem with a hardcoded filename in a postinst somewhere
[01:51] <slangasek> superm1: so we're looking for -0ubuntu3?
[01:52] <superm1> slangasek, yeah. just uploaded it a few minutes ago
[01:52] <slangasek> superm1: ok, queued up
[01:53] <superm1> thanks
[01:54] <dave-ubuntu1> anyone home 0_o?
[01:57] <LaserJock> I'm at home, not sure about other people
[01:59] <smoser> slangasek, ami-846249f0
[01:59] <dave-ubuntu1> LaserJock, can you help me set my /usr/share/initramfs-tools/scripts/local-top/cryptroot. file
[01:59] <dave-ubuntu1> or point me in the right direction.
[02:00] <slangasek> smoser: which one does that replace?
[02:00] <dave-ubuntu1> the people in #ubuntu have no clue when it comes to more advanced problems..... my system wont boot
[02:00] <smoser> eu-i386
[02:00] <dave-ubuntu1> by the way why is sun java jre 1.0.14 the latest in the repos?
[02:01] <slangasek> smoser, zul: published to the tracker
[02:01] <dave-ubuntu1> <IP_ADDRESS> is out
[02:19] <TheMuso> slangasek: Hrm I think studio alphas are a bust, due to some weird behavior with the RT kernel. Unless I can find a fix soonish, I'm going to have to say we'll have to pass this time around.
[02:20] <slangasek> TheMuso: ok; can you please mark the test as failed in the tracker?
[02:20] <TheMuso> slangasek: sure
[02:23]  * TheMuso tries i386 as well to see if both arches are affected.
[04:31] <foxbuntu> mathiaz, ping
[04:31] <mathiaz> foxbuntu: hi
[04:32] <foxbuntu> mathiaz, hello, I was wondering if you knew about the mysql-server-5.1 issue yet?
[04:32] <foxbuntu> ...more specificly that it doesnt install/upgrade from 5.0 properly
[04:32] <mathiaz> foxbuntu: I know of a couple of mysql-server-5.1 issue
[04:32] <mathiaz> foxbuntu: under which circumstances? what is the error message?
[04:32] <mathiaz> foxbuntu: is there a bug?
[04:33] <foxbuntu> mathiaz, not yet..I wanted to get your thoughts on it and then if its indeed a bug I will gladly file it for you
[04:33] <foxbuntu> mathiaz, let me get logs for you
[04:34] <foxbuntu> mathiaz, http://mythbuntu.pastebin.com/m7e507c83
[04:34] <foxbuntu> mathiaz, this is what I am seeing
[04:34] <mathiaz> foxbuntu: how are you upgrading the system? apt-get dist-upgrade?
[04:34] <foxbuntu> yes
[04:35] <mathiaz> foxbuntu: bug 413789
[04:35] <foxbuntu> mathiaz, ah...looks like it
[04:37] <foxbuntu> mathiaz, your the man :)
[04:37] <foxbuntu> right on top of it.
[04:37] <foxbuntu> thats all I wanted :)
[06:46] <dholbach> good morning
[07:47] <pitti> Good morning
[08:42] <lifeless> pitti ping
[08:42] <lifeless> pitti: bryce: just offhand, would you happen to remember doing a sync-and-discard of our xlib patches ?
[08:45] <bryce> lifeless, xlib?  not offhand
[08:48] <pitti> hey lifeless
[08:54] <tseliot> hey bryce
[08:54] <bryce> heya tseliot
[08:57] <lifeless> hi pitti :)
[08:57] <lifeless> for some reason my dreaded 'not supported by xlib' locale errors are back; I'm investigating.
[08:58] <lifeless> the patch is still there and in the series, but something's not right.
[08:58] <pitti> errare linuxum est?
[09:00] <lifeless> that reminds me, vocab practice time ;)
[09:13] <slangasek> superm1: the mythbuntu respin did get posted; not sure who's going to be testing those?
[09:22] <davmor2> slangasek: I'd say I would but I'm a bit busy with all the others :)
[09:23]  * slangasek nods - well, it'll be some hours before superm1 is around, we'll see what happens
[11:03] <d3xter> hey guys
[11:04] <slytherin> Now that udev/devicekit handles storage devices, should hal be uninstalled?
[11:04] <d3xter> is there any documentation on how to use notify-osd to display messages?
[11:10] <slangasek> slytherin: it should be marked as a candidate for autoremoval for you when the time comes; in the meantime I wouldn't second guess it :)
[11:11] <ubuntu> hello
[11:11] <ubuntu> sorry to ask this here but no one seems to know anything in the regular channel. i'm getting this error on installing xubuntu 9.04 amd64: "Executing 'grub-install (hd0)' failed. This is a fatal error"
[11:11] <slytherin> slangasek: I am having some problem with the DVD drive getting recognized. I was wondering if hal-storage is interfering with udev.
[11:12] <ubuntu> at 94% done
[11:12] <slangasek> slytherin: well you can try removing it for debugging to see if it makes a difference; either way it warrants a bug report
[11:12] <ubuntu> the md5sum of the cd checks out
[11:12] <cjwatson> ubuntu: please change your nick to something less generic. That's also a rather generic error message unfortunately; there should be more information in /var/log/syslog or possibly /var/log/installer/debug
[11:12] <d3xter> is there any documentation on how to use notify-osd to display messages?
[11:12] <slytherin> slangasek: A bug is already open. I have added info that keybuk asked.
[11:15] <lg> cjwatson, snippet from /var/log/syslog: http://codepad.org/hkrCzwza
[11:16] <tgpraveen> d3xter: lots. seee
[11:16] <lg> cjwatson, similar errors in /var/log/installer/debug
[11:16] <tgpraveen> .. search google for notify osd development fuideline wiki or something
[11:16] <tgpraveen> *guideline
[11:17] <d3xter> tgpraveen: ok, thx
[11:28] <lg> cjwatson, ok i'll try with karmic then. can you point me to the release you'd like me to try?
[11:28] <cjwatson> we're not putting much more effort into GRUB Legacy (as in 9.04), but if GRUB 2 still gets it wrong then we'll want to debug that
[11:28]  * slangasek blinks
[11:28] <slangasek> "gnome-terminal wants to install a font\n An additional font is required to view this document correctly."
[11:28] <cjwatson> lg: you might as well go for http://cdimage.ubuntu.com/xubuntu/daily-live/current/, which is very close to what we'll shortly be releasing as Alpha 5
[11:28] <lg> cjwatson, will do
[11:28] <slangasek> no thanks, I'm ok with not being able to read the spam
[11:28] <cjwatson> lg: thanks a lot
[11:29] <yuanyelele>  Hi, Anybody know where is gsize defined in glib-2.*?
[11:29] <yuanyelele>  it is referenced some where but I can not find the definition
[11:31] <lg> yuanyelele, http://library.gnome.org/devel/glib/unstable/glib-Basic-Types.html#gsize
[11:32] <lg> for glib related questions you may want to try irc.gnome.org/#glib or #gtk
[11:33] <yuanyelele> well , I cannot find this line "typedef unsigned long gsize;" in any file..
[11:33] <lg> ah
[11:33] <yuanyelele> sorry but there are few people in those channels....
[11:33] <lg> i dont have the headers on hand but.. have you tried to cd into /usr/include and then do a grep -ri "typedef unsigned long gsize" ?
[11:34] <yuanyelele> yes, it's in glib-1.2, but not in glib-2.0
[11:35] <cjwatson> it's in /usr/lib/glib-2.0/include/glibconfig.h
[11:35] <yuanyelele> Oh thank you!
[11:36] <lg> what an odd spot for the headers
[11:36] <yuanyelele> The point is why online api does not cite this file?
[11:36] <Hobbsee> uit
[11:37] <lg> hmm
[11:38] <lg> how will i be able to burn a disc from a box with 1 cd drive (while running the live cd)?
[11:38] <cjwatson> lg: that may be a challenge
[11:38] <tgpraveen> d3xter: https://wiki.ubuntu.com/NotificationDevelopmentGuidelines
[11:39] <cjwatson> yuanyelele: the existence of that file isn't part of the advertised API, I assume; what the API documentation says is that if you include <glib.h> then you get gsize
[11:40] <cjwatson> lg: odd spot> IIRC, it's the architecture-dependent bit of the headers
[11:40] <lg> ah yes that would explain it
[11:41] <yuanyelele> Thank you~~
[11:48] <lg> arg, cant unmount cdrom, says its busy
[11:57] <lg> ok, got it burnt somehow. gonna try installing. will be back
[12:03] <d3xter> tgpraveen: thx, i've found this already
[12:03] <lg> hello
[12:07] <lg> on another box now. currently installing karmic on the other.
[12:08] <lg> btw, i like the encryption option in the installer
[12:21] <pitti> ogra: do you happen to know about a good guide how to setup cross compiling for ARM?
[12:21] <pitti> ogra: (I already know https://wiki.ubuntu.com/ARM/BuildEABIChroot, that's an excellent thing)
[12:22] <ogra> pitti, what do you want to cross complie ?
[12:22] <pitti> ogra: myself nothing, but a friend of a friend wants to do that (he'll give me a call soon)
[12:22] <ogra> if its a kernel, amitk's blog is great, for all other stuff i'd use a chroot or qemu, else you get into dependency hell
[12:22] <jjardon> pitti, hal is not more a hard dependency in gnome-power-manager, see http://bugzilla.gnome.org/show_bug.cgi?id=593933
[12:23] <pitti> ogra: oh, https://wiki.ubuntu.com/Toolchain/Crosscompilers/ARMEABIToolchain looks promising, too, I'll send this to him as well
[12:23] <pitti> jjardon: right, I know, but still needed for brightness support on some hardware
[12:23] <jjardon> pitti, si, the problem is in graphics drivers?
[12:23] <jjardon> s/si/so
[12:23] <ogra> pitti, well, you can also use a prebuild toolchain from codesourcery ... but if you do more than kernels it gets hairy
[12:24] <ogra> since you need to build every piece of the build deps
[12:24] <slangasek> pitti: step 1) implement multiarch! :)
[12:24] <pitti> jjardon: yes, and kernel; e. g. many nvidia cards need smartdimmer, and the kernel doesn't provide a standard API for those, so userspace has to hack around
[12:25] <ogra> slangasek, qemu-static-$arch FTW :) use chroots ;)
[12:25] <lg> pitti, i've done some cross compiling in the openembedded environment. it seems like it was designed to 'take care of the deps' for you
[12:25] <jjardon> nvidia closed or open source drivers?
[12:25] <slangasek> ogra: pff, chroots
[12:25] <ogra> slangasek, i dont see multiarch->arm happening soon :)
[12:25] <ogra> or multiarch ppc
[12:25] <pitti> ogra: right, I think a qemu-arm-static chroot is pretty rad
[12:25] <lg> cjwatson, got an error installing the latest karmic
[12:26] <slangasek> ogra: um, it will happen the same time as the rest of multiarch
[12:26] <ogra> pitti, yeah, sadly still has issues ... and doesnt really help complier speed ...
[12:26] <slangasek> (which is not in karmic, unfortunately
[12:26] <slangasek> )
[12:26] <pitti> jjardon: I don't actually think it matters
[12:26] <lg> cjwatson, "An error occurred while installing packages: E:Sub-process dpkg returned an error code (1)" etc.
[12:27] <cjwatson> lg: doesn't sound grub-related; can I see the full logs?
[12:27] <lg> cjwatson, this was at ~119%
[12:27] <ogra> slangasek, hmm, how would that work without translation layer if your CPU syscalls differ as much as between x86 and armel
[12:27] <pitti> jjardon: thanks for your upstream patch, though; so if we really need some day, we could disable support for it
[12:27] <lg> cjwatson, sure
[12:27] <cjwatson> lg: *cough* yeah, the progress percentages are apparently a bit broken right now
[12:27] <cjwatson> ogra: binfmt_misc plus qemu?
[12:28] <cjwatson> that's the standard handwavy answer for this anyway ...
[12:28] <ogra> cjwatson, well, so what i do with qemu-arm-static already then
[12:28] <lg> cjwatson, got the same error again at 126%, but it appeared to have successfully done grub-install
[12:28] <slangasek> ogra: no, because you don't have to have a full chroot and run all the executables under emulation
[12:29] <slangasek> so you get about a mumble percent speed-up from being able to run a bunch of stuff natively
[12:29] <ogra> slangasek, yeah, i know, thats what qemu-arm-static already does ... but it *additionally* ships a wrapper to debootstrap that copies the static binary into a chroot if you build one
[12:30] <ogra> it registers with binfmt_misc and all that but for a native build env its better to have a clean chroot
[12:30] <ogra> which is why i added the debootstrrap wrapper script to the package as well
[12:30] <ogra> -r
[12:31] <lg> cjwatson, at the end it gave 'installation complete' and now its rebooting. can i still get at the logs?
[12:31] <cjwatson> lg: they should be in /var/log/installer/ after installation
[12:31] <lg> ok
[12:32] <cjwatson> does anyone know where the "Loading, please wait" message comes from while grub is booting the kernel? I'd love to get rid of it, but for the life of me I can't actually find it anyway
[12:32] <cjwatson> anywhere
[12:32] <ogra> cjwatson, isnt that initramfs ?
[12:32] <slangasek> cjwatson: grub 1 or 2?
[12:33] <cjwatson> slangasek: 2
[12:33] <Keybuk> cjwatson: top of initramfs
[12:33] <ogra> /usr/share/initramfs-tools/init
[12:33] <cjwatson> aha, good call
[12:33] <Keybuk> wing-commander scott% grep -n Loading /usr/share/initramfs-tools/init
[12:33] <Keybuk> 3:echo "Loading, please wait..."
[12:33] <cjwatson> didn't even think to look there
[12:33] <cjwatson> shall we just have that check the quiet flag?
[12:33] <lg> cjwatson, on boot  the checkinig root file system failed. superblock last mount time is in the future.... unexpected inconsistency: run fsck manually, root fs is mounted in read-only mode... mantenance shell
[12:34] <ogra> btw, while i have all people that might be intrested in that here, how about modularizing casper a bit ?
[12:34] <cjwatson> lg: right, we know about that one - run fsck manually as it directs (you'll need to tell it the device to use), then exit the shell and let it reboot
[12:34] <ogra> currently all casper-bottom scripts contain all hacks for all falvours we have
[12:34] <lg> ok
[12:34] <ogra> *flavours
[12:34] <Keybuk> ogra: I'd be interested in making casper work with dracut ;)
[12:34] <ogra> which means a lot of unneeded filesystem acesses on already slow media
[12:35] <cjwatson> I confess to not really being interested
[12:35] <ogra> i would like to have a casper-ubuntu, casper-xubuntu etc setup that contains the flavour specific scripts
[12:35] <ogra> and only dumps in place whats really needed for a live flavour
[12:36] <ogra> i see 2min boots on armel and see a lot of filesystem accesses i dont really need
[12:36] <ogra> (2min for the livefs)
[12:36] <Keybuk> ogra: sounds like a UDS-L spec to me
[12:36] <ogra> beyond that casper carries a huge amount of old cruft that should really see a cleanup
[12:36] <ogra> Keybuk, yep, that was my idea
[12:37] <Keybuk> I'll bring the Proton Pack
[12:37] <slangasek> Keybuk: do you have some time when you could explain /lib/udev/{pci,usb}-db to me?
[12:37] <ogra> heh
[12:37] <ogra> another thing i'd love to do would be to decouple the live squashfs from /lib/modules
[12:37] <Keybuk> slangasek: don't they just parse pci.ids and usb.ids ?
[12:37] <lg> cjwatson, on reboot, the session icon is not available :/
[12:37] <slangasek> Keybuk: yes - why in God's name are they doing this?
[12:38] <cjwatson> lg: session icon?
[12:38] <slangasek> Keybuk: i.e., why is it udev's job to import a text database into its environment for use by third-party programs?
[12:38] <Keybuk> slangasek: to generate comments
[12:38] <ogra> splitting it in two squashfs mounted stacked ... so we only need one generic file plus one for the modules dir
[12:38] <lg> cjwatson, on the login screen.
[12:38] <lg> cjwatson, but i guess this is not the final product yet
[12:38] <cjwatson> lg: sorry, I'm missing something, what session icon were you expecting?
[12:39] <lg> cjwatson, well i see a red x in front of the "session:" label so i figure the icon link is bad
[12:39] <Keybuk> slangasek: basically HAL replacement stuff really
[12:39] <cjwatson> lg: ah - well, I can't offer help with desktop-level issues, my main interest is that it managed to boot, which it does seem to have done :)
[12:39] <slangasek> Keybuk: oh?  comments where?  (the reason I care about this is because udev is violating the FHS by assuming /usr is available when it runs this stuff, and I'm trying to figure out how serious it is)
[12:39] <cjwatson> lg: best just file a bug about that sort of thing
[12:40] <Keybuk> slangasek: various places
[12:40] <Keybuk> slangasek: aren't those files in /var/lib/misc? :)
[12:40] <ogra> cjwatson, btw, whats the status of usplash wrt live images ? i guess we'll keep it there ?
[12:40] <lg> cjwatson, you want /var/log/installer/syslog?
[12:41] <Keybuk> they seem to move back and forth between /usr and /var depending on which way the wind is blowing
[12:41] <slangasek> Keybuk: meh, /var is also allowed to be a separate partition, so it's still an FHS violation
[12:41] <slangasek> Keybuk: also, for further enjoyment, see strings /lib/udev/pci-db |grep ids
[12:41] <slangasek> I'm pretty sure that's not the PCI id db
[12:41] <cjwatson> ogra: I don't know
[12:42] <cjwatson> lg: yeah
[12:42] <cjwatson> lg: BTW, anything involving /var/log/installer/syslog is a separate bug from that missing session icon ...
[12:42] <Keybuk> but you're right that udev shouldn't be accessing files in either of those places
[12:42] <Keybuk> sure iz buggy
[12:42] <lg> cjwatson, yes i see. i just thought i would mention it :P
[12:42] <cjwatson> that's fine
[12:43] <cjwatson> ogra: live images aren't really a target for the boot performance work, to the best of my knowledge; I don't know about boot experience
[12:43] <cjwatson> but since the latter kind of depends on the former ...
[12:43] <lg> cjwatson, http://pastebin.com/f2b7b0677
[12:43] <ogra> yeah
[12:43] <slangasek> Keybuk: well, I don't care if udev accesses them, as long as nothing else further up /relies/ on udev having been able to access them ;)  so I'm wondering if it's just cosmetic, or if we need to move these databases to /lib (blech), or if I can persuade someone that this architecture is fubar and things that want text strings should bloody well fetch them elsewhere instead of expecting udev to have it
[12:43] <Keybuk> slangasek: looks like it's all HALsectomy stuff
[12:44] <ogra> i just want to know if i need to special case armel somehow ... we now have usplash working
[12:44] <ogra> and the boot in live as well as instealled systems is slow enough to validate keeping usplash all over the place
[12:44] <cjwatson> lg: yecch, openoffice.org bug, no idea what that is
[12:44] <jjardon> pitti, Do you know the video drivers that still not support XBACKLIGHT? maybe we can file bugs for this
[12:45] <cjwatson> lg: can you please report a bug on openoffice.org, attaching that syslog and pointing to the bit in it where openoffice.org-filter-binfilter fails?
[12:45] <sgallagh> mathiaz: ping
[12:45] <cjwatson> lg: oh, wait, there might already be one
[12:45] <pitti> jjardon: not exactly, but I guess everything except intel and perhaps nouveau
[12:46] <lg> cjwatson, i got about 3 other errors during the install as well
[12:46] <pitti> jjardon: Richard would know better, I don't really know this I'm afraid
[12:46] <lg> cjwatson, oh hmm, i guess they were all from openoffice
[12:46] <cjwatson> lg: there are a couple of *similar* existing bugs but they aren't quite the same; I think it would be best to report a fresh one
[12:46] <lg> cjwatson, ok sure
[12:46] <cjwatson> bug 423588, bug 423249
[12:47] <jjardon> pitti, ok, I'll take a look. Richard, the g-p-m devel?
[12:47] <lg> cjwatson, lets see if i can remember my launchpad credentials
[12:47] <pitti> jjardon: right
[12:47] <cjwatson> lg: all your dpkg errors were from the installer repeatedly trying to hammer openoffice.org-filter-binfilter into place and failing, at least
[12:47] <slangasek> Keybuk: ok, so you haven't seen any discussions about this stuff specifically?  any idea where I need to look to chase this up?  (Md said I should post to linux-hotplug, but I'm hoping to get some context first)
[12:48] <jjardon> pitti, great, I'll ast him then, thank you!
[12:48] <Keybuk> as in, udev has to have it, because the things further up might not have permission to look it up themselves
[12:48] <Keybuk> also looks like udev tries to use them to decide things about sound cards
[12:48] <Keybuk> which is obviously not going to work when /usr or /var are separate
[12:48] <cjwatson> Keybuk: does http://paste.ubuntu.com/264016/ look potentially OK to you, for the clock problems?
[12:48] <cjwatson> still need to test that
[12:49] <slangasek> Keybuk: I don't follow... surely udev could give the further-up-bits the ID instead of the text string, and the file to do their own lookups should be world-readable?
[12:49] <slangasek> (a root-only pci.ids seems like an uninteresting use case)
[12:51] <slangasek> /lib/udev/rules.d/78-sound-card.rules> meh, lovely
[12:51] <Keybuk> slangasek: no, I had to look it up when you mentioned it
[12:51] <Keybuk> so linux-hotplug would be a good place to start
[12:51] <Keybuk> slangasek: yes, though oddly udev doesn't do that because the id is in the sysfs tree ;)
[12:51] <Keybuk> I think it's more than udev matches on this stuff itself
[12:51] <Keybuk> cf. sound cards
[12:51] <Keybuk> pitti might know a bit more about this stuff since it probably touches ACLs or DeviceKit
[12:51] <Keybuk> but it not, linux-hotplig
[12:51] <Keybuk> cjwatson: that looks right
[12:51] <Keybuk> cjwatson: though maybe UTC=--localtime in the other case
[12:51] <Keybuk> cjwatson: since whether hwclock defaults to localtime or utc depends largely on the time of day ;)
[12:51] <slangasek> pitti: ^^ hi, what can you tell me about this udev madness in connection with HALsectomy? :)
[12:51] <pitti> slangasek: just reading scrollback
[12:52] <slangasek> ok :)
[12:52] <cjwatson> Keybuk: mm, right
[12:52] <pitti> slangasek: hm, what was the original question?
[12:52] <cjwatson> Keybuk: (literally, probably!)
[12:53] <slangasek> pitti: why is udev upstream doing mad things that violate the FHS?
[12:53] <slangasek> :)
[12:53] <pitti> slangasek: do you expect a technical answer to that? :-)
[12:53] <slangasek> pitti: /lib/udev/{usb,pci}-db look in /usr (or /var) for databases and suck that information into their environment - that's an FHS violation, and it needs fixing
[12:53] <pitti> slangasek: what is it, requiring pci.ids and usb.ids from /usr to work?
[12:53] <slangasek> yes
[12:53] <pitti> ah
[12:54] <slangasek> (separately, our build of pci-db is amusingly broken, and only looks at the usb database)
[12:54] <pitti> I wouldn't mind having them in /lib
[12:54] <cjwatson> (I can think of at least one program in the archive which is (a) not explicitly a calendaring application and (b) whose behaviour actually does depend on the phase of the moon)
[12:55] <pitti> not that it matters much, I suppose; did anyone actually try running ubuntu with a separate /usr?
[12:55] <Laney> nethack?
[12:55] <pitti> or, rather, a separate /var
[12:55] <cjwatson> Laney: that was the one I had in mind, yes :)
[12:55] <lg> cjwatson, isnt that 423588 the same bug?
[12:56] <slangasek> pitti: er, I have a separate /usr here.  *both* are supported configurations under the FHS, and cjwatson just did extensive work in jaunty to support split /usr
[12:56] <cjwatson> lg: that's a preinst failure, but your failure's in the postinst
[12:56] <Keybuk> cjwatson: I'd probably add --noadjfile to match hwclock.sh stop too
[12:56] <Keybuk> pitti: yes
[12:56] <Keybuk> pitti: it's part of my standard test set due to /var/run and /var/lock
[12:56] <pitti> slangasek: however, even if /usr isn't available on early boot, I understood that a later udevtrigger should coldplug everything again, and thus get the DB populated
[12:56] <Keybuk> pitti: we don't *do* a later udevtrigger
[12:56] <lg> cjwatson, ah right, gotcha. filing report now
[12:56] <cjwatson> lg: so it's technically slightly different although the cause may be the same; I don't know enough about OOo to tell
[12:56] <pitti> Keybuk: ah, I thought that was kay's explanation
[12:56] <cjwatson> Keybuk: right
[12:56] <pitti> anyway, I think we have a bug for that
[12:56] <slangasek> pitti: nope, even if there was a later udevtrigger, it would happen before !root filesystems were mounted
[12:56] <pitti> let me look
[12:57] <Keybuk> pitti: I'm not adding 5s (average udevtrigger time) to the boot just to populate the udev db with silly strings from pci.ids ;)
[12:57]  * slangasek grins
[12:57] <cjwatson> Keybuk: though /etc/adjtime written in d-i won't be preserved across reboot anyway
[12:57] <Keybuk> cjwatson: you right it in the target
[12:57] <Keybuk> cjwatson: write even
[12:57] <cjwatson> good point
[12:57]  * Keybuk will bbiab
[12:57] <pitti> Keybuk: ah, I think that's why I originally filed bug 372241
[12:57] <pitti> slangasek: ^
[12:57] <pitti> time to reopen then?
[12:58] <slangasek> pitti: sounds like it
[12:58] <pitti> I reopened it
[12:58] <pitti> and reassigned to udev
[12:58] <evand> cjwatson: is there a trick to getting into the grub menu when using kvm SDL?  Neither shift nor escape is working for me.
[12:58] <pitti> uh, where did Keybuk go
[12:59] <pitti> slangasek: so, since not even /lib will help us, it seems we should copy them into the initramfs?
[12:59] <cjwatson> evand: hmm, I'm sure it *did* work
[12:59] <slangasek> pitti: meh, that appeals to me even less than copying it to /lib
[12:59] <slangasek> pitti: I still think the architecture is wrong
[12:59] <pitti> slangasek: but we don't have /lib during initramfs?
[13:00] <slangasek> pitti: correct
[13:00] <pitti> slangasek: so what is the actual problem that we have with this?
[13:00] <slangasek> but IMHO, udev shouldn't be in the business of translating PCI/USB IDs to strings for the benefit of random other parts of the stack
[13:00] <pitti> seems that we are just potentially missing some ID_ strings?
[13:00] <pitti> they aren't guaranteed to be available at all
[13:00] <slangasek> pitti: Keybuk noted that /lib/udev/rules.d/78-sound-card.rules behaves differently as a result of some of those strings
[13:01] <pitti> if a rule needs them, it needs to call usb_id itself anyway
[13:01] <slangasek> well, yes, but some of those rules are going to be triggered before the filesystem is there
[13:01] <cjwatson> there's a comment above those rules as it is saying that they're ugly. maybe now is the time to redesign them
[13:02] <pitti> slangasek: hm, it would seem more robust to me to change that to use IDs, not strings?
[13:02] <slangasek> pitti: I agree - but that's not done yet, and I don't know what else upstream was expecting to use this stuff for
[13:02] <slangasek> pitti: hence, hoping your halsectomy work provided insight
[13:03] <pitti> so I guess this is a question what we actually expect from udev
[13:03] <cjwatson> evand: that's a bug, sorry, I'm not sure how to address it immediately
[13:03] <pitti> if we want reliable ID_* {usb,pci}_id strings, we need to copy the maps into initramfs
[13:03] <evand> cjwatson: no worries, I can work around it with a live CD
[13:03] <pitti> if we don't want to guarantee this, we need to fix the udev rules
[13:03] <slangasek> pitti: oh, heh - also, the rules that use {usb,pci}-db aren't in the initramfs either
[13:03] <pitti> or, as a compromise, call udevtrigger later on
[13:03] <slangasek> so those rules only run after we're on the rootfs
[13:04] <pitti> ah
[13:04] <pitti> but then the devides are already there
[13:04] <pitti> and the rules won't be triggered at all
[13:04] <pitti> would it help to add sth. like udevadm trigger --subsystem=audio to the alsa init script then?
[13:05] <pitti> bbiab, pizza is ready
[13:05] <lg> cjwatson, #423673
[13:05] <slangasek> pitti: I don't remember what it is now, but I think there's another interface, /not/ udevadm trigger, that tells udev to run the new rules
[13:05] <lg> bug 423673
[13:06] <lg> cjwatson, there was also a crash of some sound daemon after booting up
[13:07] <slangasek> pitti: anyway - bug is open now, we can figure it out from here; back to alpha5 with me
[13:07] <lg> cjwatson, xfce volume daemon closed unexpectedly
[13:10] <lg> cjwatson, i'm going to get some sleep. i'll idle for a while so feel free to msg me if you need to
[13:11] <john280z> Running X11, my kernel is 2.6.31-5   how to force upgrade to 2.6.31-9?
[13:11] <cjwatson> lg: ok, just for the record, anything after grub booting successfully I'm going to suggest that you file bugs :)
[13:11] <cjwatson> lg: I'm not an XFCE developer or anything
[13:11] <lg> ah okk
[13:12] <lg> well then thanks for your help in getting grub booting successfully :]
[13:58] <hdon> maybe this is a weird place to ask, but how can i get sort(1) to order things like strcmp() does? by default it seems to ignore underscores
[13:59] <ion> LC_ALL=C sort perhaps
[13:59] <hdon> i tried -g (--general-numeric-sort) and -n (--numeric-sort) but neither seems to be what i want (and their man page doc strings are a little ambiguous)
[13:59] <hdon> ion: i'll try
[13:59] <hdon> ion: that worked, thanks :)
[13:59] <slangasek> (or LC_COLLATE=C, more specifically)
[14:01] <hdon> slangasek: also correct :)
[14:01] <ion> LC_ALL=C is a generic “make locales not affect this program” spell. For sort, the LC_COLLATE part is relevant, but for something else, you might want it to print strings in English. Easier to do LC_ALL=C sort, LC_ALL=C the-other-program instead of e.g. LC_COLLATE=C sort, LC_MESSAGES=C the-other-program. YMMV, of course. :-)
[14:02] <ion> I wonder if LC_ALL=C overrides the LANGUAGES GNU extension?
[14:03] <slangasek> ion: locale(7)
[14:03] <ion> Thanks
[14:04] <hdon> ion: no worries. we generate a symbol table using the C preprocessor to define members of a struct array. one of those steps is sort(1), and it bit me because bsearch() depended on that table being sorted using the C locale ;)
[14:06] <cjwatson> I just put LC_COLLATE=C in my shell startup files
[14:06] <cjwatson> though of course I do have to remember about that if I'm writing scripts for other people
[14:16] <hdon> lol, "bsearch() depended on C locale"
[14:16]  * hdon sighs
[14:30] <superm1> slangasek, yeah i saw before i headed to bed, i gave it a quick look and it's looking better.  i'll have a detailed report up on the  tracker later this morning, and hopefully some other guys will have a look later today too
[14:30] <slangasek> superm1: ok
[14:35]  * cjwatson is up to five outstanding patches for grub2 and a sixth on its way. hurry up bzr import ...
[14:38] <seb128> jdstrand, you said that this apparmor profile thing should be easy and not create issues? ;-)
[14:38] <seb128> jdstrand, couldn't we just allow any /usr/bin binary?
[14:40] <seb128> it seems suboptimal to have to list every email client, web browser, etc
[14:40] <slangasek> seb128: it's not really a sandbox then if it's allowed to execute any binary in the path
[14:41] <cr3> pitti: hi there, do you happen to know of apport symptoms other than "storage" which I could look at?
[14:42] <seb128> slangasek, well if somebody manage to change /usr/bin you are screwed anyway no?
[14:42] <pitti> cr3: not right now, sorry; bryce is currently preparing one for X, and the totem package hook has some symptom-like Q&A game for sound
[14:42] <slangasek> seb128: er, the point is that there are likely to be things in /usr/bin that an attacker could use to achieve arbitrary code execution
[14:43] <seb128> slangasek, I don't like much having to play catching up with any email client users might be running
[14:43] <cr3> pitti: ah, so I should definately implement ui_question_something
[14:43] <seb128> or any web browser they can use
[14:43] <cr3> pitti: I've already improved apport integration in checkbox last night by providing more details in the reported bug about the test that failed as well as tagging the report accordingly
[14:44] <cr3> pitti: so symptoms will be my next target for integration
[14:44] <slangasek> seb128: that's a much easier proposition than trying to pick off all the programs in /usr/bin that it's dangerous to run
[14:44] <seb128> slangasek, and the issue is trickier for print preview since the command can be set using an environment variable
[14:45] <seb128> slangasek, ie we can't known in advance if users are going to tweak that
[14:45] <pitti> cr3: I guess, once they are implemented, checkbox could just call them to figure out why a test is failing?
[14:46] <seb128> slangasek, well clicking on a url in a pdf is no much different from clicking on an im client, web browser, irc client, etc
[14:46] <slangasek> seb128: hum, sounds like something of a design flaw in the print preview to me; but I don't know enough about this to really comment intelligently
[14:47] <cr3> pitti: perhaps, the only problem I can't seem to solve right now is that I would like to pick a symptom based on the current test context. so, if the user was testing audio, I would find it unfortunate to present storage related questions
[14:47] <seb128> slangasek, are we going to try to lock every desktop application this way or is there a reason we consider evince as weaker
[14:47] <pitti> cr3: right, that's what I meant; you should then call "ubuntu-bug sound" directly, not have ubuntu-bug ask the user for a symptom
[14:48] <slangasek> seb128: ultimately, yes, I think the security team wants full apparmor profiles for all the desktop apps :)
[14:48] <ogra> bah
[14:48] <seb128> slangasek, ideally we need a better way that listing all email clients in every profile then
[14:48] <slangasek> seb128: but as for evince, the security team probably looked at poppler's code ;)
[14:48] <ogra> with the latest apparmor update my usplash always times out on armel
[14:48] <ogra> it slows down booting massively here
[14:48] <slangasek> seb128: sure, apparmor has includes (abstractions)
[14:49] <seb128> slangasek, ok, good, I will discuss that with jdstrand then ;-)
[14:49] <seb128> I would prefer to have an include @email_clients in evince
[14:50] <seb128> and this list not in the application but somewhere easier to update
[14:50] <slangasek> seb128: right - /etc/apparmor.d/abstractions/evince itself is already an abstraction, it just needs to be broken down more with more bits kicked over for apparmor to manage centrally
[14:50] <cr3> pitti: where in the code do you map the name "sound" to the proper package(s)?
[14:50] <slangasek> just like /etc/apparmor.d/abstractions/gnome
[14:52] <slangasek> seb128: btw, so far I've found three programs in my /usr/bin that can be used to run arbitrary code, just by glancing at the list ;)
[14:52] <pitti> cr3: the symptom script has to figure that out
[14:52] <pitti> cr3: just like /usr/share/apport/symptoms/storage.py has to figure out whether it's linux, udev, devkit-disks, or gvfs
[14:52] <seb128> slangasek, urg, I don't discuss apparmor to not be a good thing, it's just trickier than expected to get that profile right there
[14:53] <slangasek> right, understood
[14:55] <cjwatson> slangasek: programs> awk perl python?
[14:55] <slangasek> cjwatson: strace ltrace ksu
[14:55] <slangasek> setarch
[14:55] <slangasek> :)
[14:56] <cjwatson> man
[14:56] <cjwatson> indeed probably anything with a pager
[14:56] <cjwatson> env
[15:03] <cr3> pitti: I thought that if I passed "sound" to ubuntu-bug, it would look for the corresponding file under /usr/share/apport/symptoms but there's no such file. so, how does apport map a name such as "sound" to a package?
[15:04] <pitti> cr3: it doesn't; someone needs to write a sound symptom script first
[15:05] <cr3> pitti: heh, thanks for the clarification, at least my understanding seemed to be alright :)
[15:05] <pitti> cr3: it's not that magic, sorry :/
[15:05] <cr3> pitti: I'll try to get komputes to contribute such a script, he has a passion for audio
[15:05] <pitti> nice
[15:12] <jdstrand> seb128: hi! well, I didn't think the apparmor stuff was too difficult for you, I've fixed all but the last dh issue ;)
[15:12] <jdstrand> seb128: but seriously, I know what you are getting at
[15:12] <seb128> jdstrand, oh, it's not "difficult", I just have the feeling we will play catching up for ever
[15:12] <jdstrand> seb128: slangasek pretty much represented the security team's position on the matter
[15:12] <seb128> jdstrand, there is always a new email client, etc
[15:13] <jdstrand> seb128: evince was targetted due to the massive CVE counts in poppler (and xpdf)
[15:13] <jdstrand> seb128: that is the nature of apparmor profiling I'm afraid
[15:13] <seb128> jdstrand, I'm wondering if it wouldn't be easier to maintain those list out of evince
[15:13] <seb128> would avoid to rebuild the software each time we want to tweak the profile
[15:13] <jdstrand> seb128: sure we can, and probably will once somethng other than evince is using it
[15:13] <seb128> would avoid to rebuild the software each time we want to tweak the profile, especially after freezes
[15:14] <jdstrand> seb128: well, we have to rebuild *something* each time
[15:14] <seb128> well, rebuilding data packages is usually no issue
[15:14] <seb128> ie we can do that late
[15:14] <seb128> where rebuilding code can lead the compiler changes issues, toolchain issues, etc
[15:14] <jdstrand> seb128: apparmor abstractions are built in the apparmor package, which is a binary
[15:14] <seb128> ok
[15:15] <jdstrand> maybe we can restructure that, that is an interesting point
[15:15] <jdstrand> seb128: I did plan to break out some of that into an abstraction some time, but like I said, it was the only one using it so I just put it there
[15:16] <seb128> jdstrand, anyway I will look at the documentation soon so I can do the change to the profile myself for the next changes
[15:16] <seb128> I just wanted to have a grasp of what you guys do first and I was on vac
[15:16] <seb128> thanks for doing the first round of updates and fixing for this one
[15:16] <jdstrand> seb128: sure, np. I'm glad to help in anyway I can
[15:17] <jdstrand> seb128: keep in mind the following though: /usr/share/doc/evince/README.Debian
[15:17] <seb128> jdstrand, the print preview command can be changed by an environment variable not sure how to address that or if we should
[15:17] <seb128> jdstrand, or if we decide that whoever change that can also tweak the profile
[15:18] <jdstrand> seb128: well, our take on profiling is a) it must work in the default installation and b) it should work in common and standard practice configurations
[15:18] <jdstrand> this is for any apparmor profile
[15:18] <jdstrand> seb128: if people start changing their system radically, we have to draw a line
[15:18] <seb128> ok, fair enough
[15:19] <jdstrand> seb128: for example, launching mutt as the email handler in gnome-terminal is supported
[15:19] <jdstrand> (it is gnome after all)
[15:19] <jdstrand> seb128: but launching mutt in an xterm or konsole is not, but I adding commented out sections in the profile that people can use if desired
[15:20] <jdstrand> (due to the reduced security stance)
[15:20] <seb128> ok
[15:20] <jdstrand> seb128: I'm happy to add an common previewers
[15:21] <seb128> jdstrand, I don't think there is any out of evince itself, they just let the option for other desktop and non linux system I think
[15:23] <jdstrand> seb128: I'm not sure I fully understand. /usr/bin/evince* are confined. if an environment setting make something call them, then everything should be ok. if they honor an environment variable for calling out other stuff, then we may need to tweak the profile if it is a common configuration
[15:24] <cjwatson> perhaps a long-term approach for evince would be to privilege-separate the PDF handling into a separate process that could be confined separately from the graphical interface
[15:24] <cjwatson> obviously an upstream kind of thing
[15:25] <jdstrand> I'd certainly be happy with that :)
[15:25] <seb128> jdstrand, the print preview comes from gtk which calls evince (default choice)
[15:26] <jdstrand> seb128: ah, then if the gtk option is changed, evince is not used so no problem, no?
[15:27] <seb128> jdstrand, but that's a gtksetting and kde could set kpdf or something there
[15:27] <seb128> jdstrand, well if you run evince under kde and do print preview it might start kpdf to do the preview
[15:27] <seb128> since gtk will start whatever the setting says to start
[15:28] <seb128> (I don't think kde tweak that right now though but I didn't check)
[15:28] <seb128> it's probably not an issue right now
[15:28] <jdstrand> seb128: we can certainly test that configuration, but using evince instead of kpdf but wanting kpdf as the previewer sounds like an uncommon configuration?
[15:28] <seb128> I think we should just wait for a potential bug report to see if somebody tweak that value
[15:29] <jdstrand> seb128: AA profile SRUs are typically no brainers
[15:29] <seb128> ok, so let's not worry about this one
[15:31] <jdstrand> seb128: honestly, I've been pretty happy with the number of bug reports. Overall, quite smoothe (I realize you probably weren't happy with the bugs that came in, but I was expecting it ;)
[15:32] <jdstrand> seb128: please, let me know if I can assist with this at all. I like the idea of a separate profiles data package
[15:32] <seb128> jdstrand, I'm not unhappy, I just fear that the email and web browser list turns to a catching up game
[15:32] <seb128> ie epiphany-webkit is not listed there
[15:32] <seb128> and I guess several other email clients users are running
[15:33] <jdstrand> seb128: if you've got a list otoh, give it to me and I can add them
[15:33] <seb128> jdstrand, having those email client and webbrowser lists not in the application would be nice
[15:33] <jdstrand> seb128: I can move those out
[15:33] <seb128> jdstrand, I think I will start doing the profile tweaks without bothering you now
[15:33] <seb128> jdstrand, you can stop watching evince bugs, I will Cc you when needed
[15:34] <seb128> jdstrand, that would be nice, I think it's going to be useful in other applications over time anyway
[15:34] <jdstrand> seb128: did you upload ubuntu8?
[15:35] <seb128> jdstrand, no, alpha freeze in effect
[15:35] <seb128> jdstrand, I think I changed the target to karmic by mistake though
[15:35] <seb128> you can do changes to it if you want, I will upload later today
[15:35] <jdstrand> seb128: ok, let me prepare ubuntu8 and I'll upload it and apparmor with the email clients and browsers pulled out
[15:35] <jdstrand> seb128: or I can ping you
[15:35] <seb128> jdstrand, thanks!
[15:35] <jdstrand> (whichever)
[15:36] <seb128> jdstrand, feel free to upload I did the only change I wanted to do there
[15:36] <jdstrand> ok, I will upload
[15:36] <jdstrand> seb128: np! thanks for the feedback :)
[15:38] <jdstrand> seb128: btw, once I move the email and browsers stuff out of evince, you can then reassign the bug to apparmor rather than evince, as these things come up
[15:39] <jdstrand> s/the bug/the future bugs/
[15:39] <seb128> jdstrand, ok, will do!
[15:39] <jdstrand> (for email and browsers that is ;)
[15:41] <jdstrand> seb128: fyi-- the way the evince* profiles are designed is that I created an abstraction/evince file that the profiles defined in /etc/apparmor.d/evince all share
[15:41] <jdstrand> seb128: as I'm sure you've seen, the evince package ships both the /etc/apparmor.d/usr.bin.evince file and the /etc/apparmor.d/abstraction/evince file
[15:42] <jdstrand> seb128: /usr/bin/evince* are all set in /etc/apparmor.d/usr.bin.evince
[15:42] <jdstrand> seb128: as always, feel free to ask me or anyone on the security team if you have any questions
[15:42] <jdstrand> :)
[15:42] <seb128> jdstrand, right I've seen there was 2 files but I didn't try to understand the role for each one yet
[15:43] <seb128> thanks for the explanations ;-)
[15:43] <seb128> I will start by reading the documentation
[15:43] <seb128> I will ping you back then if I still have questions
[15:43] <jdstrand> sounds good
[15:43] <seb128> but I expect that should be ok once I've read the wiki ;-)
[15:43] <liw> hrmph, my gnome panels have moved to a different monitor again
[15:44] <seb128> liw, http://bugzilla.gnome.org/show_bug.cgi?id=562944
[15:46] <jdstrand> seb128: regarding bug #423687 can you do 'apport-collect -p evince 423687'?
[15:47] <seb128> jdstrand, what information do you need? just curious
[15:47] <jdstrand> seb128: essentially 'dmesg|grep audit'
[15:48] <seb128> ok, I need to break it again
[15:48] <seb128> how do I undo the aa-complain I did
[15:48] <seb128> aa-enforce ?
[15:48] <jdstrand> seb128: yes
[15:48] <jdstrand> seb128: but it should be in kern.log too
[15:48] <jdstrand> seb128: so you don't need to 'break it' again
[15:49] <seb128> jdstrand,
[15:49] <seb128> [20210.811220] type=1502 audit(1251982341.105:28): operation="exec" pid=25377 parent=25376 profile="/usr/bin/evince" requested_mask="::x" denied_mask="::x" fsuid=1000 ouid=0 name="/usr/bin/evince" name2="/usr/bin/evince//null-e"
[15:49] <jdstrand> seb128: I think that may be from when it was in complain, not enforcing
[15:50] <seb128> let me do that on the bug
[15:50] <jdstrand> seb128: 'cat /var/log/kern.log | grep audit' would be good to see
[15:51] <jdstrand> seb128: if you don't want it in the bug, you can put it on chinstrap or something...
[15:52] <seb128> jdstrand, no issue having it on the bug, let me 30s I just finish something else
[15:52] <liw> seb128, so no solution to the panel thing yet, if I understand correctly
[15:53] <seb128> liw, not that I know about at least
[15:53] <liw> seb128, ack, then I'll wait patiently
[15:54] <mvo> hey liw - sorry that I have not answered your mail yet :(
[15:55] <liw> mvo, no worries
[15:57] <seb128> jdstrand, apport-collect crashes
[15:57] <slangasek> superm1: should I expect mythbuntu amd64 to get testing for A5?
[15:57] <seb128>     value = validated_values[param.name]
[15:57] <seb128> KeyError: 'description'
[15:57] <dpm> pitti: we've got an ubuntu translation meeting in a few minutes and we've got a topic I'd like to ask you a few things about. May I ping you later on when we are discussing it and ask you to shortly join us on #ubuntu-meeting to give us your view? It's about the second point here -> https://wiki.ubuntu.com/Translations/Meetings/2009-09-03 ("Disabling CLI translations for Hebrew")
[15:57] <superm1> slangasek, yes
[15:57] <slangasek> ok
[15:58] <slangasek> superm1: any idea how soon?  I'm expecting everything else to be ready to go in the next hour or so
[15:59] <superm1> slangasek, i'm looking right now since the other guys wouldnt be able to get to it until later today
[15:59] <slangasek> alrighty, thanks
[15:59] <seb128> jdstrand, I've added the 'cat /var/log/kern.log | grep audit' log to the bug let me know if you need something else
[16:00] <jdstrand> seb128: I just reproduced it-- it is print preview from within evince, correct?
[16:00] <seb128> jdstrand, right, just run evince on a pdf, go to file, print, click preview
[16:00] <jdstrand> seb128: ok, easy fix. sorry I missed it. I checked print preview somewhere else which worked
[16:23] <slangasek> superm1: bug #423233 seems to be private, so I have no idea what failed in your mythbuntu test :-)
[16:24] <ogra> toomanysecrets
[16:34] <superm1> slangasek, volume daemon crashed, nothing too big
[16:35] <superm1> i have a feeling its a duplicate of another bug, but i'll let the retracer decide
[16:35] <slangasek> ok
[16:35] <dholbach> Ubuntu Developer Week will start in 25 minutes in #ubuntu-classroom
[16:53] <zyga> mvo: hello, are you working on app-center
[16:55] <mvo> hey zyga - yes I implement it, for the design we have mpt
[16:55] <zyga> I
[16:55] <zyga> 78o
[16:55] <zyga> sorry, kids
[16:55] <mvo> haha
[16:55] <mvo> np :)
[16:56] <zyga> I'd like to ask you about something that has been in my mind since I read about the concept
[16:56] <zyga> the major usability win of app store / itunes is that the user installs applications - not system components
[16:56] <zyga> and they have a property of being _always_ installable, without any dependencies
[16:57] <zyga> have mpt or you considered offering something like this on top of the current apt/dpkg infrastructure/
[16:57] <zyga> this would limit the scope of actions applicable in the "default" interface
[16:57] <zyga> but would reduce all difficult things (packages depending on libraries, shared data, packages conflicting, replacing one another) to zero
[16:58] <zyga> I was thinking about having three pieces of data in the store
[16:58] <zyga> applications
[16:58] <mvo> zyga: no, that would be possible, but a major change in how to package apps. it would basicly be all lsb apps
[16:58] <zyga> I don't mean to change packages
[16:58] <zyga> just the frontent
[16:58] <zyga> and how to present packages to users
[16:58] <zyga> imagine this:
[16:58] <zyga> the user maintains only one thing unless they choose otherwise by enabling true package view
[16:59] <zyga> the list of applications
[16:59] <mvo> oh, I see what you mean. I think this was not yet discussed, a interessting idea
[16:59] <mvo> only present stuff by default that is "safe"
[16:59] <zyga> to be considered "application" you must be a package with .desktop file (or something like that) and depend on some stuff that can be installed without bothering the user
[17:00] <zyga> so if I want to use "k3b" I just install that
[17:00] <zyga> the UI should indicate that K3b needs other "things" but the user should be informed about that more unless he really cares
[17:00] <zyga> the other two concepts would be "libraries and other packages"
[17:01] <zyga> and "services"
[17:01] <zyga> libs and packages would only inform the user about what is truely installed that is not an application package
[17:01] <zyga> the only UI the user would have is "remove the ones I don't need"
[17:02] <zyga> the last stuff would be for services once we can define something like that in the system
[17:02] <zyga> so if I want to install "file sharing for windows aka samba" it would go under services, but that is off the topic
[17:02] <zyga> the central concept change I was thinking about is "dont manage packages"
[17:02] <zyga> "manage applications"
[17:03] <zyga> "show packages with -remote-junk- button"
[17:03] <mvo> zyga: that sounds interessting (and actually not too hard to implement) - I think it aligns iwth the ideas that mpt has
[17:03] <zyga> the problem this obviously has is how to integrate "advanced" mode without remaking synaptic
[17:03] <zyga> and the deep problem of having stuff like virtual packages, conflicts etc
[17:04] <mvo> yeah, once we enter the realm of "all packages" its going to be tricky
[17:04] <zyga> (-common packages containig desktop files, alternatives and the rest of things that are "smart")
[17:04] <mvo> I have not seen a good answer to this yet
[17:05] <zyga> the only thing I can think of is to add _really_ smart UI for each particular use case (like special stuff for virtual packages, special ui for "related packages like -doc and -dev and recommends etc)
[17:05] <zyga> and work with debian to simplify :)
[17:05] <zyga> that's my idea anyway
[17:05] <zyga> I'd love to hear what you and mpt think about it
[17:06]  * zyga is looking for plastic doors to my son's car
[17:08] <zyga> mvo: one more thing
[17:09] <zyga> mvo: if the app store concept really takes off and gains adoption
[17:09] <zyga> mvo: we could create a spec of "application" and evangelize everyone about it
[17:09] <zyga> mvo: _and_ tag packages with X-whatever-is-application
[17:10] <mvo> zyga: yeah, more meta-data is definitely a win
[17:10] <zyga> so this can grow smarter/beyond checking for .desktop files and other hacks and being integrated properly with the package manager
[17:10] <mvo> maybe debtags, I'm not sure what will win
[17:10] <zyga> I'm not familiar with debtags but anything we can have at the lower layer for everyone to use
[17:11] <zyga> applications have other concerns like shared system configuration, per user data, migrations, mime types, url scheme integration etc but I realize this is a one-step-at-a-time approach
[17:11] <zyga> being able to "revert app to default" setting would be a huge step towards PC as consumer electronics vs "unix workstation"
[17:12] <mvo> revert all apps to default? i.e. remove pkgs/settings that are not a standard ubuntu install?
[17:13] <zyga> that would be interesting too but i was thinking about "revert this particular app to default state"
[17:13] <zyga> for example if the user damages configuration
[17:13] <zyga> or would like to revert to default state, whatever that is
[17:13] <zyga> this is actually beyond packaging
[17:13] <zyga> it's also about locating files that applications create that are not "user documents"
[17:14] <zyga> and being able to manage them somehow
[17:14] <zyga> maybe this is not something that the app store could sensibly manage but it could be important from usability point of view
[17:16] <sgallagh> mathiaz: ping
[17:16] <zyga> mvo: on OSX almost every app stores several files in your $HOME, something akin to xdg-dirs
[17:16] <cjwatson> Keybuk: wow, yeah, bug 407428 is totally a udev bug
[17:16] <zyga> mvo: there is an application that allows you to uninstall other application and get rid of that data at the same time
[17:17] <Keybuk> cjwatson: udev bug?!
[17:17] <mvo> zyga: interessting, we would have to have a way to descripe where the app installs stuff
[17:17] <zyga> mvo: it's possible because many system frameworks require apps to have unique id's (reverse domain + name) and require using that to  access stuff
[17:17] <Keybuk> neat
[17:17] <cjwatson> Keybuk: udevd.c:worker_new() blocks a huge pile of signals
[17:17] <cjwatson> and util_run_program etc. never puts them back
[17:17] <Keybuk> my god did that bug go right around the entire system ;-)
[17:18] <zyga> mvo: that's xdg-dirs
[17:18] <zyga> mvo: (just nobody follows it yet)
[17:18] <Keybuk> cjwatson: thanks, can you assign them back then :-))
[17:18] <zyga> mvo: it's really simple stuff like "get preferences for app at pl.suxx.my-app"
[17:18] <cjwatson> done :)
[17:18] <Keybuk> cjwatson: so, I have a bug for you
[17:18] <cjwatson> 15-all?
[17:18] <zyga> so you have to use that id in many common APIs
[17:19] <zyga> right now I don't see this becoming viable with so many frameworks but it's something I keep thinking about
[17:19]  * mvo nods
[17:19] <zyga> if the package data has something like xdg-dirs-name: foo
[17:19] <Keybuk> cjwatson: it's a eglibc bug ;)
[17:20] <Keybuk> http://pastebin.ubuntu.com/264512/
[17:20] <Keybuk> (it might be a gcc bug too)
[17:20] <zyga> then we can guess the app keeps a cache and preference in .cache/foo and .config/foo respectively
[17:20] <zyga> and use that in the UI
[17:20] <zyga> mvo: again it's not perfect but it gets much closer to being usable without changing everything :-)
[17:20] <mvo> zyga: I think it needs to be encoded somewhere in the meta-data, guessing is not good enough, but yeah, its a good feature :)
[17:20] <mvo> zyga: we could add it to the desktop file for now
[17:20] <zyga> the xdg-dir would be encoded
[17:21] <zyga> if it was encoded the app store could assume that the app follows xdg-dirs
[17:21] <zyga> .desktop files are nice because they are package-agnostic and could be integrated upstream
[17:22] <zyga> what is going to be the primary source of data in the app store?
[17:22] <zyga> some custom format or regular apt repo?
[17:22] <mvo> regular apt sources
[17:22] <mvo> with additional meta-data, initially from desktop files
[17:22] <zyga> I see
[17:22] <mvo> hopefully later in a more generic way
[17:23] <mvo> zyga: thanks for all you ideas :) I need to leave for dinner now, but you should pass them to mpt as well
[17:23] <cjwatson> Keybuk: I don't think it can be an eglibc bug; the function declaration matches the standard
[17:24] <Keybuk> cjwatson: well, other than the use of the intermediate typedef
[17:24] <Keybuk> but I'm not sure that should make a difference
[17:24] <cjwatson> I don't think it should
[17:24] <Keybuk> it may well be a gcc bug
[17:24] <cjwatson> it does look like one
[17:24] <zyga> mvo: thanks - I'd love to talk to mpt and you more about this
[17:24] <Keybuk> I'm pretty sure that a function pointer that takes void arguments should be compatible with a function pointer that takes other arguments
[17:24] <cjwatson> C99 <IP_ADDRESS> says that function pointers are implicitly converted to other function pointers
[17:25] <cjwatson> in fact it's a rather more general rule than I expected
[17:25] <cjwatson> let me do a bit more standards-browsing to make sure though
[17:26] <Keybuk> if the standard says this gcc error is correct, then it's definitely a glibc bug
[17:26] <Keybuk> because qsort explicitly suggests alphasort() as exactly the kind of function you should pass to it ;-)
[17:26] <Keybuk> indeed
[17:27] <Keybuk> since qsort() and alphasort() are both, I think, defined by C99
[17:27] <Keybuk> and qsort says a good function is alphasort
[17:27] <Keybuk> and it gives the alphasort prototype as taking dirents
[17:27] <Keybuk> I think that pretty much guarantees that this can't be invalid C99 ;)
[17:27] <Keybuk> unless we found a bug in C99 :p
[17:28] <cjwatson> actually alphasort is mentioned nowhere in C99, and the manual page says it takes const void *
[17:28] <cjwatson> though glibc appears to differ, it's true
[17:28] <Keybuk> cjwatson: oh, are those ones posix?
[17:29] <cjwatson> yeah
[17:29] <Keybuk> quick testing shows that this is not a typdef issue
[17:29] <cjwatson> POSIX.1-2008 at that
[17:29] <Keybuk> gcc doesn't believe that int (*)(const void *, const void *) and int (*)(const char *, const char *) are compatible
[17:29] <Keybuk> let alone anything more complex
[17:33] <Keybuk> err
[17:33] <Keybuk> in fact
[17:33] <Keybuk> const void *a;
[17:33] <Keybuk> char *b;
[17:33] <Keybuk> b = a;
[17:33] <Keybuk> doesn't quite work
[17:34] <Keybuk> oh, no, I'm a numpty - that one works
[17:42] <jcole> good morning everyone
[17:50] <jcole> ive got no response in #ubuntu or #ubuntu+1... can anyone here point me to the reasoning for not including 64bit flashplayer in the next ubuntu release karmic
[17:54] <jcole> are there some closed source bits/drivers that depends on the 32 bit version?
[17:59] <cjwatson> Keybuk: ok, I got some C standards lawyering help
[17:59] <Keybuk> what do they say?
[17:59] <cjwatson> Keybuk: function pointers are convertible only if each of their parameters have compatible types (<IP_ADDRESS>(15))
[18:00] <cjwatson> Keybuk: contrary to my assumption, thingy * and void * are not in fact compatible types
[18:00] <Keybuk> right
[18:00] <Keybuk> why are thingy * and void * not compatible?
[18:00] <Keybuk> isn't that the entire point of void * ?
[18:00] <cjwatson> Keybuk: the reason you can assign one to the other freely is only that there is a special exemption for assignment (<IP_ADDRESS>)
[18:01] <cjwatson> AFAICS anyway
[18:01] <Keybuk> actually, I think that's true
[18:01] <Keybuk> I have to cast function pointers if I change void *data to Something *useful
[18:01] <Keybuk> which means this is a glibc bug, right? :)
[18:01] <Keybuk> the prototype of alphasort() is wrong
[18:01] <cjwatson> <IP_ADDRESS>(2) says "for two pointer types to be compatible, both shall be identically qualified and both shall be pointers to compatible types"
[18:01] <cjwatson> <IP_ADDRESS> says that there are no implicit conversions for void
[18:02] <cjwatson> oh, well, it does say you can implicitly convert to void, so I'm not 100% sure
[18:02] <Keybuk> heh
[18:02] <cjwatson> but consensus seems to be that gcc is acting within the standard, so I'm inclined to agree that this is a glibc bug
[18:02] <cjwatson> that just leaves layer 9
[18:02] <Keybuk> gcc breaks glibc DEATHMATCH
[18:03] <cjwatson> I wonder if the best way to do this is to get the manpages maintainer to intercede, since his manual page disagrees with glibc :-)
[18:03] <Keybuk> err
[18:03] <Keybuk> why?
[18:03] <Keybuk> you mean the alphasort() man page maintainer?
[18:03] <cjwatson> right, it's in manpages-dev
[18:04] <cjwatson> and upstream for man-pages is generally doing a fair bit of bug-filing on the kernel, glibc, etc.
[18:04] <Keybuk> this must be a recent glibc or eglibc change
[18:04] <cjwatson> it's in glibc too
[18:04] <Keybuk> though I think it's glibc, because google says F11 is having these issues too
[18:04] <cjwatson> I checked git
[18:04] <cjwatson> one moment and I'll git blame it
[18:06] <cjwatson> git sha-1 eee6b1432794967d4272394dfed1e2b5cca4be39, http://sources.redhat.com/bugzilla/show_bug.cgi?id=9759 - apparently it was to match POSIX.1-2008
[18:06] <cjwatson> http://www.opengroup.org/onlinepubs/9699919799/functions/scandir.html
[18:07] <cjwatson> so if anything that makes it a POSIX bug ...
[18:07] <cjwatson> looks like alphasort is designed for use with scandir, and qsort gets screwed
[18:08] <cjwatson> scandir used to take int (*) (const void *, const void *) but now takes two const struct dirent **
[18:08] <cjwatson> so in short I have absolutely no idea whose problem this is now. :-)
[18:11] <jdstrand> seb128: ok, I have committed the changes to the evince tree and abstracted out all the email clients and web browsers. I then added several abstractions to apparmor and went through Ubuntu Software Center and synaptic looks for all gui and cli browsers and MUAs. I think we should be in better shape
[18:11] <jdstrand> seb128: so that will support the common and even not very common situations
[18:12] <cjwatson> Keybuk: looks like you get to cast or use a wrapper ...
[18:12] <tkamppeter> pitti, hi
[18:12] <Keybuk> cjwatson: disagree
[18:12] <Keybuk> since qsort() explicitly recommends alphasort()
[18:13] <Keybuk> and alphasort() explicitly states it's intended for qsort()
[18:13] <Keybuk> the prototypes should be compatible
[18:13] <jdstrand> seb128: and now other apparmor consumers can benefit (yea)
[18:13] <cjwatson> Keybuk: where's this?
[18:13] <cjwatson> the only thing I see is a SEE ALSO from qsort to alphasort, in POSIX
[18:13] <Keybuk> qsort()s manpage
[18:14] <cjwatson> manual pages are written post-hoc :-(
[18:14] <Keybuk> NOTES
[18:14] <Keybuk>        Library routines suitable for use as the compar argument include alpha‐
[18:14] <Keybuk>        sort(3) and versionsort(3).  To compare C strings, the comparison func‐
[18:14] <Keybuk>        tion can call strcmp(3), as shown in the example below.
[18:14] <Keybuk> so?
[18:14] <Keybuk> I think it's utterly wrong for this to break
[18:14] <Keybuk> this is a fairly fundamental API
[18:14] <cjwatson> I agree, but it's a POSIX bug, glibc is just passing it on
[18:14] <Keybuk> how is it a POSIX bug?
[18:14] <Keybuk> alphasort() isn't *in* POSIX yet
[18:14] <cjwatson> yes it is!
[18:14] <cjwatson> I just gave you the reference
[18:14] <cjwatson> http://www.opengroup.org/onlinepubs/9699919799/functions/scandir.html
[18:14] <Keybuk> ah
[18:14] <Keybuk> well, fix that then
[18:15] <Keybuk> or patch our glibc to work around it
[18:15] <cjwatson> I can see if I can raise it as a POSIX defect or something
[18:15] <Keybuk> indeed
[18:15] <Keybuk> I'd say that since POSIX does see also this, it's recommending it
[18:15] <cjwatson> but until then it's best to leave the libc alone I think
[18:16] <Keybuk> why?
[18:16] <Keybuk> if I broke something fundamental in an API that was recommended widely
[18:16] <Keybuk> and pretty widely used
[18:16] <Keybuk> you would make me revert my breakage
[18:16] <Keybuk> I don't see this is any different
[18:16] <Keybuk> glibc has broken behaviour that was previously recommended
[18:16] <Keybuk> glibc should be fixed now
[18:16] <cjwatson> because changing alphasort's prototype will mean that it's no longer compatible with scandir; changing scandir will mean that application programmers writing code to POSIX will have to change, etc.
[18:16] <cjwatson> it's hardly broken, it's just a cast
[18:17] <cjwatson> we can raise it, but there is no need to panic
[18:17] <Keybuk> I disagree
[18:17] <Keybuk> since there's no typedef defined
[18:17] <Keybuk> it's a workaround for a glibc bug
[18:17] <cjwatson> a wrapper function is easy too, and perfectly traditional for comparison functions given to qsort
[18:18] <Keybuk> there should be no need for a wrapper function
[18:18] <Keybuk> glibc has broken its API
[18:18] <Keybuk> this breakage should be reverted
[18:18] <cjwatson> correct. but it's hardly something to get up in arms about.
[18:18] <cjwatson> a
[18:18] <Keybuk> well, it is
[18:18] <Keybuk> because I'm getting build failures
[18:18] <cjwatson> I agree it's a bug but I think you're overreacting
[18:18] <Keybuk> and if I change the code to match *our* glibc
[18:18] <Keybuk> I get build failures on older glibc
[18:18] <Keybuk> because then the prototypes don't match there either
[18:18] <cjwatson> that means your change is not sufficiently creative
[18:18] <Keybuk> in fact
[18:19] <Keybuk> this breaks jaunty vs. karmic
[18:19] <cjwatson> changing this will just cause knock-on build failures elsewhere; we need to get the standard fixed
[18:19] <Keybuk> we can fix glibc in the meantime
[18:19] <cjwatson> anyway, it's my dinnertime.
[18:19] <Keybuk> while we wait the necessary 5 years for the standard
[18:19] <seb128> jdstrand, excellent, thanks
[18:19] <danielgianni> hi guys, i don?t understand ubuntu event system, example, autofs cdrom automount cdrom but how I get the end of mount event?
[18:19] <seb128> jdstrand, do you upload the changes or do you want me to do that?
[18:20] <jdstrand> seb128: I will, I am building and testing now
[18:20] <seb128> ok, good
[18:20] <cjwatson> something like http://paste.ubuntu.com/264544/ should be entirely sufficient and work on both old and new
[18:20] <cjwatson> err, sorry
[18:21] <danielgianni> HAL seems to me is more confusing than Autofs
[18:21] <cjwatson> http://paste.ubuntu.com/264547/
[18:21] <cjwatson> (tested on both karmic and lenny)
[18:22] <Keybuk> so would a simple 1-line patch to the glibc header file
[18:22] <cjwatson> which would cause other things to fail to build. if that's your standard, then we have total deadlock; therefore I argue that is not really the most productive standard to apply
[18:23] <Keybuk> it's the standard that has been in effect since glibc was introduced
[18:23] <Keybuk> it's the recommended practice in the manpages
[18:23] <Keybuk> glibc should not break this
[18:25] <Keybuk> glibc could always bump its SONAME to indicate it's not API compatible anymore ;)
[18:27] <pitti> slangasek: congrats to alpha-5!
[18:28] <pitti> dpm: oops, sorry, missed your ping; sure, just ask me if you have questions
[18:28] <pitti> hey tkamppeter
[18:32] <pitti> tkamppeter: thanks for the hplip polkit migration!
[18:32]  * pitti chalks it off at https://wiki.ubuntu.com/DesktopTeam/PolicyKitOneMigration
[18:34] <tkamppeter> pitti, there a re-upload will come soon, as it FTBFS, it needs now a dependency on policykit-1.
[18:34] <tkamppeter> pitti, Are both PolicyKits there now in parallel on the CDs?
[18:35] <cjwatson> Keybuk: for the record, I think it would be entirely reasonable for you to respond to a reported API breakage by saying "hmm, interesting, there are some knock-on effects with just reverting that so I'll need to raise it upstream; in the meantime, here's a workaround"
[18:35] <pitti> tkamppeter: yes, we are still transitioning
[18:36] <tkamppeter> pitti, then it is good that I have removed the redundant HP PostScript PPDs from foomatic-db, as they are also in HPLIP.
[18:38] <sbeattie> pitti: are you okay with the patch in bug 401983, or do you want something different?
[18:39] <pitti> sbeattie: nice timing, I was just looking at it
[18:40]  * pitti is on an apport bug cleanup rave
[18:40]  * jdstrand considers filing one
[18:40]  * pitti phears sbeattie's telepathic skillz
[18:40] <pitti> sbeattie: .apport makes sense, it's more neutral than .crash or .txt
[18:41] <pitti> sbeattie: in fact, when reading the description I was about to change ubuntu-bug to accept .txt as well, but this is better
[18:46] <ScottK> pitti: I managed to install bcmwl using jockey from an ISO last night, so whatever it was, I think you fixed it.
[18:46] <pitti> ScottK: good to hear
[18:47] <sbeattie> pitti: cool, thanks.
[18:50] <tkamppeter> pitti, did our new udev rule for the USB printers make it upstream?
[18:50] <pitti> tkamppeter: no, didn't get to discussing it with kay yet
[18:50] <pitti> still on my todo list
[18:59] <jdstrand> seb128: fyi, ubuntu8 uploaded (revno 32)
[19:02] <davmor2> pitti: didn't the auto codec thing get fixed in totem?
[19:02] <pitti> seb128: ^ do you happen to know?
[19:27] <seb128> pitti, no, http://bugzilla.gnome.org/show_bug.cgi?id=591677
[19:27] <seb128> jdstrand, thanks
[19:41] <ulaas> libldb-samba4-0
[20:14] <lordmetroid> Why are some packages consistently being kept back during upgrades?
[20:21] <lordmetroid> Shall I do an update-manager -d now when alpha 5 has been released, to upgrade from alpha 4?
[20:37] <LordMetroid> Sorry if I missed the answer, do I need to update my alpha 4 to alpha 5 using update-manager -d ?
[20:42] <ScottK> LordMetroid: #ubuntu+1 is a better place for that question.
[20:42] <LordMetroid> I see
[20:50] <LordMetroid> What is the purpose of this channel?
[20:52] <ScottK> LordMetroid: Read the topic.
[20:53] <LordMetroid> Yes but what is the difference between this channel and #Ubuntu+1?
[20:53] <LordMetroid> #Ubuntu+1 is support?
[20:53] <ScottK> For people running the development release yes.
[20:54] <ScottK> This is for doing the development.
[20:55] <LordMetroid> ok, thanks
[20:57] <kees> mterry: I hit the rsyslog hang again.  :(  more details in bug 423943
[20:57] <mterry> kees, for the love of
[20:57] <kees> mterry: I think I have a viable guess at the cause and a fix this time (without actually having looked at the code)
[20:58] <mterry> kees, nice.  I'll look at it tomorrow
[20:58] <kees> mterry: cool
[20:58] <mterry> kees, (I mean, I looked at your report, I'll look at it in more depth tomorrow.  :))  thx
[20:59] <kees> mterry: yup, no problemo.  it's just in my VM.  :P
[21:10] <rgreening_> asac: have you seen this? http://en.opensuse.org/KDE/FirefoxIntegration (you probably have... but just in case not)
[21:35] <mattfletcher> hello, i've just dist-upgraded my 9.04 install to karmic alpha and i now have two firefoxes installed. 3.5.2 and 3.0.something. what packages do i need to remove to get just the latest?
[21:37] <mattfletcher> correction, i used update-manager -d, not dist-upgrade
[21:50] <LordMetroid> mattfletcher, #Ubuntu+1 will probably know
[21:58] <taavikko> xorg-server 2:1.6.3-1ubuntu3 brought 183_dont_reset_event_time patch, now I have it on my notification area?
[23:16] <dtchen_> TheMuso: given the bug fixes in the ppa version of pulse, it's worth an FFE. also, i've updated debian/copyright.
[23:19] <dtchen_> liw: thanks (also to everyone i'm omitting) for the zsync addition on cdimage
[23:24] <cjwatson> ogasawara: I don't understand why you reassigned bug 423128 to kbd; I asked cr3 to send those bugs to linux instead, because the test in question is "does changing virtual terminals work?", and it's really quite unlikely that the cause of that is that the chvt binary is broken
[23:24] <cjwatson> ogasawara: it's much more likely that it's because the kernel's virtual terminal subsystem is broken
[23:24] <cjwatson> ogasawara: I know the bugs are rubbish; checkbox is not being very helpful here :-(
[23:26] <ogasawara> cjwatson: ahh, got it.  I think I'd only moved 2 bugs so far.
[23:27] <cjwatson> ogasawara: TBH I suspect there isn't much usable in those bugs - somebody needs to work with Marc to get them improved
[23:27] <cjwatson> dunno, maybe you guys can extract something from them
[23:28] <cjwatson> if you *do* find out that it's due to a broken chvt binary then let me know and I'll take it back :-)
[23:31] <TheMuso> dtchen_: Ok. I am happy to work on that if you haven't started it already.
[23:33] <dtchen_> TheMuso: i have not started it; feel free :-)
[23:37] <TheMuso> dtchen_: ok.
[23:47] <kirkland> does anyone know which signal is being ignored with mask SigIgn: 0x0080
[23:50] <cjwatson> little-endian, that's 7th bit from the bottom, kill -l says SIGBUS
[23:51] <HiGuys> Hey Everyone
[23:52] <HiGuys> Is this the right place to put packaging questions?
[23:52] <cjwatson> err, and forget my "little-endian" term there, that's probably wilfully confusing in this case
[23:52] <cjwatson> HiGuys: #ubuntu-motu is probably better for general mentoring
[23:53] <HiGuys> Ok thanks