[12:58] <jdong> can an apparmor god explain what "kw" is in permissions?
[12:58] <jdong> I can't find a manpage for "k"
[12:58] <jdong> in the documentation I've consulted...
[01:01] <Kmos> jdong: https://bugs.edge.launchpad.net/edgy-backports/+bug/141181 -> can you check this one ?
[01:01] <ubotu> Launchpad bug 141181 in edgy-backports "Please backport ddclient" [Undecided,New] 
[01:02] <jdong> Kmos: in the middle of something currently, can you e-mail me with these bugs?
[01:03] <Kmos> jdong: ok =) thx
[01:08] <Kmos> cya
[01:10] <pwnguin> jdong: i dont even seem to have apparmor running =/
[01:19] <jdong> pwnguin: aww well you should.... it's pretty nice for some things, like I just wrote some profiles for my irssi client and such
[01:19] <jdong> pwnguin: I don't trust my perl abilities not to have a few shell injection capabilities ;-)
[01:26] <pwnguin> jdong: i thought it was installed by default
[01:26] <jdong> it is...
[01:26] <pwnguin> jdong: perhaps its not enabled by default on an upgrade?
[01:26] <jdong> it should be
[01:26] <pwnguin> or perhaps it conflicts with something else i have
[01:27] <jdong> pwnguin: it's not running and spewing cupsd denied messages into dmesg?
[01:27] <pwnguin> nope
[01:38] <CarlFK> someone wana help me collect info for a bug report on gutsy alt installer?  (cuz all I got is "FATAL: Could not load /lib/modules/2.6.22-12-386/modules.dep: No such file or directory" and "can too!")
[02:51] <jdong> pwnguin: hmm playing with apparmor a bit more... and BOY! is skype curious!
[02:51] <jdong> it traverses down all of ~/.mozilla recursively, and also requests to see /proc/1/cmdline for some reason?
[02:54] <Amaranth> jdong: why would it want to know what init is in use?
[02:54] <Amaranth> it's all /sbin/init, no?
[02:54] <jdong> Amaranth: I have no clue
[02:54] <jdong> Amaranth: why would it want to open mode "r" all of my ~/.mozilla files either?
[02:54] <jdong> when skype AFAIK has no web browsing functionality?
[02:54] <Amaranth> it's looking for the skype firefox extension
[02:55] <jdong> Amaranth: ah, interesting...
[02:57] <jdong> so it needs to be able to traverse down /home/*/.mozilla/**/
[03:03] <dobey> it might also parse the cookies?
[03:03] <jdong> dobey: I don't see how tha'ts any of skype's business though
[03:03] <ion_> It might also send anything interesting from ~/.mozilla/** to interested parties. :-)
[03:04] <jdong> ion_: lol call me paranoid but I am worried it wants something with my history and cookies :)
[03:04] <jdong> is there some way of writing an apparmor rule in "inverse"
[03:04] <dobey> jdong: well, the only way to share cookies is to look in each browser's directory for where it stores cookies, currently
[03:04] <jdong> like allow everything in .mozilla.... EXCEPT bookmarks.html, etc
[03:07] <dobey> so basically, deny everything in .mozilla :)
[03:08] <jdong> lol
[03:08] <jdong> deny almost everyhing ;-)
[03:21] <pwnguin> someone else was pointing out that skype was hitting /etc/shadow
[03:21] <pwnguin> a while back. i donno what that was
[03:22] <pwnguin> or maybe it was /etc/passwd
[03:22] <pwnguin> shadow'd be a much scarier thing i think
[03:23] <superm1> pwnguin, yeah there is a post on the skype forums about it
[03:24] <superm1> really i dont see a big deal with hitting /etc/passwd.  It's world readable, so why not.
[03:24] <dobey> probably because it grabs your real name or something from /etc/passwd
[03:24] <dobey> there's nothing wrong with hitting /etc/passwd
[03:24] <dobey> plenty of gnome/kde already do it
[03:24] <dobey> getpwnam ()
[03:24] <dobey> srsly
[03:24] <holycow> the problem really is that its closed source and you can't check WHY its doing all of that
[03:26] <dobey> well
[03:26] <dobey> you can ltrace the app
[03:27] <dobey> and it should show getpwnam () or whatever
[03:27] <dobey> which would give you more clue than "omg! it's opening /etc/passwd!"
[03:27] <dobey> :)
[03:27] <jdong> pwnguin: it only hits /etc/passwd, which is not all that abnormal for something that even does a ls -alh
[03:28] <jdong> [114990.104000]  audit(1191199733.820:5567):  type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/proc/1/cmdline" pid=20237 profile="/usr/bin/skype"
[03:28] <jdong> ^^ that's the last thing I'm REALLY puzzled about
[03:30] <holycow> well if you read up on how skype works ... you'd also note that they already do some shady things to make it just work
[03:30] <holycow> for example to bypass nat types of situatios they exploit a flaw in an rfc of some sort, i forget which one but it has to do with how udp packets are handled
[03:30] <holycow> to establish a 2 way connection outside of the nat
[03:31] <holycow> its pretty clever actually ... some clever people created this product
[03:35] <jdong> holycow: ah the classic person A hammers person B's UDP port, person B hammers person A's udp, in a manner agreed by the two hosts via a 3rd party (skype server) :)
[03:35] <jdong> and soon enough NAT is tricked into thinking it's an established route
[03:37] <holycow> jdong: acutally that sounds exactly what i read about
[03:37] <dobey> heh
[03:37] <holycow> jdong: right exactly
[03:37] <jdong> yep, it's a neat trick :)
[03:37] <dobey> if the hammer doesn't work... use a bigger hammer.
[03:38] <jdong> AFAIK if you mirror the two source-port/dport pairs correctly (one host is mirror of the other) it's brain-dead easy to punch through
[03:38] <holycow> it was a bit eye opening reading that indeed
[03:38] <jdong> some torrenting DHT implementations do the exact same thing
[03:38] <holycow> makes me want to block all udp traffic
[03:38] <holycow> heh
[03:39] <jdong> holycow: meh what services do you run over UDP though? :)
[03:39] <holycow> nothing actually :)
[03:40] <holycow> good poitn
[03:41] <jdong> exactly
[03:41] <jdong> if you did, then it'd behoove you to run a simple iptables firewall on the host with a basic allow-local-subnet, block-everything-else rule
[03:58] <StevenK> Can someone please give-back gimp on i386?
[03:59] <holycow> StevenK: say what?
[04:00] <StevenK> holycow: The i386 builder that was building gimp had a few issues. gimp has apparently been currently building on verdansky for 12 hours
[04:48] <fabbione> morning
[05:01] <bddebian> Heya fabbione
[05:14] <pwnguin> +#include <acl/libacl.h>
[05:14] <pwnguin> any ideas on where to find the package i need to depend on to get that?
[05:14] <StevenK> pwnguin: libacl1-dev
[05:14] <pwnguin> hmm. searching apt-cache for libacl is much shorter than just acl =/
[05:14] <fabbione> pwnguin: http://archive.ubuntu.com/ubuntu/dists/gutsy/Contents-i386.gz
[05:15] <fabbione> pwnguin: zcat that file |grep "fileyouwant"
[05:15] <pwnguin> surely i have a local cache of that?
[05:16] <fabbione> pwnguin: no you don't
[05:16] <fabbione> hey Hobbsee
[07:24] <pitti> Good morning
[07:27] <Hobbsee> pitti!
[07:48] <dholbach> good morning
[07:50] <Hobbsee> morning dholbach!
[07:50] <dholbach> hey Hobbsee
[07:58] <ion_> Hi
[07:59] <pitti> hi ion_
[08:00] <superm1> morning dholbach
[08:01] <dholbach> hey superm1
[08:01] <superm1> how are you doing?
[08:04] <dholbach> good good - how are you?
[08:05] <superm1> i'm a bit agitated.  we were planning on announcing our mythbuntu beta disks on friday, but have bug 144043 and bug 144395 affecting our builds really poorly unfortunately
[08:05] <ubotu> Launchpad bug 144043 in linux-ubuntu-modules-2.6.22 "kernel BUG at /build/buildd/linux-ubuntu-modules-2.6.22-2.6.22/debian/build/build-generic/fs/unionfs/inode.c:1057!" [Undecided,Confirmed]  https://launchpad.net/bugs/144043
[08:05] <ubotu> Launchpad bug 144395 in linux-ubuntu-modules-2.6.22 "unionfs oopses for http processes" [Undecided,New]  https://launchpad.net/bugs/144395
[08:06] <superm1> so ubiquity is tending to randomly stall :(
[08:06] <dholbach> oh :-/
[08:06] <superm1> i'm at a loss still how the normal gutsy beta disks weren't affected as badly as we were
[08:16] <Hobbsee> keescook: ping
[08:38] <Hobbsee> argh, dammit!
[08:39] <Mithrandir> did the world implode?
[08:39] <Hobbsee> (apologies to the readers of ubuntu-devel ML)
[08:39] <Hobbsee> no
[08:41] <carlos> pitti: did your script find the language pack update exported Saturday night?
[08:43] <pitti> carlos: oh, I didn't change the cron jobs yet
[08:43] <pitti> carlos: will adapt them today
[08:44] <carlos> pitti: the update export took around 43 minutes
[08:44] <carlos> so I don't expect it to be a problem like the full export was
[08:44] <pitti> carlos: for updating the cronjobs, can you please give me a current table of when the export happens for which release?
[08:45] <carlos> sure, let me look for the cron tasks scheduled I sent to Stuart...
[09:09] <siretart> morning folks!
[09:10] <dholbach> hey siretart
[09:15] <\sh> moins
[09:19] <siretart> yay. cryptsetup works with UUIDs as well :)
[09:20] <pitti> siretart: !
[09:20] <siretart> pitti: the trick is this: not the 'pseudo' block device must be uuid'ed, but the real device. and that one is the 2nd column in /etc/crypttab, and not the one in /etc/fstab
[09:21] <siretart> pitti: I'm going to upload a new partman-crypto right now
[09:21] <pitti> ah, cool
[09:21] <siretart> I'm not sure if we should bother to convert existing volumes
[09:21] <pitti> I didn't know that crypttab would support uuids
[09:21] <siretart> I just tested it by entering that manually and just booting it
[09:21] <siretart> :)
[09:22] <siretart> [and yes, I did recreate my initramfs and checked that it actually uses uuids] 
[09:22] <siretart> pitti: I'm just not sure if we should bother converting existing crypttabs
[09:22] <siretart> since we haven't supported cryptsetup before, and can therefore assume that existing users are competent enough to fix potential breakage themselves
[09:22] <Mithrandir> siretart: don't.  They contain a human-generated name, so we can reasonably expect that to be unique on a host.
[09:22] <Mithrandir> same as for LVM
[09:23] <siretart> Mithrandir: I take that as "don't convert existing /etc/crypttab", right?
[09:23] <Mithrandir> siretart: correct
[09:23] <siretart> that would be my guess as well
[09:23] <pitti> right, that would be too hackish
[09:23] <Mithrandir> siretart: or are you meaning the source device rather than the target name?
[09:23] <pitti> siretart: if it just touches partman, then we won't break upgrades, and new installations will DTRT
[09:24] <siretart> Mithrandir: I'm only talking about the "source device". the "target name" must be consistent in /etc/{fs,crypt}tab
[09:25] <Mithrandir> siretart: the source device should be converted, unless it's unique already.
[09:25] <Mithrandir> siretart: and the target name does not have to be consistent.
[09:25] <Mithrandir> backup-crypt /dev/disk/by-id/md-uuid-30859f04:dcfabcf1:60f4d120:ee3978a4 /var/local/backup-lukskey luks,checkargs=ext2 in crypttab
[09:25] <Mithrandir> UUID=299178d5-99c5-482e-a807-c073ead853f1 /backup       ext3    defaults       02
[09:25] <Mithrandir> in fstab
[09:26] <Mithrandir> works fine.
[09:26] <siretart> pitti: it touches partman-target (which should mangle the target name in /etc/fstab), udev (volumeid.postinst, to not mangle the "target name" in /etc/fstab, both already uploaded) - and partman-crypto, to mangle the "source device"
[09:26] <siretart> Mithrandir: for root on cryptofs,  the "target name" must be consistent in /etc/{fs,crypt}tab
[09:26] <siretart> else the cryptroot hook in initramfs will break
[09:27] <siretart> pitti: what's left is the partman-cryto upload, which I'm about to upload right now
[09:27] <Mithrandir> siretart: that might be; I'm just doing encrypted raid.
[09:27] <siretart> Mithrandir: I investigated that issue last thursday and friday
[09:27] <siretart> by reading the crypyroot hook and partman-crypto
[09:28] <Mithrandir> siretart: anyway, that sounds like an issue which should be fixed, and which is fairly easy to fix too?
[09:28] <siretart> they are coded with that assumption in mind
[09:29] <siretart> Mithrandir: right, I have the fixes already ready and uploaded
[09:29] <siretart> partman-crypto pending ACCEPTance right now
[09:31] <siretart> there is a very tiny visual issue left: the "target name" is named like 'sda5_crypt'.
[09:31] <pitti> i. e. although it is just a name, it will get confusing if it isn't on sda any more
[09:31] <siretart> in the case sda5 is named hda5 back or something, this would be a bit confusing, but won't break anything, since this is only the 'virtual target name'
[09:31] <siretart> right
[09:33] <fabbione> cjwatson: i think something is wrong the tasks in the archive. server netinstall fails with:
[09:33] <fabbione> Oct  1 07:21:40 in-target: E:
[09:33] <fabbione> Oct  1 07:21:40 in-target: Couldn't find task ubuntustudio-desktop
[09:33] <fabbione> Oct  1 07:21:40 in-target:
[09:33] <fabbione> Oct  1 07:21:40 in-target: tasksel: aptitude failed (100)
[09:33] <fabbione> no tasks selected at all
[09:33] <fabbione> just plain install
[09:33] <pitti> .. studio??
[09:34] <fabbione> yeps.. this is on sparc, and reproducible at will
[09:36] <pitti> hey seb128
[09:36] <seb128> hello pitti
[09:40] <pitti> calc_, seb128: FYI, I'm putting back ooo-{base,evolution}
[09:40] <seb128> ok
[09:41] <kagou> good morning
[09:42] <seb128> lut kagou
[09:42] <pitti> calc_: however, that'll oversize the alternates again; maybe there are some more points on my 'recent OO.o growth reasons' list which can be reverted?
[09:51] <kagou> hey seb128 , pitti
[09:53] <pitti> moin kagou
[10:00] <seb128> mjg59: could you try to ping somebody from the desktop team before uploading desktop packages? Your gnome-control-center upload conflicts with a 2.20.0.1 which was almost ready to be uploaded
[10:00] <StevenK> pitti: Morning!
[10:01] <pitti> hey StevenK, how are you?
[10:01] <mjg59> seb128: Ah, sorry about that
[10:01] <StevenK> pitti: Would you mind giving back gimp on i386? It looks like vernadsky choked on it.
[10:02] <mjg59> seb128: I noticed it while doing hotkey-setup fixes and wondering why the video stuff wasn't working
[10:02] <seb128> mjg59: that's alright, merging your change now ;)
[10:02] <pitti> StevenK: currently building already
[10:02] <seb128> mjg59: I think the 0xaa value came from Keybuk
[10:03] <StevenK> pitti: Yes, but it's listed as building on vernadsky, and apparently has been for 20 hours. And vernadsky is showing as not available on the +builds page.
[10:03] <pitti> oh, that
[10:03] <StevenK> Hence the vernadsky choking on gimp. :-)
[10:03] <pitti> StevenK: sorry, we need infinity or cprov for that; "Cancel current job" does not work in the UI
[10:04] <StevenK> pitti: Ah, right. Hopefully your mentioning them will get them to see what you said. :-)
[10:06] <kwwii> pitti: I have an updated wallpaper package (99% likely that this is the final change), could you take a look?
[10:06] <mjg59> seb128: Yeah, we had the wrong one set at one poitn
[10:07] <kwwii> pitti: the default wallpaper file size is some 90kb larger than the previous - no way to avoid that without loosing quality though
[10:07] <pitti> kwwii: sure, can you please put the source package somewhere?
[10:07] <pitti> kwwii: yeah, not being able to use jpeg sucks, but we can't help that now
[10:07] <pitti> kwwii: NB that the next alternates are oversized again (I just added ooo-base back)
[10:08] <ion_> Not being able to use JPEG why?
[10:08] <pitti> due to some weird 'warty-bla.png' hardcoded gconf value
[10:08] <kwwii> http://sinecera.de/gutsy-wallpapers_0.17.tar.gz, http://sinecera.de/gutsy-wallpapers_0.17_source.changes, http://sinecera.de/gutsy-wallpapers_0.17_source.build, and http://sinecera.de/gutsy-wallpapers_0.17.dsc
[10:09] <ion_> Filenames are for humans, not computers. :-) Have you tried whether gnome-desktop is as stupid as to not load a JPEG image called foo.png?
[10:09] <pitti> heh, that might actually work
[10:10] <kwwii> pitti: I already suggested that to dholbach but his comment that that is quite a hack is right
[10:11] <dholbach> kwwii: I think we can drop feisty-session-splashes, right?
[10:11] <dholbach> kwwii: we don't use a splash screen atm
[10:12] <ion_> kwwii: As long as gnome-desktops image loader is not stupid, the only problem is that a human might think its a PNG based on the filename.
[10:12] <dholbach> I think soren found another problem with it
[10:12] <soren> dholbach: Hm?
[10:12] <dholbach> seb128: it should be OK to drop the feisty-session-splashes now (at least not have ubuntu-artwork depends on it)
[10:12] <ion_> For software, a plain list of inodes would be sufficient to find data, filenames *only* exist for humans. :-)
[10:13] <soren> dholbach: Ah, the png/jpg thing?
[10:13] <dholbach> soren: the "rename the .jpg to .png" trick
[10:13] <pitti> kwwii: ok, I wait a bit with the upload until this discussion settles
[10:13] <soren> dholbach: Yeah, stupid eog tries to do magic things if the file is called .jpg..
[10:13] <cjwatson> fabbione: oh, meh, ok, I'll figure out a fix
[10:13] <fabbione> cjwatson: thanks a lot
[10:13] <soren> dholbach: Probably to extract EXIF info or something.
[10:14] <kwwii> dholbach: yes, we can drop it, afaik
[10:14] <ion_> I can understand guessing the MIME type based on the filename on remote directories, but theres no reason not to read the file header on local HDDs on todays hardware.
[10:14] <dholbach> Installed-Size: 148
[10:14] <dholbach> Size: 82582
[10:15] <soren> dholbach: Or is it the other way around? I forget. ANyhow, it doesn't work properly which could cause problems if users happen to be using nautilus or eog to browse around in /usr/share/backgrounds :(
[10:15] <dholbach> yeah :-/
[10:16] <soren> dholbach: It's a bug in eog more than anything else, though.
[10:16] <soren> dholbach: It shouldn't be relying on extensions for anything.
[10:17] <dholbach> *nod*
[10:17] <Mithrandir> we could, like, fix it.
[10:17] <dholbach> pitti: I dropped the depends on feisty-session-splashes; we can demote it to universe soon
[10:17] <soren> Mithrandir: Are you volunteering? :)
[10:17] <Mithrandir> soren: no. :-)
[10:18] <pitti> dholbach: where? gutsy-wallpapers doesn't have this dep?
[10:18] <ion_> soren: Indeed.
[10:18] <dholbach> pitti: from ubuntu-artwork
[10:18] <pitti> ah
[10:19] <dholbach> also, I fixed http://daniel.holba.ch/sponsoring to respect subscriber and assignee and filter out people that are not in motu/ubuntu-core-dev
[10:19] <dholbach> that way I can subscribe people to bugs and people won't think "oh this is assigned to <person>, I better not touch it any more"
[10:24] <calc_> pitti: ok, i'm waiting on translations from carlos and then i'll be doing another upload, hopefully in the next day or two
[10:25] <pitti> calc_: oh, I didn't expect you to be awake at this hour :)
[10:26] <pitti> calc_: did you find anything else to size down?
[10:26] <calc_> pitti: not yet :(
[10:26] <calc_> pitti: we might gain a little bit when i drop portaudio v19 but i think they are just going to pull v18 back into main so not sure how much that will help
[10:29] <pitti> calc_: no chance either to drop libhsqldb-java and/or libxalan2-java+libxerces2-java?
[10:30] <TheMuso> cal/c
[10:30] <TheMuso> calc_: I don't think there is much of a difference between pa19 and pa18
[10:30] <calc_> TheMuso: oh ok
[10:31] <dholbach> calc_: bug 135086?
[10:31] <TheMuso> We'll save 4MB only it seems, or there abouts.
[10:31] <ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
[10:31] <calc_> dholbach: i'll try to get to that later today
[10:31] <dholbach> thanks calc_
[10:31] <pitti> TheMuso: "only"? 4 MB is great
[10:31] <calc_> TheMuso: save 4mb by going back to pa18
[10:31] <calc_> TheMuso: that is huge if so
[10:32] <TheMuso> calc: This is only going on actual package size, not installed size.
[10:32] <calc> TheMuso: so 4MB compressed then?
[10:32] <dholbach> Riddell: bug 136425? pitti: bug 139671?
[10:32] <ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
[10:32] <ubotu> Launchpad bug 139671 in hal "hal-device-manager window should be titled "Hardware Information"" [Undecided,In progress]  https://launchpad.net/bugs/139671
[10:32] <calc> yipee! :)
[10:32] <pitti> TheMuso: how, though? the external libportaudio is tiny
[10:33] <pitti> dholbach: meh string freeze meh
[10:33] <dholbach> soren: what do you think about the change in bug 138181?
[10:33] <ubotu> Launchpad bug 138181 in network-manager-openvpn "Network Manager's openvpn plugin doesn't respect DHCP's domain setting." [Low,Fix committed]  https://launchpad.net/bugs/138181
[10:33] <TheMuso> pitti: yeah as I said, I haven't done a thorough check.
[10:33] <dholbach> pitti: then best to milestone it as 'later'?
[10:33] <dholbach> pitti: just let the patch author know and I'll unsub u-m-s
[10:34] <pitti> dholbach: it's assigned to me now anyway, so unsub'ing is fine
[10:34] <calc> pitti: looks like it might only be 40KB difference
[10:34] <dholbach> pitti: thanks
[10:34] <pitti> done
[10:35] <pitti> calc: right; I'm still hoping we can get rid of above java deps; they haven't been there in tribe 5, and they would save 5 MB
[10:35] <calc> i think i may be wrong that the java deps weren't in tribe 5 because java was completely disabled
[10:35] <calc> which breaks among other things ooo base
[10:36] <soren> dholbach: I've got the network-manager-openvpn on my TODO list for today anyway. I'll be looking at it a bit later.
[10:36] <dholbach> soren: rock on
[10:36] <soren> ;)
[10:36] <calc> pitti: i'll try to find out to what extent not having the java stuff breaks base for each package
[10:36] <calc> pitti: but i know base uses a lot of java stuff for it to work pretty much at all
[10:36] <cjwatson> calc: I'm beginning to think the right answer is simply to remove -base from the CDs
[10:37] <pitti> heh, I was just about to ask for the same
[10:37] <pitti> cjwatson: we did that for beta in fact
[10:37] <calc> cjwatson: could be, of course bits of base are used by writer, but for the most part writer functionality would be ok
[10:37] <cjwatson> wouldn't it be better to have a really good -base downloadable from the network than a neutered one on the CD? it doesn't really seem like a core feature
[10:37] <calc> cjwatson: yea
[10:37] <cjwatson> calc: in what circumstances are they used?
[10:37] <calc> cjwatson: it breaks a few things in writer if base isn't installed like for mail merges, and bibliography.. probably some other things i don't know of off the top of my head
[10:38] <cjwatson> it would be useful to know what writer says when that happens
[10:38] <pitti> calc: does that tell the user to install -base? or does it just crash or something?
[10:38] <cjwatson> e.g. "error code c182734" vs. "please install -base"
[10:38] <calc> cjwatson: it just doesn't work, no error from what i recall
[10:38] <TheMuso> pitti: So if OOo goes back to pa18, what do we do now to get it back into main, so that an espeak upload can use it?
[10:38] <calc> cjwatson: upstream believes in having everything always installed :\
[10:39] <pitti> TheMuso: I don't mind much which pa version is in main, I just don't want both
[10:39] <pitti> TheMuso: once you two decide which one you want/need, I can promote/demote
[10:39] <TheMuso> pitti: As you said in the bug report. I'm just wondering what we do now.
[10:39] <pitti> TheMuso: do you need 18 for espeak, or doesn't it matter?
[10:39] <pitti> calc: does OO.o work better with portaudio18? or is 19 ok?
[10:39] <calc> actually without base trying to use bibliography crashes ooo
[10:40] <calc> pitti: before i turned on v19 support ubuntu wasn't using it at all, so not sure
[10:40] <calc> pitti: i was going to just turn it back off
[10:40] <cjwatson> calc: I think it would be a good use of time to try to fix that
[10:40] <TheMuso> pitti: As I explained in 140673, espeak works with 19, but theres something wrong with 19, causing speech to be cut off, and espeak to freeze.
[10:40] <cjwatson> we're going to need to be able to split OOo up, either now or in the future
[10:41] <TheMuso> bug 140673
[10:41] <ubotu> Launchpad bug 140673 in espeak "Espeak + portaudio v19 causes undesirable lock-ups." [Medium,Confirmed]  https://launchpad.net/bugs/140673
[10:41] <nrdb> Hi, I have been looking into the initrd of 7.04, I notice that the mount point for the 'root' filesystem seems to be '/root', is this correct ?  when is this changed to '/' ?
[10:41] <pitti> TheMuso: and it does need libportaudio in the first place? doesn't work with alsa, or so?
[10:41] <calc> cjwatson: i don't know that those are the only two things that break with -base removed but those are the first two i have found
[10:41] <cjwatson> nrdb: that's correct. /init chains to the real root filesystem as its last action
[10:41] <seb128> TomaszD: the template not updates are not all due to missing Build-Depends on intltool
[10:41] <TheMuso> pitti: Since espeak is cross-platform, it uses portaudio and portaudio only.
[10:42] <pitti> ah
[10:43] <Amaranth> TheMuso: is that my bug?
[10:44] <TheMuso> Amaranth: the espeak + portaudio bug? No.
[10:44] <Amaranth> dang, i'd really like to be able to use orca to test stuff :)
[10:44] <TheMuso> Amaranth: That is if you refer to 140673.
[10:44] <nrdb> cjwatson: I presume its the executable 'run-init' that does this ?
[10:45] <cjwatson> nrdb: yes
[10:50] <nrdb> cjwatson: so if I want a unionfs as my 'root' I would pass the mount point of the union to 'run-init' ?
[10:50] <pitti> calc: FYI, giving back OO.o on sparc/powerpc; stumbled over the udev postinst error, apparenlty
[10:51] <cjwatson> nrdb: yes
[10:51] <cjwatson> nrdb: exactly as the live CD does in fact
[10:52] <nrdb> cjwatson: thanks for the help :)
[10:54] <nrdb> cjwatson: I have been looking at what the LiveCD does, but there is a lot of stuff done by the casper scripts, and I wanted to understand more before I fiddled with the script any more.
[11:00] <pitti> LongPointyStick: you sponsored a new evolution-sharp upstream release which breaks ABI (new soname) for mruiz; the changelog does not mention a FF exception bug; who will take care of fixing the reverse dependencies? I will keep this in the NEW queue until someone uploads fixed beagle and gfax
[11:00] <pitti> LongPointyStick: (or reverts the package to the older version)
[11:05] <TomaszD> seb128, aren't those I've reported ?
[11:05] <seb128> TomaszD: what do you mean?
[11:06] <TomaszD> seb128, aren't those issues I've reported caused by the missing build-dep?
[11:06] <seb128> TomaszD: like the rhythmbox issue is not a missing Build-Depends on intltool, if you look at the build log you will notice that intltool-update is called correclty
[11:06] <seb128> TomaszD: no
[11:06] <TomaszD> alright, I'll keep that in mind. Where can I see those build logs?
[11:06] <seb128> on launchpad
[11:07] <seb128> go to package page, the overview tab
[11:07] <seb128> click on the version you want
[11:08] <TomaszD> seb128, I see now
[11:08] <TomaszD> seb128, what about gnome-screensaver then?
[11:08] <TomaszD> duh, I'll look at the build log :] 
[11:10] <TomaszD> "echo 'langpack.mk: po/Makefile* mentions intltool, but intltool-update is not available'; "
[11:10] <TomaszD> so I think I was right there
[11:11] <TomaszD> yep, pretty sure it's a missing intltool build-dep there
[11:11] <TomaszD> cool stuff this build log
[11:11] <TomaszD> alright, no more bogus reports from me then
[11:13] <TomaszD> it's the same with serpentine
[11:18] <pitti> seb128: bah, shall I just add intltool as a cdbs build dep?
[11:19] <seb128> pitti: I'll do it, I've an another small change to do
[11:20] <seb128> pitti: cdbs Depends you mean, right?
[11:20] <pitti> seb128: right (note that cdbs is in bzr)
[11:20] <seb128> (ok)
[11:22] <TomaszD> If you guys have some time, this is my pet peeve https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/147278
[11:22] <ubotu> Launchpad bug 147278 in gnome-panel "[gutsy]  tooltip of workspace switcher doesn't pick up translations" [Undecided,New] 
[11:23] <highvoltage> soren: congrats on being core-dev!
[11:23] <soren> highvoltage: \o/ Thanks!
[11:25] <pitti> siretart, cjwatson: partman-crypto-loop moved back to main; I'll test tomorrow's daily alternate
[11:25] <seb128> TomaszD: we got like 100 new desktop bugs during the WE so that will take some time
[11:25] <siretart> pitti: err, how das partman-crypto-loop work? I haven't used/looked at it yet
[11:26] <TomaszD> seb128, sure, I understand.
[11:27] <pitti> siretart: er, I mean partman-auto-crypto
[11:27] <siretart> ah
[11:29] <pitti> carlos: one q: when the cronjob automatically fetches and updates gutsy/PPAs, how to tell the rosetta UI? (it currently says 'unused')
[11:29] <soren> Have you guys ever experienced the initramfs getting cut short?
[11:29] <carlos> pitti: right now, you need to tell jtv, danilo or me
[11:30] <pitti> carlos: hm, twice a week/
[11:30] <pitti> ?
[11:30] <carlos> pitti: I hope that at the end of october, we will get it automatically once buildd finish processing your upload
[11:30] <carlos> pitti: well, it should be done only when you upload your packages to the public archive
[11:30] <carlos> PPAs doesn't count for that
[11:30] <pitti> carlos: something like appending "&& mail -s "gutsy delta pack uploaded" carlos@ubuntu.com" after the dput? :)
[11:31] <carlos> pitti: that's enough, yes, I don't expect you to ping us on IRC each time :-P
[11:31] <pitti> ok
[11:31] <carlos> pitti: but use rosetta@launchpad.net, please
[11:31] <pitti> carlos: ok, I'll include the version into the mail
[11:31] <pitti> and that
[11:31] <carlos> pitti: thank you
[11:31] <carlos> pitti: but remember, only for published packages in the archive
[11:31] <pitti> right
[11:32] <TomaszD> carlos, pitti, hi. I was just wondering about the r-m not having any translations issue. Have you figured it out yet? "Launchpad does export that translation. The problem should be in the process that generates the .deb packages based on the tar.gz we export."
[11:33] <Nafallo> mjg59: my Lenovo R61 doesn't have laptop-mode enabled when I unplug AC. is that a bug? (powertop just told me about lots of things I would have supposed happened automagically)
[11:33] <pitti> TomaszD: no, I had hoped that the last langpacks would include it
[11:33] <carlos> pitti: launchpad exported those translations
[11:33] <carlos> I already checked it
[11:33] <mjg59> Nafallo: No, it's not a bug
[11:34] <carlos> pitti: so seems like they are lost in the process to create the .deb package
[11:34] <mjg59> For reasons we're still entirely unclear on, it seems to cause hangs on some systems
[11:34] <TomaszD> pitti, the 20070928 langpack doesn't contain the translation
[11:34] <ion_> nafallo: Have you turned it on in /etc/default/laptopsomething?
[11:34] <Nafallo> mjg59: ouch :-/. yet another whitelist or blacklist needed?
[11:34] <mjg59> No, it needs fixing
[11:35] <pitti> carlos, TomaszD: ah, I see; my package classificator only reads main/source/Sources.gz, will fix that
[11:35] <Nafallo> ion_: not there.
[11:36] <Nafallo> oh. there is is...
[11:36] <Nafallo> in acpi-support
[11:36] <TomaszD> pitti, THANK YOU! One of the last loose ends in gutsy's translations
[11:37] <carlos> pitti: ok, thanks
[11:37] <ion_> Ah, right.
[11:38] <Mithrandir> mjg59: any particular reason for libusplash-dev not to ship a shlibs file?
[11:38] <mjg59> Incompetence on my part?
[11:38] <Mithrandir> heh, I'll fix
[11:38] <ion_> nafallo: You also need to restart /etc/init.d/laptop-mode after enabling it for the power event scripts to do anything.
[11:39] <Nafallo> ion_: cheers
[11:39] <mjg59> ion_: No
[11:40] <ion_> mjg59: Hm, ok. I had a memory of the script creating some file in /var/run, without which the laptop-mode script doesnt do anything. I was probably wrong, then.
[11:40] <Nafallo> mjg59: . /etc/default/laptop-mode < deprecated?
[11:41] <mjg59> Yes
[11:41] <Nafallo> thought so :-)
[11:42] <Nafallo> laptop-mode status looks kinky :-)
[11:42] <mjg59> Just ignore the laptop-mode command
[11:43] <mjg59> We've hacked it to small pieces to make it plausibly sane, but it's still utter crack
[11:47] <Nafallo> ehrm. I'm starting to believe in that :-P
[11:49] <fabbione> cjwatson: thanks for the fix on tasksel
[11:55] <cjwatson> np
[12:04] <pitti> carlos: https://translations.launchpad.net/ubuntu/feisty-updates/+latest-delta-language-pack does not work
[12:04] <pitti> carlos: and neither s/feisty-updates/feisty/
[12:05] <pitti> carlos: ah, is that because https://translations.edge.launchpad.net/ubuntu/feisty/+language-packs does not list any exported delta packs?
[12:05] <carlos> pitti: right
[12:05] <carlos> you will need to wait until their slot this week
[12:05] <carlos> so they are generated
[12:05] <pitti> carlos: but /feisty/ is right, not /feisty-updates/ ?
[12:08] <carlos> pitti: is feisty, not feisty-updates
[12:08] <cjwatson> mvo: I'm changing debconf so that it doesn't break if some random python module won't compile
[12:08] <cjwatson> mvo: with any luck that'll get rid of a class of upgrade failures
[12:08] <cjwatson> or at least make them a lot less severe
[12:09] <mvo> cjwatson: that sounds good
[12:12] <pitti> carlos: hm, but shouldn't the dapper export have happened last night?
[12:13] <carlos> pitti: no, it's scheduled for tonight
[12:13] <sladen> off-by-one-error
[12:13] <pitti> 00 22 * * 1
[12:13] <pitti> isn't that Monday?
[12:13] <pitti> oh, ignore me
[12:13] <pitti> I thought that was 0:22, not 22:00
[12:14] <carlos> pitti: :-P
[12:14] <carlos> pitti: if you want to change the schedule, just tell me it
[12:14] <carlos> we are flexible and we are not tied with any other process running first
[12:15] <pitti> no, that's fine, I'm just a retard with reading crontabs :)
[12:15] <pitti> ok, I'll test the dapper PPA uploading tomorrow
[12:17] <carlos> ok
[12:31] <pitti> carlos, TomaszD: langpack-o-matic fixed for restricted, FYI; next gutsy base update will fix it completely
[12:32] <carlos> pitti: thanks. Is that the one planned for 11th October?
[12:32] <carlos> pitti: or will you do a new full export?
[12:32] <TomaszD> pitti, thanks
[12:32] <carlos> or just a patched one with the same version we have right now in Gutsy?
[12:32] <pitti> carlos: oh, new full export for the release candidate
[12:33] <carlos> ok
[12:33] <carlos> pitti: remember that you need to request it 3 days before you want to use it..
[12:33] <pitti> right
[12:33] <pitti> carlos: I uploaded the current gutsy delta pack (no automated mail yet)
[12:34] <carlos> ok
[12:34] <carlos> I will note it in our UI
[12:34] <seb128> TomaszD: is libwnck translated in your locale? the workspace switcher applet tooltips come from it
[12:34] <TomaszD> seb128, checking
[12:36] <TomaszD> seb128, no, this one isn't. but the "translate this application" button in the workspace switcher pointed me to gnome-panel
[12:37] <seb128> TomaszD: there is strings coming from the panel and from libwnck, we could remove the items though
[12:38] <TomaszD> seb128, no no I'll manage, I found the missing strings in rosetta, will translate them now
[12:39] <Whoopie> cjwatson: Hi, latest ntfs-3g introduced --disable-library configure option. this links the ntfs-3g library. the benefit is that the filesize sum is less and the preformance increased. Will be update to latest ntfs-3g before release?
[12:39] <seb128> TomaszD: ok, cool
[12:40] <cjwatson> Whoopie: on my list, though I wasn't planning on doing significant repackaging, just a straight update
[12:40] <cjwatson> and it's only on my list to investigate, so this is not a promise
[12:41] <Whoopie> cjwatson: ok ;)
[12:44] <TomaszD> seb128, we have only 4 people (with me included) on the Polish GNOME upstream translation team, so our resources are quite... well, small. We managed to translate 97% of GNOME, libwnck, orca and a small part of gnome-games is what's been left untranslated :(
[12:45] <TomaszD> tough luck, seems libwnck is very important
[12:45] <seb128> TomaszD: good job! ;)
[12:45] <seb128> yeah
[12:45] <seb128> you still have time to get it translated in gutsy though so that should be alright
[12:46] <TomaszD> yeah, it's way too late for other distros though
[12:49] <slytherin> dholbach: ping
[01:15] <nrdb> I am trying to mount a drive in the init file in initrd, I used the command "[ -d ${rootmnt}/mnt/hdc1 ]  || mkdir -p ${rootmnt}/mnt/hdc1" any ideas why this isn't creating a directory in the '/mnt/' directory ?
[01:16] <cjwatson> that code looks fine although the [ -d ]  is unnecessary since mkdir -p already handles that
[01:16] <cjwatson> it should create a directory in /root/mnt/ though, not /mnt/
[01:16] <cjwatson> (and BTW the Ubuntu standard is to use /media/ for that ...)
[01:16] <TomaszD> seb128, got another one for you, confirmed lack of intltool build-dep in build-log for gnomebaker https://bugs.launchpad.net/ubuntu/+source/gnomebaker/+bug/147624
[01:16] <ubotu> Launchpad bug 147624 in gnomebaker "[gutsy]  gnomebaker should build-dep on intltool, no template available" [Undecided,Confirmed] 
[01:17] <nrdb> cjwatson: but as the 'run-init' command moves the mount wouldn't that end with it being in "/mnt" ?
[01:20] <cjwatson> nrdb: yes. perhaps you created the directory before mounting the filesystem on /root?
[01:20] <cjwatson> (run-init doesn't really move the mount, BTW; it merely changes where you're standing ...)
[01:21] <nrdb> cjwatson: I don't think so, its just before the 'run-init' command.
[01:22] <cjwatson> I don't know, then. You're in the best place to debug it :)
[01:22] <Mithrandir> nrdb: why are you doing this in the initramfs instead of later on?
[01:23] <nrdb> cjwatson: I think I know why, it isn't a writable fs at that point.
[01:25] <Nafallo> kylem: why doesn't /usr/share/doc/xserver-xorg-video-intel/ have changelog.Debian.gz?
[01:25] <Nafallo> :-)
[01:25] <zul_> Nafallo: its 7:30am in the morning he might not be up yet
[01:26] <Nafallo> zul_: ah. well, I guess he will fix it when he is then ;-)
[01:26] <Nafallo> thanks
[01:31] <cjwatson> nrdb: that's not true for us
[01:37] <seb128> TomaszD: there is no language pack for universe
[01:38] <TomaszD> hmm, seb128 so build-dep on intltool wouldn't fix anything? the mainline translation in rosetta isn't used
[01:39] <TomaszD> or at least something that's being used is terribly out of date
[01:41] <seb128> TomaszD: it should not be in rosetta
[01:41] <pitti> hey Hobbsee
[01:42] <TomaszD> seb128, so the build errors should be ignored?
[01:42] <seb128> TomaszD: what build error?
[01:42] <Hobbsee> pitti!
[01:43] <TomaszD> seb128, same as with other apps that need to have a intltool build-dep, like serpentine or others
[01:43] <TomaszD> the buildlog complains about missing intltool-update and such
[01:43] <seb128> TomaszD: other applications are in main and have the translation stipped at build time, that should not be the case of gnomebaker
[01:43] <TomaszD> ok
[01:50] <mjg59> What hardware?
[01:51] <smurf> mjg59: ATI. See lp#147635
[01:51] <mjg59> Right. Fixed upstream.
[01:52] <smurf> Good. ETA?
[01:52] <mjg59> Oh, interesting. Maybe not, in fact.
[01:52] <mjg59> Does X start at all?
[01:52] <smurf> Yes. Apart from the fact that I cannot see anything, everything seems to be working. :-/
[01:52] <mjg59> So no gdm?
[01:53] <smurf> including console switching
[01:53] <tepsipakki> it uses wrong output I guess
[01:53] <smurf> tepsipakki: probably. With an empty xorg.conf (or the one from feisty) that's a bit surprising though.
[01:54] <Whoopie> smurf: I also own a Samsung P35 and it works with 6.7.194
[01:54] <tepsipakki> smurf: right, try 6.7.194 first
[01:54] <tepsipakki> log says it's .193
[01:55] <StevenK> pitti: evolution-sharp is in binary NEW due to libevolution2.0-cil -> libevolution3.0-cil jump. I've got the two uploads prepared if you can wave it through NEW?
[01:56] <Whoopie> smurf: btw, I have a problem with it and gnome-power-manager. does changing the brightness via /sys/class/brightness/asus/brightness also generate an ACPI event for you?
[01:56] <pitti> StevenK: ah, that was what I was asking Hobbsee about earlier
[01:56] <Hobbsee> pitti: what were you asking me about earlier?  was i here?
[01:56] <pitti> StevenK: there was no FF exception bug in the changelog, and I wasn't aware of who would care for the transition
[01:56] <smurf> Whoopie: Yeah, brightness fluctuates wildly here, that was the next problem to tackle. :-/
[01:57] <pitti> Hobbsee: to LongPointyStick
[01:57] <Hobbsee> pitti: ah, i havent read the log from that yet
[01:57] <StevenK> pitti: Ah. I'm happy enough to deal with the transition, I'm doing so because it appears in NBS.
[01:57] <tepsipakki> smurf: gutsy has .194, please update :)
[01:57] <smurf> tepsipakki: downloading
[01:57] <StevenK> pitti: If you want to reject it, I'm happy for you to do so, I've spent a whole five minutes on it
[01:57] <Whoopie> smurf: you need to disable the /etc/acpi/events/asus-brightness-{up,down}
[01:57] <pitti> StevenK: no, I wouldn't like to reject binary NEWs
[01:58] <smurf> Whoopie: I gathered as much, but it's still a regression.
[01:58] <Whoopie> smurf: the problem is the DSDT which generates an event. :(
[01:58] <pitti> StevenK: I would like people to mention FF exception bug numbers in changelogs :)
[01:58] <smurf> Whoopie: Who started listening to crap events like that?  :-/
[01:58] <pitti> StevenK: NEWed; I take it your new uploads have proper build deps, so feel free to upload
[01:58] <mjg59> Whoopie: Does hitting the brightness keys actually do anything without those events?
[01:58] <StevenK> Hobbsee: a) It oughtn't to be. b) It hasn't built on i386 yet
[01:59] <Whoopie> mjg59: yes, brightness control is done in hardware. it's just for the OSD.
[01:59] <Hobbsee> StevenK: ah, great.
[01:59] <mjg59> Whoopie: Right. Grab hal-info, take a look at how the Thinkpads are flagged
[01:59] <Hobbsee> StevenK: i thought we built all binaries for the source at the same time.
[01:59] <mjg59> Then add something similar
[01:59] <StevenK> Hobbsee: gimp-data is arch all
[02:00] <StevenK> Hobbsee: Which is only built on i386
[02:00] <StevenK> Hobbsee: verdansky choked on it. We need infinity or cprov to get it unstuck.
[02:01] <StevenK> pitti: Right. I shall update their changelogs and upload.
[02:01] <Hobbsee> StevenK: oh right, yes.
[02:01] <pitti> meh, why oh why doesn't pysqlite3 allow you to change the timeout?
[02:03] <Hobbsee> hiya cprov!
[02:04] <StevenK> pitti: Tell cprov about gimp's problem? I'm having trouble phrasing.
[02:04] <StevenK> pitti: And beagle and gfax have both been uploaded, both of which are universe.
[02:04] <pitti> StevenK: doing
[02:05] <cprov> Hobbsee: hi there, what's up ?
[02:05] <Hobbsee> cprov: the sky.  and varying thoughts about componentry of ppas.
[02:06] <StevenK> Like the i386 ppa builder.
[02:06] <cprov> interesting subject.
[02:07] <Hobbsee> yeah, that too
[02:07] <Whoopie> mjg59: I tried something this: http://en.pastebin.ca/721607
[02:07] <Whoopie> mjg59: but I couldn't see any improvements.
[02:07] <mjg59> Whoopie: You'd then need to restart hal
[02:07] <Whoopie> smurf: could you also try?
[02:07] <Whoopie> mjg59: I did
[02:07] <mjg59> Whoopie: Does lshal show that key?
[02:08] <smurf> Whoopie: will do
[02:08] <Whoopie> mjg59: I think, it did. I grep'ed for it. but I have the P35 not here, so can't test.
[02:08] <Hobbsee> StevenK: 2.
[02:09] <StevenK> Hobbsee: Sigh.
[02:09] <Hobbsee> StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/gimp/+bug/147628
[02:09] <StevenK> Hobbsee: Let me merge and bitch-sl^Wcomment.
[02:09] <ubotu> Launchpad bug 147628 in gimp "Gutsy Gibbon 7.10 - unmet dependencies: gimp: Depends: gimp-data (>= 2.4.0~rc3) but 2.4.0~rc2-1ubuntu1 is to be installed" [Undecided,Fix committed] 
[02:09] <smurf> Whoopie: seems I need to get the cat hairs out of the keyboard first *grumble*
[02:10] <StevenK> Hobbsee: Which you've already done. :-)
[02:10] <Hobbsee> yeah
[02:10] <StevenK> Hobbsee: The problem is that verdansky grabbed gimp, and hasn't let go.
[02:10] <Hobbsee> StevenK: heh.  it wont build?
[02:10] <Whoopie> smurf: hehe
[02:11] <StevenK> Hobbsee: No other i386 builder will try gimp since verdansky is trying. Apparently.
[02:11] <Hobbsee> ah, right, yes
[02:11] <smurf> Whoopie: yeah, my editing skillz suffer when I can't even move the cursor in both directions
[02:12] <Whoopie> mjg59: the problem is that g-p-m changes the brightness through sysfs and that interferes with the ACPI events. That's my guess.
[02:12] <smurf> Bah. dpkg troggers are seriously cool, but not so when aptitude insists on starting a new dpkg for what feels like Every. Single. Packet.
[02:13] <smurf> s/trogger/trigger/
[02:13] <cjwatson> s/Packet/Package/ too :)
[02:14] <smurf> cjwatson: Bah :-)
[02:14] <pkern> mjg59: Did you read my PM? It seems that I went offline inbetween. \:
[02:14] <mjg59> Whoopie: Yes, the firmware is being irritating in this case
[02:14] <Hobbsee> StevenK: you've got both the new beagle and e-d-s?
[02:15] <StevenK> I didn't think e-d-s needed a rebuild?
[02:15] <smurf> On to the next problem ... any firefox font display experts in here?  :-/
[02:15] <pkern> smurf: You mean the ligatures problem?
[02:15] <Hobbsee> StevenK: sorry, beagle-backend-evolution
[02:15] <smurf> pkern: 'xactly
[02:16] <StevenK> Hobbsee: Which is built from beagle. I uploaded beagle and gfax
[02:16] <Hobbsee> StevenK: which presumably dont build yet, as this thing's sitting in NEW
[02:16] <Hobbsee> no, wait.
[02:16] <pkern> smurf: Problem known, no fix yet (disable Pango or disable ligatures in the default font)... i.e. change font or start Firefox with some obscure envvar to disable Pango.
[02:16] <Hobbsee> which presumably will have to be given back, to build with the new library.
[02:17] <pkern> smurf: #37828 that is
[02:17] <StevenK> Hobbsee: They should hit DEPWAIT, and will be retried automatically.
[02:18] <StevenK> Hobbsee: pitti and I have done this before. :-)
[02:18] <smurf> pkern: thanks
[02:18] <Hobbsee> pitti: OK, please let that thru (and sorry, i forgot to deal with it earlier)
[02:18] <pitti> Hobbsee: I NEWed it 20 minutes ago, should be on the way to the archive in publisher
[02:18] <nrdb> cjwatson: can you please have a look at http://paste.ubuntu-nl.org/39257/   it is the last part of the init file I am using, it is hanging at the begining of the startup now.
[02:18] <pkern> Probably not, whyever it needs Pango. I don't know.
[02:20] <cjwatson> nrdb: sorry, I'm doing a million other things
[02:20] <nrdb> cjwatson: ok, thanks for the help.
[02:20] <Hobbsee> pitti: cool, thanks.  (and there was a bug #)
[02:26] <\sh> why is ia32-libs missing from the feisty archives?
[02:26] <pitti> ia32-libs | 1.5ubuntu9 |        feisty | source, amd64
[02:26] <pitti> \sh: hm? it seems to be fine?
[02:26] <\sh> yes, I know...but just installing a feisty
[02:27] <\sh> server...and adding all archives (m,r,u,mu) and apt-get update and apt-cache search ia32 brings nothing
[02:27] <Mithrandir> \sh: what does apt-cache policy ia32-libs say?
[02:27] <pitti> that works on my feisty at least
[02:27] <pitti> \sh: and it's in main
[02:28] <\sh> forget it...my boss is a jerk
[02:28] <pitti> (in feisty, anyway, we demoted it in gutsy)
[02:28] <pkern> And installed i386? :-P
[02:28] <Whoopie> smurf: you should close your bug report.
[02:28] <\sh> pkern, right
[02:28] <\sh> pkern, and gives me the fault
[02:28] <smurf> Whoopie: as soon as I checked that the thing works now :-P
[02:28] <pkern> \sh: Thought that when I read your statement. ;)
[02:28] <pkern> \sh: You got all the ia32 libs at your fingertips now (:
[02:29] <Whoopie> mjg59: btw, why don't we add tp_smapi anymore?
[02:29] <\sh> pkern, /me should kick this guy to hell.....*gnarf*
[02:47] <manchicken> \sh: What's your job market?
[02:50] <smurf> Whoopie: no, still fluctuating. Worse, when it does that it generates NULL characters so that I also cannot login on the console. :-/
[02:54] <maks> where do i find the daily nebootable d-i tar.gz ?
[02:54] <maks> ah google
[02:55] <maks> nevermind, you should leave links :P
[02:55] <pkern> blackle
[02:55] <Whoopie> smurf: then disable the acpi events.
[02:57] <Whoopie> smurf: but lshal shows brightness_in_hardware?
[02:58] <Whoopie> smurf: I'd be interested if ASUS laptop owners are also affected.
[03:10] <smurf> Whoopie: will check
[03:15] <agoliveira> Whoopie: I didn't get the thread from the beginning but I do have an Asus laptop (a G1). Is there anything I can do to help?
[03:17] <Whoopie> agoliveira: the samsung laptop also uses asus_acpi. but when gnome-power-manager changes the brightness, an ACPI event is triggered. this results in a brightness change loop.
[03:17] <Whoopie> agoliveira: so if you open g-p-m preferences and move the brightness slider, do you see any events with "acpi_listen"?
[03:18] <agoliveira> Whoopie: Let me check
[03:20] <agoliveira> Whoopie: I just remembered that I'm not using asus_acpi but asus_laptop instead which is far more complete, at least for asus notebooks. whitout, for instance, I can't switch to an external monitor.
[03:20] <smurf> Whoopie: nope -- no brightness_in_hardware in lshal
[03:21] <Whoopie> agoliveira: the problem is that asus-laptop doesn't support the samsung at the moment. because the brightness control in the DSDT is different from the asus ones.
[03:21] <Whoopie> smurf: did you restart hal?
[03:21] <smurf> Whoopie: of course
[03:21] <agoliveira> Whoopie: I see.
[03:22] <Whoopie> smurf: lshal | grep system.hardware.vendor
[03:23] <smurf> Whoopie: that's SAMSUNG all right :-/
[03:23] <Whoopie> smurf: reboot? :)
[03:24] <smurf> Whoopie: already did that too
[03:24] <Whoopie> smurf: and just greping for brightness?
[03:25] <smurf> Whoopie: nothing
[03:38] <Nafallo> ehrm
[03:38] <Nafallo> I plugged in the power and gpm disappered...
[03:40] <lemsx1> Nafallo: perhaps you meant to ask that on #ubuntu+1 ?
[03:42] <Nafallo> lemsx1: that wasn't a question.
[03:43] <TomaszD> seb128, I have a hunch. It's strange, but please listen for a moment :]  I think that if a universe application actually uses rosetta for translations (which is the case for gnomebaker and ndisgtk for example) then these translations aren't being used in Ubuntu. I checked it with both these programs and both of them are translated in rosetta, but don't appear to be in Ubuntu. Especially ndisgtk is completely in English while it had a Polish trans
[03:43] <TomaszD> lation for a long time in Rosetta. I've been fixing the translation now but it's pointless if it's not going to be used.
[03:44] <seb128> TomaszD: right, that's a rosetta bug, they should not be listed there, talk to carlos maybe he can mask those
[03:44] <lemsx1> Nafallo: ah, just making sure ;-)
[03:45] <seb128> carlos: do you know why gnomebaker from universe is on rosetta?
[03:46] <TomaszD> seb128, but these programs use Rosetta for translations that are not Ubuntu-specific, gnomebaker devs just use it for mainline development... at least they used to
[03:46] <seb128> TomaszD: ok, so that's their job to get those translations in the tarballs they roll
[03:46] <seb128> TomaszD: and to update the templates
[03:47] <TomaszD> uhuh
[03:47] <TomaszD> ok
[03:47] <seb128> TomaszD: the upstream templates don't come from package builds
[03:47] <seb128> TomaszD: since the package strings can be different
[03:47] <seb128> it's up to upstream to provide update templates to launchpad
[03:47] <TomaszD> alright.
[03:50] <rohan> crimsun had once told me how to build kernel sound modules using just the source code obtained from the alsa hg repository. i lost those instructions, can someone please tell me how to do it again ?
[03:52] <rohan> the sound card module used is snd-hda-intel
[03:56] <Mithrandir> asac: did you end up deciding on a directory where plugins common to all browsers should go?
[04:00] <asac> Mithrandir: according to upstream its a bug that /usr/lib/mozilla/plugins isn't used by firefox et al.
[04:01] <Mithrandir> asac: ok, so I can stuff plugins in /usr/lib/mozilla/plugins and expect them to be used {now,soonish}?
[04:01] <asac> Mithrandir: but in gutsy+1 we will definitly have a single plugins directory
[04:01] <asac> Mithrandir: are packaging a new plugin?
[04:01] <Mithrandir> kinda.
[04:02] <Mithrandir> it's acroread, and it's not going in a public repo.
[04:03] <asac> Mithrandir: ok ... i will let you know tonight. Have to verify if its an easy fix before comitting on this.
[04:04] <Mithrandir> asac: I don't mind if it doesn't work completely just now, but it'd be good to have it working at least for Hardy
[04:05] <asac> Mithrandir: hardy is a safe bet ... if you can wait for it, there is nothing todo :) ... xulrunner-1.9 will take care for that
[04:05] <Mithrandir> asac: rock on!
[04:16] <bddebian> Heya
[04:19] <soren> Hi, bddebian!
[04:19] <bddebian> Hello soren
[04:29] <pitti> kwwii, dholbach: what was  the outcome of the gutsy-wallpapers discussion? shall I upload kwwii's new package, or did you find a way to reduce the size?
[04:30] <Kopfgeldjaeger> hi
[04:30] <dholbach> pitti: no, I don't know any; I'm OK with that change
[04:31] <toresbe> http://nopaste.org/p/aKinluP5 <- i'm seeing this behavior with Gutsy. Some kind of a kernel bug?
[04:31] <sladen> what needs shrinking?
[04:32] <toresbe> I'm submitting a bug report after this dist-upgrade completes and I've rebooted into the new kernel.
[04:32] <pitti> sladen: the gutsy wallpaper is currently shipped as rather large PNG
[04:33] <pitti> sladen: mostly because some ancient gconf default requires it to be called sth. like 'warty-background.png'
[04:34] <sladen> 888K    /usr/share/backgrounds/warty-final-ubuntu.png
[04:34] <sladen> 380K    /usr/share/backgrounds/elephant-skin.jpg
[04:37] <toresbe> never mind, latest initramfs updated it.
[04:38] <bddebian> OK, so where in gconf does it store what screensaver I'm using?
[04:39] <soren> bddebian: I often find "gconftool-2 --dump / | grep stuff" very useful. :)
[04:43] <tepsipakki> pitti: I have a new discover-data ready, adds a number of nvidia cards that the current driver (nv) supports. Ok to upload?
[04:43] <pitti> tepsipakki: deferring to slangasek
[04:43] <pitti> tepsipakki: please attach a debdiff to the bug
[04:43] <tepsipakki> pitti: ok
[04:50] <bddebian> soren: That kind of helps, thanks.  I see tons of stuff for gnome-screensaver, but I don't see anything for if I was running say xscreensaver. :-(
[04:51] <soren> bddebian: Ah, no, that probably wouldn't be in gconf.
[04:53] <ogra> bddebian, there should be ~/.xscreensaver if you use that
[04:54] <ogra> gnome uses whatever gets started by /etc/xdg/autostart/ where xscreensaver doesnt put anything atm
[04:56] <bddebian> Grr.  What I'm trying to do is set up brightside to be able to use xscreensaver or gnome-screensaver instead of forcing one or the other
[04:56] <ogra> well, you can only run one at a time anyway
[04:56] <bddebian> Ideally I would just check which on is running I suppose
[04:57] <ogra> likely
[04:58] <bddebian> Aye but the debian package uses xscreensaver-command foo and I patched it in Ubuntu a while back to use gnome-screensaver-command foo
[04:58] <bddebian> It should ideally handle both
[04:58] <ogra> you cant judge that by installation status ... the thing is that if you have ubuntu-desktop and xubuntu-desktop installed for example they will both be there
[04:58] <sladen> pitti: that image is very suitable for jpeg'ing;  it'd probably be worth putting in the effort to update the gconf keys and handle all the sides cases as a resonable looking image down to ~150kB
[04:59] <kwwii> pitti: one thing to note is that the current file size is quite smaller than the one we shipped with feisty
[04:59] <pitti> slangasek: right, I hope that'll happen in hardy
[04:59] <ogra> so you need to actually check which one is actually running
[04:59] <bddebian> That's what I thought.  Hmm, how would I do that?
[05:02] <Whoopie> agoliveira_lunch: any results?
[05:04] <clem92> sry
[05:05] <ogra> bddebian, from a script i'd check if $(pgrep -u $USER -f gnome-screensaver -c) > 0 or something like that
[05:05] <ogra> if that C code, find something equivalent :)
[05:05] <ogra> *thats
[05:07] <bddebian> It's C and I have been searching for how to do it :-(
[05:27] <agoliveira> Whoopie: Ooops... I understood that as I was using asus_laptop instead of asus_acpi you weren't interested.
[05:30] <agoliveira> Whoopie: Anyway, answering your question, the brightness slide works nicelly and no acpi events are generated.
[05:31] <Whoopie> agoliveira: ok, thanks a lot. if you find the time, could you also try with asus_acpi?
[05:31] <Whoopie> agoliveira: I know it's not working that good for you, but ...
[05:33] <agoliveira> Whoopie: No problem, I can try... hold on.
[05:36] <agoliveira> Whoopie: Same result.
[05:36] <Whoopie> agoliveira: thanks, then it's a buggy DSDT on my side.
[05:36] <Whoopie> agoliveira: could you send me yours?
[05:37] <agoliveira> Whoopie: I have a fixed my DSDT, indeed.
[05:38] <tkamppeter> pitti, ping
[05:45] <pitti> hi tkamppeter
[05:49] <tkamppeter> pitti, it seems that CUPS is using "apparmor force-reload" in its maintainer script and this option has been taken out of the apparmor startup script.
[05:49] <tkamppeter> pitti, this causes apport reporting installation/upgrade problems on many printing packages
[05:50] <tkamppeter> pitti, see for example bug 147703
[05:50] <ubotu> Launchpad bug 147703 in hplip "package hplip 2.7.7.dfsg.1-0ubuntu2 failed to install/upgrade: vereistenproblemen - blijft ongeconfigureerd" [Undecided,New]  https://launchpad.net/bugs/147703
[05:53] <tkamppeter> pitti, bug 146885, bug 134453, bug 146748, bug 146742, bug 146739, bug 135635, bug 134453
[05:53] <ubotu> Launchpad bug 146885 in update-manager "cups-pdf fails during upgrade (was: package update-manager 1:0.78 failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /tmp/tmpM_pNBz/backports/usr/bin/dpkg returned an error code (1))" [Undecided,Incomplete]  https://launchpad.net/bugs/146885
[05:53] <ubotu> Launchpad bug 134453 in cups-pdf "package cups-pdf 2.4.6-3ubuntu5 failed to install/upgrade: le sous-processus post-installation script a retourn une erreur de sortie d'tat 1" [Undecided,Incomplete]  https://launchpad.net/bugs/134453
[05:53] <ubotu> Launchpad bug 146748 in hal-cups-utils "package hal-cups-utils 0.6.13+svn83-0ubuntu1 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/146748
[05:53] <ubotu> Launchpad bug 146742 in foomatic-db-hpijs "package foomatic-db-hpijs 20070813-0ubuntu1 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/146742
[05:53] <ubotu> Launchpad bug 146739 in hplip "package hplip 2.7.7.dfsg.1-0ubuntu2 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/146739
[05:53] <StevenK> Bad tkamppeter!
[05:54] <mvo__> asac: I got bugreports about network-manager not working with ndiswrapper, is there a way for it to detect that ndiswraper is providing the interface and keeping its fingers off it?
[05:54] <mvo__> asac: (e.g. #97616)
[05:55] <asac> mvo__: he? just configure the interface in /e/n/i ... nm will not touch it then
[05:55] <tkamppeter> Is there a limit on how many bug numbers in one message ubotu processes? I have posted 7 bug numbers and ubotu go tired after five.
[05:55] <asac> bug 97616
[05:55] <ubotu> Launchpad bug 97616 in update-manager "network monitor is installed by default, while ndiswrapper was used in 6.10" [Undecided,New]  https://launchpad.net/bugs/97616
[05:56] <joebaker> Question:  If I've used module-assistant to install the kqemu module and I install a new kernel update provided by Ubuntu will the module automatically recompile and be ready for the next reboot?
[05:56] <asac> mvo__: hmm from what i know ndiswrapper works with nm
[05:57] <asac> mvo__: in some cases it might not work, but in general it should
[05:57] <mvo__> asac: ok, it may well be that this is old informaton
[05:57] <mvo__> asac: great, I will close the bugreport then
[05:58] <asac> mvo__: good ... tell them they should file specific bug reports if ndiswrapper doesn't work with nm for them
[05:59] <pitti> tkamppeter: that would be a grave bug in apparmor; force-reload must exist in any init script according to DP
[05:59] <pitti> tkamppeter: not sure, but my /etc/init.d/apparmor does have force-reload
[06:11] <tkamppeter> pitti, I am backm
[06:11] <tkamppeter> 
[06:12] <tkamppeter> OOo has torn down my system completely had to do a hardware reset
[06:13] <tkamppeter> pitti, see bug 147703, log file http://launchpadlibrarian.net/9622106/DpkgTerminalLog.txt
[06:13] <ubotu> Launchpad bug 147703 in hplip "package hplip 2.7.7.dfsg.1-0ubuntu2 failed to install/upgrade: vereistenproblemen - blijft ongeconfigureerd" [Undecided,New]  https://launchpad.net/bugs/147703
[06:13] <superm1_> mvo__, ping
[06:13] <tkamppeter> pitti, I get
[06:14] <tkamppeter> Unable to find apparmor_parser, installation problem?: Failed.
[06:14] <tkamppeter> invoke-rc.d: initscript apparmor, action "force-reload" failed.
[06:14] <tkamppeter> usage: update-rc.d [-n]  [-f]  <basename> remove
[06:14] <tkamppeter>        update-rc.d [-n]  <basename> defaults [NN | sNN kNN] 
[06:14] <tkamppeter>        update-rc.d [-n]  <basename> start|stop NN runlvl [runlvl]  [...]  .
[06:14] <tkamppeter> 		-n: not really
[06:14] <tkamppeter> 		-f: force
[06:14] <tkamppeter> Looks like some component of apparmor is still missing in main.
[06:20] <pitti> tkamppeter: where do you get that?
[06:20] <pitti> it's in apparmor
[06:20] <pitti> (the package)
[06:21] <pitti> tkamppeter: weird; both the init script and apparmor_parser are in the very same package
[06:21] <pitti> tkamppeter: do you have 'apparmor' installed at all?
[06:30] <tkamppeter> I have found that in the log file http://launchpadlibrarian.net/9622106/DpkgTerminalLog.txt of bug 147703
[06:30] <ubotu> Launchpad bug 147703 in hplip "package hplip 2.7.7.dfsg.1-0ubuntu2 failed to install/upgrade: vereistenproblemen - blijft ongeconfigureerd" [Undecided,New]  https://launchpad.net/bugs/147703
[06:32] <tkamppeter> pitti, I cannot reproduce it by myself. For me every update goes smoothly.
[06:37] <Hobbsee> ScottK: oh damn.  clamav != spamassassin
[06:38] <LjL> Hobbsee: assuming you're gmt+12, yeah, i think so.
[06:38] <Hobbsee> +12?  that might be a bit far.
[06:38] <Hobbsee> i think we're only +10 or +11.
[06:38] <Hobbsee> it's almost 3am, nayway
[06:39] <LjL> oh then it's not late.
[06:39] <ScottK> Hobbsee: Yes?
[06:40] <Hobbsee> ScottK: you'll find out.
[06:40] <ScottK> I see it.
[06:40] <ScottK> Want to ack it anyway?
[06:40] <ScottK> Or does that one still count?
[06:41] <Hobbsee> ScottK: if i cant figure out which source package is which, do you really expect me to be able to make that kind of decision at this hour?
[06:41] <Hobbsee> ScottK: i'd like to see the upstream changelog
[06:42] <ScottK> Hobbsee: Upstream changelog diff is in the bug now.
[06:42] <ScottK> OK
[07:00] <sladen> mjg59: how come so few things are soon in alsamixer now;  eg. no modem or many of the other options there used to be
[07:00] <mjg59> sladen: It depends what the driver claims the hardware exposes
[07:01] <seb128> carlos: changing the names of the po in the export is not nice
[07:01] <sladen> mjg59: so things like jacksense are now intentially hidden by the driver?
[07:02] <mjg59> I think hda is sufficiently complicated that it doesn't make sense to think of jack sense as a single micer element
[07:05] <pwnguin> which is all and well should jack sense actually work
[07:06] <mjg59> pwnguin: Well, it wouldn't help in this case - if there were a mixer option, it wouldn't work either
[07:06] <mjg59> In ac97 there was a standard codec register that corresponded to that
[07:06] <mjg59> So it was nice and straightforward
[07:07] <pwnguin> actually
[07:07] <pwnguin> i have a headphone element
[07:07] <pwnguin> that works
[07:08] <pwnguin> toggles the headphone jack, then just turn down the front speakers
[07:08] <mjg59> Yeah, that's a definition of "works" that is somewhat less than ideal :)
[07:09] <pwnguin> its better than the older versions of works
[07:09] <pwnguin> that included not being able to turn the front speakers down
[07:11] <pwnguin> i think i misinterpreted the conversation as saying they did away with that
[07:11] <mjg59> No
[07:15] <pwnguin> well, i think theorerically, there is no "mic" jack
[07:15] <pwnguin> just a conventional one
[07:38] <tkamppeter> pitti, still there
[07:42] <elmo> if I lose (fullscreen) video after suspend/resume, who's bug would that likely be? X?  kernel?
[07:43] <elmo> also, if I can't suspend/resume while on batter, kernel?
[07:43] <elmo> batterY
[07:43] <Kmos> elmo: i think it's kernel
[07:45] <me_> emacs22-gtk takes 100% cpu here... and I can't find any emacs bugs in launchpad... not tracked there? (or better yet, anybody know how to fix it :)
[07:47] <cjwatson> me_: start at https://bugs.launchpad.net/ubuntu/+source/emacs22
[07:47] <cjwatson> don't use bare /emacs or whatever unless you're intentionally filing an upstream bug
[07:50] <bddebian> Is there a chance anyone could give me some advice on this brightside thing?  Trying to figure out a good way to tell it to use xscreensaver or gnome-screensaver dynamically.  I should be able to use gconf but I don't see a sane way to do that.
[07:52] <me_> cjwatson: ok, thanks... I guess I'll file a new bug... though I think I've read something about this behavior before
[07:52] <Kmos> me_: bug 147756
[07:52] <ubotu> Launchpad bug 147756 in tracker "Possible memory leak in trackerd" [Undecided,New]  https://launchpad.net/bugs/147756
[07:55] <carlos> seb128: hi, what do you mean by 'changing the names of the po in the export is not nice' ?
[07:56] <superm1> asac, ping
[07:57] <asac> superm1: yes?
[07:57] <superm1> hi asac, i just wanted to check on bug 95064, with an idea of when to expect an upload with it (We were going to work around it with mythbuntu if its going to be a bit)
[07:57] <ubotu> Launchpad bug 95064 in network-manager-applet "add XFCE to OnlyShowIn" [Medium,In progress]  https://launchpad.net/bugs/95064
[07:58] <asac> superm1: tomorrow :) (or maybe even today)
[07:58] <superm1> okay cool :)
[07:58] <pochu> pitti: are the new freezes already applying? i.e., can we upload bug-fix releases without asking for an UVFe?
[07:59] <pochu> pitti: https://wiki.ubuntu.com/FeatureFreeze says that there's no problem with bug fix releases, but I'm not sure that applies for Gutsy...
[08:00] <ogra> mdke, ping
[08:00] <mdke> ogra: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[08:04] <pitti> pochu: yes, as announced that's effective now; please be considerate, though :)
[08:04] <pitti> tkamppeter: re
[08:05] <Kopfgeldjaeger> hi
[08:05] <pochu> pitti: sure, will be (and I need a core-dev to upload too ;) ). Thanks for the info.
[08:07] <tkamppeter> pitti, have you seen my last answer, the "Unable to find apparmor_parser, installation problem?: Failed." was only in the log of the bug report. I could not reproduce it.
[08:08] <pitti> tkamppeter: I saw it, yes; but I have no idea about it
[08:18] <tkamppeter> pitti, did you have a look into the other "failed to install/upgrade" bugs which I have listed earlier?
[08:19] <me_> ubotu: That one doesn't seem to be emacs related... ?
[08:19] <me_> ah, sorry
[08:19] <me_> Kmos: That one doesn't seem to be emacs related... ?
[08:20] <Kmos> me_: no.. i confused with someone who talks about a tracker bug
[08:20] <Kmos> me_: sorry
[09:38] <Windkracht8> Hello all, I have a problem with starting gdm on gutsy, can someone tell me what data is needed to make a bug report
[09:42] <ScottK> Windkracht8: Try #ubuntu-bugs.
[09:53] <hunger> Any progress on the bluetooth front?
[10:18] <geser> keescook: Hi, are you interested in a debdiff for an imagemagick merge (fixing several CVEs)?
[10:19] <glatzor> hello bryce
[10:19] <bryce> hi glatzor
[10:20] <glatzor> bryce: I disabled support for ati and intel drivers in guidance. Riddell will upload a new version sson
[10:20] <glatzor> soon
[10:20] <lamont> dear ubuntu-archive god-of-the-day: gcc-4.1 is new on hppa... gcc-4.1-hppa64 needs to be main (kernel build-depend) otherwise I think it's straightforward
[10:20] <bryce> glatzor: good to hear
[10:20] <lamont> who's ubuntu-archive today?  Riddell ??
[10:21] <ScottK> geser: keescook might also be a good one to look at the gnupg upload.
[10:21] <glatzor> bryce: no it is time to disappoint the users. I plan to blog about this issue before the release.
[10:22] <glatzor> bryce: regarding from what I have read on the German forums many users expect to have finnally solved all monitor related issues with randr 1.2
[10:22] <glatzor> and they hope to configure it with the "new" gui
[10:23] <bryce> however, the only way to have achieved that would be to not update any of the drivers, since upstream is moving everything to xrandr now
[10:23] <bryce> certainly would be better to just add xrandr support to displayconfig-gtk
[10:23] <Riddell> lamont: Mithrandir on monday's, but he's often too busy
[10:24] <lamont> ok
[10:24] <lamont> Riddell: ISTR hearing you say it was your archive today...
[10:24] <glatzor> bryce: I am still unsure in which direction displayconfig should go, extending the current infrastructure by randr 1.2 or a greater rewrite with 2+ monitor support
[10:24] <Riddell> lamont: I'm tomorrow
[10:24] <lamont> ah, ok.
[10:24] <lamont> you wanna NEW gcc-4.1/hppa, or should I poke Mithrandir ?
[10:25] <glatzor> bryce: but do you know any graphics card that can support more than 2 outputs?
[10:25] <Riddell> lamont: let me look
[10:26] <bryce> glatzor: I've never seen one but it wouldn't surprise me to hear they exist
[10:26] <Riddell> lamont: accepted
[10:26] <lamont> Riddell: and gcc-4.1-hppa64 promoted to main?
[10:26] <lamont> it "used-to-was-be"
[10:26] <glatzor> bryce: I would like to avoid adding complexity to the user interface that only covers a very small set of use cases.
[10:28] <bryce> glatzor: It would seem the priority would be to get the dual monitor xrandr set up working, since this is what is described in the DisplayConfigGtk spec - it does say there explicitly that >2 heads is not going to be supported yet, and I agree those of us with >2 monitors are a small use case
[10:29] <Riddell> lamont: I don't follow you
[10:29] <lamont> I was assuming that it was NEW because of gcc-4.1-hppa64 being a new binary package.
[10:29] <lamont> that package needs to be in main
[10:30] <lamont> or why was it blocked?
[10:30] <glatzor> bryce: we have written this spec :)
[10:31] <glatzor> bryce: I am already thinking about Gutsy+1.
[10:31] <Riddell> lamont: several new binaries http://paste.ubuntu-nl.org/39301/
[10:32] <lamont> Riddell: wow.  ok
[10:32] <lamont> and thanks
[10:33] <bryce> glatzor: I think the priorities are 1) single monitor, 2) laptop+external using xrandr 1.2 drivers, 3) dual-head layouts with xrandr 1.2, 4) >2 head support with xrandr 1.2, 5) dual-head with Xinerama
[10:34] <bryce> I don't think 4 can be done yet, but _maybe_ by Hardy
[10:35] <bryce> I list dual head with Xinerama last since it will only be needed for the rare drivers that still don't have xrandr yet; I think as time goes on that set is going to get smaller and smaller, so 5 may even not be needed long term.
[10:36] <slangasek> lamont: what was the status of the expect FTBFS fix?
[10:37] <glatzor> bryce: do you expect nvidia or fglrx driver with xrandr support in the gutsy time frame?
[10:37] <bryce> no
[10:37] <lamont> slangasek: I thought I did the requestsync on that...
[10:38] <lamont> feh
[10:39] <bryce> glatzor: I'm thinking more of the hardy time frame
[10:40] <lamont> slangasek: sorry - I thought I'd done that.  137837 is now in ubuntu-archive's hands
[10:41] <slangasek> ok, thanks
[10:42] <lamont> mind you, the same fix in expect-tcl8.3 demonstrated that expect reaches _very_ deep into tcl internals where it doesn't belong.  we don't want that one.  (and I may get around to fixing that new FTBFS sometime before we have the package removed from the archive)
[10:47] <Kopfgeldjaeger> gn8
[10:52] <keescook> geser: yes, please.  bug 144425 exists for it
[10:52] <ubotu> Launchpad bug 144425 in graphicsmagick "[ImageMagick]  security issues with releases prior to 6.3.5-9" [Medium,In progress]  https://launchpad.net/bugs/144425
[10:58] <geser> keescook: http://members.ping.de/~mb/imagemagick.debdiff
[10:58] <geser> should I attach it to the bug is the link enough for you?
[10:59] <keescook> geser: I can attach it; thanks for building the diff!
[11:00] <geser> keescook: can you also ACK bug #147822? (fixes CVE-2007-4974)
[11:00] <ubotu> Launchpad bug 147822 in libsndfile "Please sync libsndfile (main) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/147822
[11:00] <ubotu> Heap-based buffer overflow in libsndfile 1.0.17 and earlier might allow remote attackers to execute arbitrary code via a FLAC file with crafted PCM data containing a block with a size that exceeds the previous block size. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4974)
[11:01] <keescook> geser: sure thing
[11:02] <ScottK> keescook: geser's also done Bug 147343 if you have time for it....
[11:02] <ubotu> Launchpad bug 147343 in gnupg "gpg ignores 1 as valid trust value" [Undecided,Confirmed]  https://launchpad.net/bugs/147343
[11:06] <keescook> ScottK: cool, looking
[11:43] <soren> How do I get a list of milestoned bugs assigned to myself or a team?
[11:44] <soren> Ah, I can order by milestone and then guess where the cutoff is.
[11:44] <Luke_S> Hi... is there a way to rebuild an install CD to have a custom usplash screen, the x window system with the minimum necessary packages, and a few cusotm packages? (make it boot into a custom X based application. no desktop manager)
[11:47] <ScottK> soren: Would you please have a look at Bug #147861.  It catches a CVE fix.
[11:47] <ubotu> Launchpad bug 147861 in inotify-tools "[UVFe]  Update to inotify-tools 3.11" [Undecided,New]  https://launchpad.net/bugs/147861
[11:50] <soren> ScottK: Am i the only one who is annoyed by the policy of requiring a diffstat, but not the actual diff?
[11:50] <soren> ScottK: Now I can see that there's 10 new lines in libinotifytools/src/inotifytools.c, but what it they're all crack?
[11:50] <soren> Grr...
[11:52] <soren> ScottK, geser: Ack'ed.
[11:52] <sladen> Luke_S: yes, https://help.ubuntu.com/community/LiveCDCustomization
[11:52] <geser> soren: if you are still interested: http://members.ping.de/~mb/inotify-tools.debdiff
[11:53] <soren> I am :)
[11:56] <soren> geser: Thanks for that! :)
[12:04] <slangasek> soren: is there any progress on #119075?  it's still assigned to you, who is the "resident Debian maintainer person" mentioned in the log?
[12:04] <slangasek> (bug #119075, let's make that)
[12:04] <ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [High,Confirmed]  https://launchpad.net/bugs/119075
[12:06] <soren> slangasek: funny, I was just writing about it in my weekly activity report. :)
[12:06] <soren> slangasek: If you hang on for two minutes, it'll hit your inbox :)
[12:07] <cjwatson> soren: yeah, I think diffstats are rather unhelpful and pointless too
[12:07] <soren> cjwatson: What's the policy for UVFe request for main? Same?
[12:07] <cjwatson> do something sensible
[12:07] <cjwatson> diff is just fine
[12:09] <slangasek> soren: heh, cheers
[12:12] <Whoopie> smurf: Hi again, I tested with a feisty live CD and the problem also exists there with generated acpi events when changing brightness via sysfs.
[12:13] <Whoopie> smurf: so it's not a regression, "just" an annoying DSDT "feature".
[12:19] <slangasek> soren: FWIW, my take on the question, if the permanent fix isn't available yet, is that it's better to prompt for a mysql root password than to leave the server unsecured, and it's better to prompt for this password during the install then to require the user to take some post-installation action before being able to use the server.  do you agree?
[12:20] <soren> slangasek: Are you familiar with the policy about questions during install?
[12:20] <Riddell> keescook: that's those kdelibs/base and qt3/4 security patches all up to date in gutsy
[12:21] <slangasek> soren: perhaps not. :)
[12:23] <slangasek> soren: but feel free to turn the comparison on its head, as an assertion that these two options are both worse than a "prompt during install" option that's considered unacceptable
[12:23] <cjwatson> soren: FWIW, the policy applies to the default Ubuntu desktop install
[12:24] <slangasek> (i.e., I'm not saying "we should prompt during install", I'm saying "we should rule out these other solutions and see what's left")
[12:24] <soren> cjwatson: Ah, really?
[12:24] <cjwatson> soren: if it's necessary to achieve security, I don't think anyone's going to shoot you for an extra question during the Ubuntu server install if you select a task involving the mysql server
[12:24] <soren> cjwatson: I've never seen it in writing, actually.
[12:24] <cjwatson> soren: though it probably ought to be regarded as a bug and removed again in a future release
[12:25] <soren> cjwatson: The reason it came up, was because someone (fabbione, I think) pointed out that we shouldn't be asking more questions than in previous releases due to a sabdfl decree :)
[12:25] <cjwatson> soren: it's sort of one of the bits that are embedded in the heads of the founding developers and people have varying interpretations
[12:25] <cjwatson> but the original decree was in the days when we had one CD and that was it
[12:25] <cjwatson> we should of course avoid drifting towards infinity-questions installs
[12:26] <soren> cjwatson: Of course, of course.
[12:26] <cjwatson> https://wiki.ubuntu.com/UbuntuArchitecture states something in the general vicinity of this but isn't terribly explicit
[12:26] <cjwatson> I'll see if I can think of something coherent
[12:27] <slangasek> "Applications should work immediately upon installation, without requiring additional steps, whenever possible. This "instant gratification" makes users more productive and allows them to explore the software choices available"
[12:27] <soren> cjwatson: That would be much appreciated. It's one of the policies many people refer to, but noone can actually define.
[12:27] <cjwatson> soren: like slangasek, I'm not saying "you should do this", but don't discard it out of hand
[12:27] <slangasek> there you go, installing a broken mysql server package and expecting the user to configure it later is a bad idea ;)
[12:28] <soren> cjwatson: Well, since we're in no position to do the "right thing" (i.e. making the mysql-owning user able to do admin stuff to mysql), the proper thing to do IMO is ask the question.
[12:29] <soren> I just thought that was out of the question.
[12:29] <slangasek> soren: setting a random password isn't an acceptable workaround?
[12:29] <soren> slangasek: No.
[12:29] <slangasek> ok
[12:29] <soren> slangasek: That makes it *really* difficult for novice admins to do anything at all to their mysql server.
[12:30] <soren> slangasek: They'd have to either remember to write it down if we show it during install (noone ever does that) or be able to find it easily somewhere.
[12:30] <soren> ...but making it easy to find, makes it hard to keep secret :)
[12:31] <slangasek> right, or if we gave them a way to reset the password without knowing it, this would be Ubuntu-specific and not described in any of the upstream/generic howtos
[12:31] <soren> slangasek: I had a patch to do that, actually.
[12:31] <cjwatson> plus showing a password during install is an instant pass for a hysterical slashdot article ;)
[12:31] <soren> slangasek: It used the debian-sys-maint user, but it was rejected, afair.
[12:33] <soren> I'll see if I can dig it up and see if it makes sense at this point. Tomorrow, though.
[12:33] <slangasek> ok, 'night
[12:33] <soren> Night, all.