[00:19] <quadrispro> pitti, bug 512048 -> fixed in debian, thank you!
[01:54] <owen1> how to find a maintainer of a specific driver?
[01:55] <crimsun> owen1: which touchpad driver? also, X Window System driver or kernel driver?
[01:55] <owen1> driver for touchpad. it's elantech.
[01:55] <owen1> crimsun: dell inpiron 11z and dell mini 10 both comes with this touchpad.
[01:56] <owen1> crimsun: and i can't configure it at all. i am about to give up and return my laptop to dell.
[01:56] <owen1> crimsun: http://ubuntuforums.org/showthread.php?t=1347942&page=2
[01:57] <crimsun> xserver-xorg-input-synaptics and linux certainly are new enough
[01:57] <crimsun> do you have a pointer to a specific bug report on Launchpad?
[01:58] <owen1> crimsun: no. i did'n know it's a bug.
[01:59] <owen1> crimsun: i'll go there and look for bug reports. maybe someone mentioned it.
[01:59] <owen1> crimsun: can u take a look at this link- http://arjan.opmeer.net/elantech/
[01:59] <owen1> is it helpul in any way?
[02:00] <crimsun> I already looked, which is why I mentioned the above source packages.
[02:04] <owen1> crimsun: i am sorry but i am a bit confused. did u find a bug report about the issue?
[02:04] <owen1> crimsun: if not, i'll be happy to add a bug.
[02:05] <crimsun> owen1: I did not look; I'm busy ATM.
[03:05] <owen1> crimsun: np. i'll go to launchpad
[04:25] <owen1> here is a similar bug - https://bugs.launchpad.net/ubuntu/+source/gsynaptics/+bug/132627
[04:26] <owen1> how was it fixed?
[04:27] <owen1> the original bug is for 7.04 and i have 9.10.
[04:27] <owen1> i think it's related to elantech touchpads.
[04:28] <owen1> they are not recognized for some laptops (inspiron 11z and mini 10)
[04:30] <owen1> can anyone help me with submitting bug to launchpad?
[04:30] <owen1> i am not sure if i should create new bug
[04:32] <persia> owen1: If it's not the same hardware, you'll want a new bug.
[04:33] <persia> You might try running `ubuntu-bug xserver-xorg-input-synaptics`
[04:34] <persia> Most bug discussion happens in #ubuntu-bugs, but that's more about bug triage than about actually solving them.
[04:34] <kees> pitti: say, can we just disable palimpsest?  it seems to be warning way too much (bug 438136)
[04:34] <persia> You might also find useful support in #ubuntu
[04:34] <kees> i'd kind of like to SRU it off too
[04:35] <persia> kees: I was going through FTBFS this weekend, and got stuck with libpam-alreadyloggedin : it appears to get confused by some of the stack-smashing-protection, but only for i386 and powerpc.  Am I on the right track, or confused by some byproduct?
[04:36] <kees> persia: hrm, confused how?
[04:36]  * kees reads the buildlog...
[04:36] <persia> https://launchpad.net/ubuntu/+source/libpam-alreadyloggedin/0.3-1/+build/1428110/+files/buildlog_ubuntu-lucid-i386.libpam-alreadyloggedin_0.3-1_FAILEDTOBUILD.txt.gz
[04:37] <persia> I had similar sorts of issues for libpam-slurm, and ended up fixing those by adding lots more -nostdlib calls to the Makefile, but that felt like a big hammer.
[04:37] <kees> yeah, -nostdlib is the right fix, but it's weird that amd64 didn't blow up in the same way
[04:38] <kees> err ..  -lc
[04:38] <persia> That was why I asked.  I had thought SSP would be on amd64, but nothing seems to fail there.
[04:38] <kees> that would imply libc ??
[04:40] <kees> persia: OH!
[04:40] <kees> ld instead of gcc
[04:40] <kees> wrong: ld -lpam --shared -lc pam_alreadyloggedin.o -o pam_alreadyloggedin.so
[04:40] <kees> right: gcc -lpam --shared -lc pam_alreadyloggedin.o -o pam_alreadyloggedin.so
[04:41] <persia> OK.  Would you be up for explaining why?
[04:41] <persia> Also, if you had any ideas why it worked on amd64, I'd be interested.
[04:44] <jono> any build admins able to bump a package up the queue
[04:44] <jono> I need Lernid to be built in my PPA ready for developer week starting
[04:50] <kees> persia: because the compiler has the logic for knowing how to call the linker correctly. i think -shared turns off somethig there
[04:51] <kees> not sure why it worked on amd64, maybe the linker handles things differently there
[04:51] <persia> OK.  Thanks for the hint.  I'll go look at --shared in hopes of understanding at least a little bit before uploading :)
[04:51] <kees> i think this is a flaw in my modifications of the spec files, ld must be missing something.
[04:53] <persia> You might also want to look at libpam-slurm if you're looking at stuff, as it shows the same broken on i386/works on amd64 behaviour if you remove my latest patch.
[04:53] <persia> And it uses gcc for all the calls when doing so.
[05:05] <nixternal> kees: dude, I am scared now...I live in a gated community, and the closest streetview is over 2 miles away...the community voted to not allow google in our subdivision, yet the mac address at my house is dead on, and the mac address here at my girlfriends is dead on...this is way to freaky
[05:06]  * persia pipes whois output to the OMCD
[05:09] <nixternal> yeah, that definitely belongs on charles darwin, now that I figured it out after the fact
[05:10] <persia> Not really.  It's probably your ISP providing data.
[05:10] <persia> Get a more private ISP, or set up fancy tunnels.
[05:10] <nixternal> att uverse at both locations
[05:10] <persia> Right.  Tunnel it is then.
[05:11] <persia> Get a vhost somewhere and set up a VPN.
[05:11] <nixternal> my cell phone on the other hand, isn't even close
[05:12] <johanbr> that's probably the location of your carrier's internet gateway
[05:13] <nixternal> if that were the case, then the gateway is in both my house and my girlfriends house :)
[05:13] <nixternal> it seems that att, like persia said, is giving out way to much info
[05:14] <persia> Well, depends on the user.  Some users prefer convenience to privacy.
[05:14] <jono> any build admins around?
[05:16] <StevenK> jono: To retry, or bump the score?
[05:19] <ScottK> nixternal: I was driving to pick up one of my kids from a friends house last night and using the Google navigation feature on my 'droid.  When I got to the destination it popped up a picture of the house so I could know which one it was.  It was totally cool.
[05:19] <jono> StevenK, it is down to build in two days
[05:19] <jono> and I really need a Lernid and Karmic build ready for Ubuntu Developer Week which starts on Monday
[05:19] <nixternal> this is really weird, persia even if I do use a tunnel, it knows where that MAC address is located
[05:20] <jono> can you help bump it up, StevenK?
[05:20] <persia> nixternal: Then you don't have enough hardware between your device and your tunnel.
[05:20]  * persia takes this somewhere slightly less off-topic
[05:21] <StevenK> jono: "It"? And I can't, but I can help get it done
[05:21] <jono> StevenK, Lernid
[05:21]  * Hobbsee looks in
[05:21] <Hobbsee> jono: in a ppa, or main archive, or?
[05:21] <jono> Hobbsee, hi! thanks :-)
[05:21] <jono> it is in my PPA
[05:21] <jono> Lernid 0.5
[05:21] <jono> I kicked off a Lernid built and then I planned a copy for a Karmic build
[05:21]  * Hobbsee looks it up
[05:21] <StevenK> https://edge.launchpad.net/~jonobacon/+archive/ppa/+build/1465979
[05:22] <StevenK> Hobbsee: ^
[05:22] <jono> https://edge.launchpad.net/~jonobacon/+archive/ppa/+build/1465979
[05:22] <jono> aha :)
[05:22] <Hobbsee> jono: prodded
[05:22] <jono> Hobbsee, what do you mean?
[05:22] <jono> oh wow!
[05:22] <Hobbsee> jono: it means i took it on a walk
[05:22] <jono> you are a rockstar :)
[05:23] <Hobbsee> jono: for reference, it's great if you can provide that link earlier, so buildd admins don't have to scramble looking for which you might mean, particularly if it's for a ppa ;)
[05:23] <Hobbsee> haha, np
[05:23] <jono> Hobbsee, will do :)
[05:23] <jono> thanks!
[05:24]  * Hobbsee starts to think it'd be nice for buildd to be modified to work for ppas too
[05:26] <Hobbsee> jono: how clever
[05:27] <jono> Hobbsee, :)
[05:27] <StevenK> And lernid is built
[05:27] <owen1> persia: thanks
[05:27] <Hobbsee> nice, i like how it's clear on what stage it's up to now, and why it isn't there in the archive yet
[05:28] <persia> owen1: That worked for you then?  Excellent.
[05:28] <jono> Hobbsee, mind doing the same for https://edge.launchpad.net/~lernid-devs/+archive/lernid-releases/+build/1466114 ?
[05:29] <owen1> persia: i just read your reply, didn't run that command yet
[05:30] <Hobbsee> jono: prodded with the Long Pointy Stick of Doom!!!! ™
[05:30] <jono> Hobbsee, that stick is awesome!
[05:30] <Hobbsee> jono: very!  it's had a long vacation
[05:30] <jono> Hobbsee, good to be back :-)
[05:30] <Hobbsee> so is nicely sharp and pointy, ready for it's next adventures
[05:30] <Hobbsee> yup!
[05:30]  * jono hugs Hobbsee :)
[05:30] <Hobbsee> :D
[05:31] <jono> Hobbsee, you must be so pleased :)
[05:32] <StevenK> Hobbsee: That's what happens when you store the Long Pointy Stick in a pencil sharpener when you're not using it
[05:33] <Hobbsee> StevenK: if i'd done that, i don't think it'd exist anymore
[05:33] <Hobbsee> it'd be all sharpened out
[05:33] <persia> At least it wouldn't be so long.
[05:33] <StevenK> Damn, my plan has been foiled.
[05:33] <jono> Hobbsee, is there likely to be a delay in publishing the packages?
[05:33] <jono> as in, a 2 day delay
[05:33] <jono> :)
[05:34] <StevenK> jono: Nope.
[05:34] <Hobbsee> jono: nah.  publishing happens every 20 minutes, last i knew
[05:34] <jono> sweet :)
[05:35] <Hobbsee> wow, +builds has had a lot of improvements.  Think i'll have to close some of my bugs against it
[05:35] <jono> all set for Ubuntu Developer week :)
[05:35] <jono> Lernid is rocking :)
[05:37] <wgrant> Hobbsee: */5, now! You are behind the times.
[05:37] <Hobbsee> wgrant: oh nice.  very behind the times
[05:37] <Hobbsee> wgrant: seeing as you are not, do you know how i get https://bugs.edge.launchpad.net/~hobbsee to work?
[05:38] <wgrant> Hobbsee: Use production.
[05:38] <wgrant> There is a bug.
[05:38] <Hobbsee> oh yeah
[05:38] <Hobbsee> rightio
[05:38] <wgrant> I believe the bugfix is yet to land, although it has been written.
[05:38]  * StevenK attempts to get undistracted
[05:39] <Hobbsee> fair enough
[05:43]  * ScottK cheers the reappearence of the stick.
[05:43] <ScottK> StevenK: Thanks for luatex.
[05:43] <owen1> persia: ok, i submitted new bug. thanks
[05:43] <owen1> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/512192
[05:43] <Hobbsee> heya ScottK!
[05:43] <ScottK> Heya Hobbsee.
[05:44] <persia> owen1: Good luck.
[06:45] <jono> what is the best way for me to re-build Lernid 0.5 but for Lucid?
[06:45] <jono> in https://edge.launchpad.net/~lernid-devs/+archive/lernid-releases
[06:49] <RAOF> jono: Looks like you should be able to safely binary-only copy that to lucid.
[06:49] <dholbach> good morning
[06:50] <jono> RAOF, you think?
[06:51] <RAOF> jono: You could copy the source & have to poke to have it rebuilt again, but it's pure-python, right?
[06:51] <jono> RAOF, it is
[06:51] <jono> it just has a stack of dependenices
[06:51] <jono> dependencies
[06:52] <RAOF> It looks like they're all satisfied on Lucid, as well.
[06:53] <RAOF> And you'll have manually specified those dependencies, because we aren't awesome enough to extract python dependancies from python source.
[06:53] <StevenK> RAOF: "Yet"
[06:54] <RAOF> StevenK: Indeed.
[06:56] <RAOF> It's not as easy as extracting shlib depends, but it's not impossible.
[07:06] <persia> RAOF: Doesn't ${python:Depends} try to do something like that?
[07:07] <ScottK> persia: Mostly it helps pick the right version of the python interpreter to depend on.
[07:08] <ScottK> Someday ....
[07:08] <persia> Ah.  I thought it somehow dig into setup.py and did the right thing
[07:08] <persia> s/dig/dig/
[07:08] <persia> dug!
[07:08] <ScottK> dog?
[07:11] <RAOF> dag
[07:12] <persia> No, really, dug.  Not quite the same vowel transition as sit/sut, but the same idea.
[07:12]  * persia wishes for a sanely conjugated language as the de facto international default
[07:13] <RAOF> All languages have their little excentricities :)
[07:13] <RAOF> Sometimes native-speakers are even able to spell each word in a sentence correctly, too.
[07:14] <StevenK> If we're lucky
[07:14] <persia> Somehow I suspect some difficulties combining that with grammatical sanctity.
[07:17] <pitti> Good morning
[07:18] <ScottK> Good morning.
[07:18] <ScottK> pitti and lool: Thanks for the quick MIR review on luatex over the weekend.
[07:31] <pitti> kees: "disable palimpsest"?
[07:31] <pitti> kees: oh, the bad block warning; we should perhaps disable that if it's not fixed in time, indeed
[07:57] <siretart`> could someone please sync epiphany-extensions from debian/unstable? It doesn't look like it will find its way to testing soon, but epiphany 2.29 is already in lucid. I'll file a sync request later…
[07:58] <pitti> siretart`: synced
[07:59] <xnox> Good morning everyone! =) I have exam today, wish me luck =) Testing alternative daily cd now
[08:04] <owen1> persia: someone has the same touchpad issue as me!
[08:05] <owen1> how many people should be affected by a bug so it will be fixed by ubuntu developers?
[08:08] <kees> pitti: it's not fixed in karmic too -- it's causing a lot of bug reports.
[08:08] <kees> nixternal: yikes. :P
[08:15] <siretart`> pitti: thanks!
[08:17] <DktrKranz> pitti: wrt python-launchpadlib, I'm going to include fix in Debian too, thanks for fixing!
[08:18] <pitti> DktrKranz: thanks! I sent a Debian bug, just didn't receive the ack for it yet
[08:19] <DktrKranz> fine, thanks again :)
[08:25] <pitti> DktrKranz: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566795
[08:33] <DktrKranz> pitti: committed as http://svn.debian.org/viewsvn/python-modules?view=rev&revision=11298
[08:33] <pitti> \o/
[09:52] <slangasek> Keybnz: ok, I've committed my attempt at splitting the plymouth upstart job; I've exercised it every way I can think of here (startup, shutdown, with or without being pulled into the initramfs, adding some sleeps here or there to cause races), and it's standing up for me
[09:53] <slangasek> Keybnz: but I'd like it if you could give it a once-over before I upload
[10:04] <dpm> hey, good morning pitti. We've got a bug with a karmic-proposed language pack (bug 511837) - What's the usual procedure to sort this out? Do I simply ask you or any archive admin for removal of the package?
[10:16] <pitti> hey dpm
[10:16] <dpm> hey :)
[10:16] <pitti> dpm: if the others work fine, then let's just remove that -proposed version, indeed
[10:17] <pitti> dpm: however, a better fix would of course to upload a new langpack with a fix; so that's not easy to do?
[10:18] <dpm> pitti, yeah, altough we haven't yet located the problem
[10:18] <dpm> the cause, I mean
[10:18] <pitti> dpm: -gnome-ast is okay, though?
[10:19] <dpm> pitti, they've only complained about the -ast one, as they've noticed the problem with FF, which is in that pkg
[10:20] <dpm> pitti, let me ask you something else somehow related first:
[10:20] <dpm> you copied the 20090115 PPA langpacks to karmic-proposed at Arne's request, but at around the same time the 20090122 language packs were released on the PPA.
[10:21] <dpm> I want to make a call for testing, but for those using the PPA it might be a bit cumbersome, since they'll have to downgrade to the 20090115 langpacks in karmic-proposed in order to test them
[10:21] <dpm> Do you think it might be possible to copy all the 20090122 PPA langpacks to karmic-proposed? Is it an involved process?
[10:22] <pitti> dpm: not involved for me, just takes some buildd time
[10:22] <pitti> dpm: I'm happy to move them over if you want those tested instead
[10:23] <pitti> dpm: language-pack-ast removed from karmic-proposed, btw
[10:23] <pitti> dpm: so want me to copy ppa to proposed (except -ast)?
[10:24] <dpm> pitti, if possible, yes, please, all 20090122 from the PPA to karmic-proposed except -ast
[10:28] <pitti> dpm: running now
[10:28] <pitti> dpm: ETA half an hour for copying the sources, and perhaps a day for all the binaries to get built
[10:28] <dpm> awesome, thanks pitti!
[10:28] <pitti> you're welcome
[10:39] <slangasek> persia: 20:00 UTC on Friday... hmm, not having managed to get around to prepping for it this weekend, I probably shouldn't commit, no :/
[10:41] <persia> slangasek: Well, let me know if you change your mind.  I'm more than happy to not get up early, and while I'll prep, it's not much (as I've given the same session a few times before).
[10:42] <hiexpo> hello all
[10:48] <slangasek> persia: ack, thanks
[10:57] <MacSlow> seb128, do you know which module provides /usr/bin/g-ir-scanner?
[10:58] <seb128> which binary you mean in lucid?
[10:58] <seb128> gobject-instrospection
[10:58] <cjwatson> MacSlow: http://packages.ubuntu.com/
[11:01] <MacSlow> seb128, cjwatson: thanks
[11:19] <lool> Is there a place where I can easily see the dependencies between pockets?
[11:19] <lool> I guess it's somewhere in the Launchpad source code, I would guess near the ogre-model implementation
[11:20] <persia> lool: How do you mean?  Which pockets depend on which other pockets?
[11:20] <lool> persia: Yes
[11:20] <lool> e.g. -proposed depends on -updates
[11:21] <persia> It's main->(null), restricted->(main), universe->(main), multiverse->(main,restricted,universe)
[11:21] <lool> I'm not quite sure whether -updates depends on -security since the security updates are copied
[11:21] <persia> Oh, at that level.
[11:21] <lool> persia: I mean pockets, not components
[11:21] <persia> Oh, sorry.  I'm not sure.
[11:28] <ogra> Keybnz, are you around by chance ? i'm trying to find out how plymouth is supposed to work, i seem to be able to run it imaually on my babbage board and get a progressbar on tty8 but i dont see anything on boot
[11:30] <ogra> *manually
[11:34] <pitti> cjwatson: in GNOME, gnome-keyring-daemon already provides an ssh auth agent and sets $SSH_AUTH_SOCK; would it be okay if 90x11-common_ssh-agent would check that condition (i. e. running gnome and gnome-keyring autostart exists) and not run ssh-agent in that case?
[11:35] <cjwatson> pitti: if you can stop me being flooded with bug reports about that ssh agent sucking?
[11:35] <pitti> cjwatson: (i. e. without that Xsession.d script we save the0.7 second overhead, but still retain the nice UI password dialogs)
[11:35] <cjwatson> I wish we could *only* use the openssh one, frankly
[11:35] <apachelogger> asac: ping
[11:36] <pitti> cjwatson: well, I asked you only the second time now; but instead of just doing it, I'd rather check with you first
[11:36] <pitti> I don't see an obvious benefit for day-to-day desktop use, but I'm sure you know better what else it is used for
[11:36] <cjwatson> whatever, do it
[11:36] <cjwatson> I'll ask you any time I get a bug about it
[11:36] <pitti> cjwatson: what kind of UI would ssh-agent2 use?
[11:37] <cjwatson> day-to-day> this is the fallacy of novice users ...
[11:37] <pitti> right, and that's why I'm asking you :)
[11:37] <cjwatson> the point is that if we're making it difficult to use the openssh agent, the GNOME one had better be absolutely robust
[11:37] <pitti> since at least under GNOME, gnome-keyring does the password input, not ssh-agent (apparently)
[11:37] <cjwatson> and it isn't, judging from my bugmail
[11:37] <cjwatson> the openssh agent spawns ssh-askpass
[11:38] <pitti> well, how do you suppress g-keyring UI today?
[11:38] <seb128> you turn off the gnome-keyring autostart I guess
[11:38] <pitti> I'm not talking about removing the Xsession.d file; we need it for !GNOME or for people who remove the autostart file
[11:38] <seb128> using the capplet
[11:38] <pitti> seb128: right
[11:38] <pitti> but we can check for exaclty that
[11:39] <seb128> the change would break that
[11:39] <seb128> since the etc autostart will not go away
[11:39] <seb128> a .local one is written
[11:39] <seb128> when you uncheck it using the capplet
[11:39] <pitti> seb128: ah, good to know
[11:39] <pitti> now, still easy to test
[11:39] <cjwatson> pitti: what exact diff are you talking about applying here?
[11:39] <pitti> cjwatson: I don't have the diff yet; talking about strategy before starting to mess up things
[11:40] <cjwatson> AFAICS that Xsession script *already* checks [ -z "$SSH_AUTH_SOCK" ]
[11:40] <seb128> right, but it's ran before gnome-keyring
[11:40] <pitti> right, but g-k is started later on
[11:41] <cjwatson> how can we make it straightforward for people to use g-k for gpg but not ssh?
[11:41] <pitti> if there's a good argument for keeping it running even under GNOME, I'm happy to take a look at the ssh-agent code and see whether things can be moved around
[11:41] <pitti> to not block the startup for that long until it forks
[11:41] <seb128> cjwatson, g-k doesn't do gpg
[11:41] <seb128> cjwatson, seahorse does
[11:41] <cjwatson> oh
[11:41] <cjwatson> is it not seahorse that's being the ssh agent then?
[11:41]  * cjwatson is confused about how all the pieces fit together
[11:41] <seb128> no, gnome-keyring is
[11:41] <seb128> seahorse is the gpg agent
[11:42] <cjwatson> ah
[11:42] <cjwatson> pitti: the good argument is that ssh-agent is much more robust
[11:42] <seb128> (which we don't install by default)
[11:42] <cjwatson> I keep getting bugs about the agent having died; they always turn out to be because people were using g-k
[11:42] <seb128> urg
[11:43] <cjwatson> we may have been reassigning some of them incorrectly to seahorse
[11:43] <seb128> I will check
[11:43] <seb128> but I'm subscribed to both and see very few crashers there
[11:43] <cjwatson> and I think g-k doesn't support all the features either; IIRC it doesn't support time-limited identities
[11:43] <cjwatson> well, it's some for g-k versus none for openssh :)
[11:44] <seb128> right
[11:44] <seb128> I've no opinion on whether you should better fix gnome-keyring or drop it
[11:44] <pitti> oh, ssh-agent doesn't cache passphrases by default?
[11:44] <pitti> ah, ignore me
[11:45] <seb128> I've no issue with gnome-keyring and I expect it works for most users just sshing random boxes
[11:45] <cjwatson> I'd definitely like to know why ssh-agent makes a significant difference to startup time
[11:45] <cjwatson> it does hardly anything on startup
[11:45] <seb128> it might have limitation than power users hit though
[11:45] <pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3.png vs. http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3-no-ssh-agent.png
[11:46] <pitti> (note that on the former, the first gnome-session process is actually ssh-agent, due to the fork/execve'ing bootchart gets confused)
[11:47] <cjwatson> an strace would be useful
[11:48] <pitti> hm; I disabled the g-k autostart .desktop, and I still don't get passphrase caching
[11:48] <pitti> seb128: anyway, text-mode only input isn't really an option, is it? (i. e. dropping g-k); it would break sftp gvfs connections and all that?
[11:48] <pitti> cjwatson: aye, I'll give it some tracing
[11:49] <cjwatson> dropping g-k isn't text-mode-only
[11:50] <pitti> hm, perhaps the agent just isn't working for me
[11:50] <cjwatson> ssh-add reads a passphrase from the terminal if it has one, but if it doesn't have one and it has $DISPLAY, it uses ssh-askpass-gnome
[11:51] <ogra> god !
[11:51] <ogra> who decided to lock my screen every time DPMS kicks in
[11:51] <ogra> thats overly annoying
[11:51] <cjwatson> of course we don't install ssh-askpass-gnome by default ...
[11:51] <cjwatson> oh, we do
[11:51] <pitti> we don't, but that could be fixed
[11:52] <cjwatson> we do, it has Task: ubuntu-desktop
[11:52] <pitti> ah, it's called gnome-ssh-askpass, sorry
[11:52] <cjwatson> oh, the binary is, yes
[11:53] <cjwatson> I wonder if it's taking ages to seed the RNG for some reason
[11:53] <pitti> hm; $SSH_AGENT_PID points to ssh-agent, and $SSH_AUTH_SOCK is set as well
[11:54] <ion> We could put 50 megabytes of random bits to the installer CD and have installations use the file for fast random numbers.
[11:55] <pitti> FSVO "random", yes :)
[12:00] <pitti> so, AFAICS the check for "will gnome-keyring be running" should be done either way, since g-k just shadows ssh-agent
[12:01] <pitti> but there's still the option of disabling g-k by default and thus making ssh-agent actually used
[12:01] <cjwatson> bugs in g-k relevant to ssh: bug 505278 (missing feature, arguably dangerous), bug 485537 (stability), bug 470456 (key decode problem?), bug 418879 (stability), bug 383926 (stability), bug 365589 (stability) ...
[12:02] <cjwatson> it appears that generally gnome-keyring just stops accepting connections rather than actually crashing
[12:03] <cjwatson> the failure mode where it all gets stuck and ssh-add -l says it can't connect to the agent seems moderately common
[12:03] <pitti> hm, I still can't get this to work; "ssh-agent /bin/bash" sets the $SSH_* but doesn't do any caching; so it seems the Xsession.d script is actually wrong
[12:04] <pitti> cjwatson: thanks for fishing out the bugs; that's good to know for deciding which one to use by default
[12:04] <cjwatson> oh and some problem with the confirmation prompt which seems like it might be bound up with a bug or two in openssh as well?  bug 209447
[12:04] <pitti> oh, you have to explicitly use ssh-add
[12:05] <cjwatson> yes
[12:05] <cjwatson> looks like I ought to backport the patch from https://bugzilla.mindrot.org/show_bug.cgi?id=1612
[12:06] <cjwatson> but 209447 still indicates that ssh-add -c will be ineffective with g-k
[12:07] <cjwatson> pitti: users of openssh ssh-agent and g-k do have slightly different expectations
[12:07] <pitti> *nod*
[12:07] <cjwatson> the expectation with g-k is (as far as I can tell?) that it loads all your identities automatically
[12:07] <cjwatson> the expectation with ssh-agent is that you have to explicitly request addition of the identities you want
[12:07] <pitti> but if you always have to open a terminal to do "ssh-add" and enter your passphrase, where does the UI come into play?
[12:08] <cjwatson> I believe that if you use an ssh program without a terminal attached, you should get a passphrase prompt too ...
[12:08] <cjwatson> it just won't cache it
[12:10] <cjwatson> hmm, maybe I'm wrong
[12:11] <cjwatson> if I could remember how to detach from a tty, I could test this :)
[12:11] <pitti> hmm; if I kill g-k, have ssh-agent running, and use "Connect to server" (sftp), I again get a g-k dialog
[12:11] <pitti> cjwatson: "nohup program"?
[12:12] <pitti> no, doesn't work, sorry (that just diverts stdin)
[12:12] <pitti> Alt+F2 "ssh foo" -> that works
[12:12] <geser> I remember some packages linking against python and failing because of -lssl missing. Does someone remember how to fix it? Because I've a similar issue when merging vim (the python interpreter support doesn't get build-in because of this).
[12:12] <pitti> I see gnome-askpass-ssh
[12:13] <cjwatson> ah yes, thanks
[12:13] <seb128> geser, yes, one minute, I look for the change
[12:14] <cjwatson> similarly command-line sftp from Alt-F2 works
[12:14] <cjwatson> I'm not sure what "Connect to server" is doing
[12:14] <seb128> geser, https://bugzilla.gnome.org/attachment.cgi?id=146930
[12:14] <seb128> geser, see https://bugzilla.gnome.org/show_bug.cgi?id=600706
[12:14] <pitti> cjwatson: it uses gvfs' sftp module to create a virtual mount (thruogh sftp)
[12:14] <cjwatson> I guess the question is whether the expectations of openssh ssh-agent are sufficiently different to make it difficult to migrate to in the Ubuntu desktop
[12:15] <seb128> geser, could be similar
[12:15] <pitti> cjwatson: right now it seems that g-k is woven pretty tightly into gnome; I'm not sure it'd be a good idea to rip that all apart in an LTS
[12:16] <seb128> there is no reason we could fix the few issues g-k has, it doesn't seem to be too buggy
[12:16] <seb128> couldn't
[12:17] <geser> seb128: thanks, I'll check if I get this adopted to vim. Should this be forwarded to Debian (I don't know if Debian's python and ours are similar enough to cause similar problems in Debian too)?
[12:18] <seb128> geser, dunno if that's similar but the use is wrong in any case
[12:18] <cjwatson> seb128: the concurrency issue is the big one, I think
[12:18] <seb128> geser, having it failing it build now is just a sideeffect
[12:19] <geser> ok
[12:19] <cjwatson> it would be nice to add the missing agent protocol features as well, but concurrency problems are the ones that bite most users
[12:20] <seb128> right
[12:20] <seb128> we should try to get this one fixed in any case
[12:20] <seb128> would be useful to have an overview of the behaviour difference
[12:21] <seb128> and how gnome-keyring integrates in GNOME where the openssh one doesn't
[12:21] <pitti> cjwatson: so, thanks for your help! it doesn't seem useful to me to have two agents running at the same time, so I'll work on that Xsession.d script
[12:21] <cjwatson> looks like the bug reports on gnome-keyring are reasonably complete
[12:22] <cjwatson> pitti: yes; as long as there's a reasonably easy (preferably documented!) way to use the openssh one
[12:22] <pitti> cjwatson: ^ I agree; that's the very same problem right now, though (i. e. disable gnome-keyring autostart)
[12:22]  * pitti ponders where to add that
[12:23] <pitti> could go into a comment into that Xsession.d file, but that's not very visible
[12:23] <cjwatson> that would be OK
[12:28] <cjwatson> pitti: perhaps a link to http://live.gnome.org/GnomeKeyring/Ssh
[12:28] <cjwatson> or just the gconftool command from there
[12:29] <pitti> ah, thanks
[12:30] <persia> I'd much prefer actual documentation than a web link: sometimes I am in networks where ssh is permitted and http is not.
[12:30] <pitti> seb128: hm, querying for a gconf key is much more expensive than querying for the presence of an autostart file
[12:30] <seb128> pitti, sure, it uses gconf
[13:08] <NCommander> Does anyone know if quilt will make a directory if need be?
[13:08]  * NCommander can't remember if it does on the fly
[13:08] <persia> NCommander: It depends on your .quiltrc
[13:08]  * persia hunts up the super-cool script
[13:08] <NCommander> persia, I meant if building on the biuldds.
[13:09] <NCommander> persia, I've almost finished porting likewise to ARM, but I need to add a new directory with files in it
[13:09] <persia> You mean, can a quilt patch create a directory?
[13:09] <NCommander> persia, yeah
[13:09] <persia> Yes, that's no problem at all, so long as it contains contents.
[13:11] <persia> Anyway, the cool snippet fell off p.d.o anyway.  It automagically created debian/patches if needed.
[13:11] <persia> s/anyway//
[13:13] <jdstrand> lool, persia: re components> https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories
[13:13] <jdstrand> lool, persia: (and pockets)
[13:14] <persia> jdstrand: Cool.  Thanks.
[13:15] <lool> jdstrand: excellent, thanks
[13:19] <persia> jdstrand: Is there a -security -> -updates copy that happens as well?
[13:20] <jdstrand> persia: yes. it is a direct pocket copy after the USN is published. we used to only do it periodically, but now we do it after every security update
[13:20] <jdstrand> persia: in practice, -updates should always have -security. that is a procedural issue though, not enforced by the builds. it is possible someone would not perform the pocket copy, for example
[13:21] <persia> OK.  That explains why both -security and -updates ought be in the sources.list.
[13:21] <persia> Is there any difference between security.ubuntu.com -updates and archive.ubuntu.com -updates ?
[13:21] <jdstrand> persia: someone should not run only -updates, correct
[13:21] <jdstrand> persia: someone running on -security is supported though
[13:21] <persia> (just whist I have you answering questions :)
[13:22] <jdstrand> persia: re security.u.c and archive.u.c wrt to -updates> I'm not sure
[13:22] <cjwatson> the other reason why -security is there is that it's quicker - e.g. not dependent on mirror propagation time
[13:23] <cjwatson> persia: the two -updates are identical
[13:23] <persia> cjwatson: Thanks.
[13:23] <cjwatson> the reason we copy stuff to -updates, at root, is that it's much cheaper for Canonical because it means we can use the mirror network - but at the same time having stuff available on -security too means that we don't have to suffer mirror lag for urgent updates
[13:33] <lool> jdstrand: Interestingly, -proposed isn't built with -proposed
[13:33] <lool> I expected otherwise
[13:34] <seb128> lool, that avoids surprises when moving one thing to updates I guess
[13:34] <persia> But we've updated things that depend upon each other before.  Was that always done by pocket-copy from somewhere else?
[13:35] <lool> Same with -backports
[13:35] <lool> seb128: As persia said, sometimes that might be needed
[13:35] <lool> e.g. if you want to push a new xulrunner + new firefox built against it or something
[13:35] <seb128> shouldn't the depends express that in those cases?
[13:35] <persia> -backports definitely builds against -backports.
[13:35] <persia> That's why we do things like backport newer debhelper
[13:36] <lool> seb128: Even if Depends do, how do we push two source packages a and b together if a needs to build against b and b can't go in -updates alone?
[13:36] <persia> I have a suspicion that -proposed builds against -proposed, just in the nature of things.
[13:36] <seb128> lool, move both together?
[13:36] <lool> I suspect so as well; in fact ISTR that we had incidents where we didn't move enough stuff from -proposed to -updates
[13:37] <seb128> right, and I'm wondering if the policy didn't change after those
[13:37] <seb128> but I'm just doing speculations
[13:37] <lool> Same here
[13:37]  * persia as well
[13:37] <seb128> the soyuz guys probably know
[13:38] <persia> So, back to the original question: is there a way to extract this information from LP, which is probably best asked in #launchpad
[13:42] <jdstrand> persia, lool: I'll get an official answer on building -proposed with -proposed and update the wiki
[13:43] <persia> jdstrand: Thanks.  Could you confirm my understanding about backports at the same time, and update that if warranted?
[13:44] <jdstrand> persia: I'm pretty sure that is an omission-- clamav is a good example
[13:44] <jdstrand> persia: but sure
[13:44] <persia> clamav is special: it's often pocket-copied with rdepends (just because it has heaps of them).
[13:45] <jdstrand> persia, lool, seb128: -proposed is built with -proposed and -backports is built with -backports
[13:46]  * jdstrand updates wiki
[13:46] <seb128> jdstrand, hi, thanks
[13:46] <lool> http://paste.ubuntu.com/362605/
[13:46] <lool> jdstrand: ^
[13:47] <lool> lib/lp/soyuz/adapters/archivedependencies.py in lp:~launchpad-pqm/launchpad/devel
[13:47] <jdstrand> lool: cool, thanks :)
[13:47] <lool> It wasn't that hard to find it in the launchpad code after all, and I happened to have a checkout (fortunately)
[13:48] <jdstrand> lool: I asked bigjools who did the same thing for me :)
[13:48] <persia> Ah, so theoretically something could be built in updates against release, security, updates, except policy forbids it.
[13:48] <jdstrand> persia: yeah, I noticed that too. I'm going to add a blurb on that as well
[13:51] <lool> persia: Apparently PPAs have a mode for that
[13:51] <lool> (Which kind of makes sense)
[13:51] <lool> In fact the Default PPA mode is "security dependencies and recommended updates", and I think it's basically it
[14:06] <geser> cjwatson: I've seen that you committed a change to lp:ubuntu/vim but didn't upload it. any reason for this? (I included your change in my vim merge)
[14:07] <cjwatson> geser: I didn't see any rush to upload it
[14:07]  * soren hugs geser 
[14:07] <cjwatson> one of the advantages of lp:ubuntu/... to me is that I don't necessarily have to immediately upload everything I do :)
[14:08] <geser> ok
[14:08] <soren> geser: Thanks! That should get rid of those annoying gtk static gravity warning thingies.
[14:08] <cjwatson> geser: how did you get the merge to work?  'bzr merge-package' wasn't working right for me, and I was waiting for james_w to get back so I could talk with him about it
[14:08] <cjwatson> and I didn't want to do the merge outside bzr and store up trouble for later
[14:08] <geser> cjwatson: by hand :(
[14:08] <cjwatson> won't that make later merges harder
[14:08] <cjwatson> ?
[14:09] <geser> cjwatson: good question
[14:10] <geser> soren: bug #511356 if you're interested
[14:11] <geser> james_w: how to handle the case when "bzr merge-package" doesn't work because it complains about different roots (have to lookup the exact error message if necessary)
[14:12] <cjwatson> oh, I can answer that part of it, you need to backport a patch from bzr.dev
[14:12] <cjwatson> but even after that I ran into trouble
[14:13] <cjwatson> bug 494269 for the first part
[14:13] <cjwatson> after that, I found that merge-package was basically stuck in a conflicts loop and I couldn't figure out how to get it out
[14:17] <sgallagh> tjaalton: Heads-up: we found a serious bug in SSSD 1.0.3 on x86_64. We're going to try to release 1.0.4 today to address it (basically, authentications don't work in 1.0.3 on 64-bit)
[14:17]  * soren would like a --please-accept-that-files-named-the-same-are-in-fact-the-same-in-spite-of-seemingly-being-from-different-roots-and-thus-having-different-file-IDs for "bzr merge"
[14:19] <tjaalton> sgallagh: ok thanks, I haven't managed to get that far anyway :)
[14:20] <sgallagh> tjaalton: No problem, just want to keep you in the loop
[14:20] <tjaalton> sgallagh: appreciate it. I'm on the list and #freeipa as well :)
[14:21] <sgallagh> tjaalton: Well, by mistake we didn't have the discussion about it in #freeipa (wrong channel), so I wasn't sure if you'd notice one patch among dozens on the list :)
[14:22] <geser> cjwatson: I need sponsoring for the vim merge anyways, so I created the classical debdiff (bug #509900)
[14:22] <tjaalton> sgallagh: :)
[15:03] <primes2h> cr3: Hello, just tried latest language-pack and still have a problem in Karmic with checkbox translations. Do you remember?
[15:04] <primes2h> cr3: Tried with latest Lucid and have problem too.
[15:05] <primes2h> It seems it doesn't take updated po
[15:05] <primes2h> also if it's fully translated
[15:06] <primes2h> I remember there was a translation infrastructure to change, due to / issues...
[15:07] <primes2h> cr3: Did you have a look, btw?
[15:08] <primes2h> We know have checkbox partially translated, and translated strings cannot be updated...
[15:10] <cr3> primes2h: I'm in the middle of a few things, but I believe the problem has been fixed but a new release has simply not been pushed.
[15:10] <cr3> primes2h: I've been meaning to do that for a while, but I think you've just given me enough inspiration to do it today :)
[15:10] <primes2h> cr3: is there a ppa to test?
[15:11] <primes2h> cr3: That's nice ;)
[15:11] <primes2h> Thank you
[15:13] <primes2h> cr3: you meant I stress you out enough to give you inspiration, isn't it?
[15:13] <primes2h> ;)
[15:13] <primes2h> s/stress/stressed
[15:14] <cr3> primes2h: I'm attempting to push to my own ppa, which should only take a moment: https://edge.launchpad.net/~cr3/+archive/ppa
[15:15] <primes2h> cr3: cool, I'll check it out and I let you know. Thanks a lot :)
[15:29] <cjohnston> Don't forget... Ubuntu Developer Week is starting in 30 minutes in #ubuntu-classroom and #ubuntu-classroom-chat  - http://wiki.ubuntu.com/UbuntuDeveloperWeek
[15:41] <ion> pitti: Re: desktop-lucid-startup-speed, perhaps by now it would be feasible to make Nautilus paint a transparent background so that the root window shows through if there’s a compositing manager. No need to paint the desktop background twice.
[15:41] <pitti> ion: we don't even have nautilus render the desktop in UNE
[15:41] <pitti> ion: but for standard GNOME that would be nice indeed
[15:53] <ogra> is Keybuk the only pwrson currently working on plymouth or is there anyone else i could talk to about it
[15:53] <mvo> ogra: tseliot most likely
[15:53] <ogra> mvo, ah, thanks
[15:54] <ogra> i see it working on armel if i run it manually ... but it doesnt seem to work by default during boot for whatever reason
[15:54] <OdyX> ogra: look after panthera on OFTC, he packaged it for Debian
[15:54] <ogra> OdyX, but i doubt he has a clue about what has been done in ubuntus initrmafs scripts to make it default :)
[15:55] <ogra> *initramfs
[15:55] <ogra> but thanks for the hint
[15:55] <OdyX> ogra: that's exactly why I point you to him :-)
[15:55] <tseliot> ogra: do you mean, if you run it manually inside X?
[15:56] <ogra> tseliot, nope, i start plymouthd and trigger plmouth with a sleep on tty1, then i see a progressbar on tty7 if i switch over to it fast enough
[15:56] <ogra> so in general it seems to work
[15:56] <tseliot> ogra: doesn't it work if you start the upstart job?
[15:57] <ogra> but it desnt seem to work during boot ... note that i only have a std framebuffer though
[15:57] <ogra> hmm, i didnt test that, one sec
[15:57] <tseliot> ogra: std framebuffer as in what vga16fb gives you? Or something with KMS?
[15:57] <ogra> god ! why is my screen locked all the time !
[15:58] <ogra> tseliot, its ARM ... they usually bring their own framebuffer driver
[15:58] <ogra> but it featurewise it should be on par with vga16fb
[15:59] <ogra> sorry, need to boot my board first before i can check the upstart job
[15:59] <ogra> takes a minute
[15:59] <tseliot> ogra: I was asking as plymouth doesn't work with vga16fb yet
[16:00] <ogra> well, as i said, i see it working on tty7 if i do the above steps
[16:00] <ogra> what does not work there yet ?
[16:01] <tseliot> ogra: plymouth doesn't support 16 colours fbs
[16:02] <ogra> ah
[16:02] <mdeslaur> pitti: what are your thoughts on us releasing security updates for LP: #446299 ?
[16:02] <ogra> well, the framebuffer is also used with xfbdev
[16:02] <tseliot> ogra: but if you say that it works with that fb then it must be something else
[16:02] <ogra> so i would suppose it supports more than 16 cols
[16:03] <tseliot> ogra: I guess so
[16:05] <ogra> ok, running the upstart job gets me the same as my manual thing
[16:06] <ogra> hmm, but i seems it killed the framebuffer this time
[16:07] <ogra> ssh connection is still fine though, but no tty switching or anything is possible anymore
[16:08] <ogra> tseliot, do you know if the vga16fb issues are supposed to be solved before release ? or is there any usplash fallback plan for such setups
[16:09] <tseliot> ogra: either I fix that in time or we use the text plugin. I hope it's the former ;)
[16:09]  * ogra wonders why there are still so many hal processes in lucid 
[16:13] <ccheney> anyone know if doko is working today?
[16:14] <ScottK> I think he's on vacation today.
[16:14] <ccheney> ok
[16:43] <ogra> tseliot, GEEZ !
[16:43] <tseliot> ogra: ???
[16:43] <ogra> tseliot, it works !! ...
[16:43] <ogra> ogra@babbage2:~$ /usr/sbin/plymouth-set-default-theme
[16:43] <ogra> text
[16:43] <ogra> :P
[16:43] <ogra> ogra@babbage2:~$ sudo /usr/sbin/plymouth-set-default-theme ubuntu-logo --rebuild-initrd
[16:43] <ogra> that gets me an ubuntu logo
[16:44] <ogra> (no animation or anything though)
[16:44] <tseliot> aah so including the theme in the initrd works
[16:44] <ogra> tseliot, any idea why it defaulted to text ?
[16:45] <ogra> well, not sure if i needed to include it in the initrd
[16:45] <ogra> the help text said that would be needed after changing the theme
[16:45] <ogra> so i just added that option ... i didnt try without
[16:45] <tseliot> ogra: we don't do it by default. only in case of encrypted disks
[16:46] <ogra> ah
[16:46] <ogra> i'll try to revert to the former state and see if just setting it without rebuilding initrd fixes it too
[16:47] <tseliot> ok
[16:47]  * ogra runs sudo /usr/sbin/plymouth-set-default-theme text --rebuild-initrd
[16:47] <ogra> i guess that gets me beck to original state
[16:47] <ogra> *back
[16:50] <tseliot> ogra: I think you could change /lib/plymouth/themes/default.plymouth and remove the text plugin from the intrd
[16:50] <ogra> ah, k
[16:50] <ogra> its intresting that it works flawless in our other armel hardware
[16:51] <ogra> i wonder what selects text at first place
[16:52] <tseliot> ogra: maybe there's some fallback which selects the text plugin
[16:52] <ogra> we should amke sure its not falling back on imx51 then :)
[16:52] <tseliot> slangasek: did you work something similar? ^^
[16:52] <ogra>  /lib/plymouth/themes/default.plymouth looks like everything points to ubuntu-logo
[16:54] <ogra> aha
[16:54] <ogra> # plugins that are always required
[16:54] <ogra> copy_exec /lib/plymouth/text.so /lib/plymouth/
[16:54] <ogra> copy_exec /lib/plymouth/details.so /lib/plymouth/
[16:54] <ogra> so text is always there
[16:54] <ogra> (from /usr/share/initramfs-tools/hooks/plymouth)
[16:56] <tseliot> right
[16:57] <ogra> so just running update-initramfs -u while the plugin defaults to ubuntu-logo works too
[16:58] <ogra> am i supposed to see any kind of animation btw ?
[16:58] <ogra> i only see a white logo
[17:01] <tseliot> ogra: no, that's all you can see now and it's just a provisional theme
[17:01] <ogra> cool, then it all works as it should
[17:02] <mathiaz> pitti: hi!
[17:02] <mathiaz> pitti: Is the desktop team looking after libgda?
[17:03] <pitti> mathiaz: not particularly, but in general it's desktop-ish realm
[17:03] <pitti> (it's in universe, though)
[17:04] <mathiaz> pitti: ah ok. I've got some request for an update of libgda
[17:04] <mathiaz> pitti: I'll advise to contact the debian maintainer then
[17:05] <pitti> hm, libgda3 was removed from unstable/testing
[17:05] <pitti> perhaps a package rename
[17:05] <mathiaz> pitti: probably libgda4
[17:05] <mathiaz> hm nope
[17:05] <mathiaz> pitti: libgda-4.0-4
[17:06] <pitti> ah, libgda4 is it then
[17:13] <primes2h> cr3: I tried latest checkbox. Strings that needed are now updated but strings with / within are still untranslated. Maybe pot/po needs to be regenerated?
[17:14] <primes2h> Tried both Karmic and Lucid
[17:51] <alkisg> On a newly installed system I have LANG=el_GR.utf8 instead of el_GR.UTF-8, and that breaks a lot of programs, for example LTSP. Should I modify LTSP to work around this problem, or is this some transitional phase?
[17:55] <cjwatson> alkisg: (a) that's unintentional (b) it's still a bug that LTSP breaks
[17:56] <alkisg> cjwatson: locale-gen $LANG returns false...
[17:56] <cjwatson> programs aren't supposed to look at the locale name components themselves; or if they do they need to be very very careful :)
[17:57] <cjwatson> I have no idea about locale-gen, but el_GR.utf8 is actually the canonical name of the locale that you get back from 'locale -a'
[17:57] <cjwatson> although el_GR.UTF-8 is the one listed in /usr/share/i18n/SUPPORTED
[17:57] <cjwatson> the installer is meant to generate el_GR.UTF-8, but programs should support either one
[17:57] <alkisg> On system (a) I have Lucid installed from alpha 1, and it has el_GR.UTF-8. On system (b) I installed alpha 2 and I got el_GR.utf8
[17:58] <alkisg> (LANG=el_GR.utf8)
[17:58] <cjwatson> please file one bug on localechooser for generating that spelling, and another on LTSP for not supporting it
[17:58] <alkisg> I think the second one should be filed against locale-gen, which returns false...
[17:59] <alkisg> Thank you.
[17:59] <cjwatson> we've never guaranteed that 'locale-gen $LANG' is something you can do, AFAIK
[17:59] <alkisg> Hmmm....
[17:59] <cjwatson> LTSP could simply check whether the current locale is working before it tries that
[17:59] <cjwatson> which should be the case for a freshly-installed system
[18:00] <alkisg> Got it.
[18:00] <cjwatson> I rather suspect locale-gen has only ever been guaranteed to support the spellings in /usr/share/i18n/SUPPORTED
[18:01] <alkisg> I'll patch LTSP to properly handle that case.
[18:05] <cjwatson> alkisg: thanks
[18:05] <alkisg> thank *you* :)
[18:05] <cjwatson> I'll look into the odd generation as time permits
[18:06] <cjwatson> would like to avoid triggering more bugs than we have to
[18:06] <alkisg> cjwatson: I have a feeling it's a gdm problem, as /etc/default/locale is correct...
[18:07] <cjwatson> ah, could well be then
[18:10] <alkisg> Heh, and I just noticed that if I login from a console instead of using gdm, I get a proper LANG :)
[18:20] <kees> can someone poke firefox in the NEW queue?
[18:37] <sianis> mvo
[18:37] <sianis> where are you? :)
[19:19] <mathiaz> slangasek: hi!
[19:19] <mathiaz> slangasek: if a daemon can be run in both the foreground and the background (ex: apache2) which option is recommended for writting an upstart job?
[19:35] <mathiaz> jdstrand: hi!
[19:35] <mathiaz> jdstrand: what's the directory where packages can drop uwf profiles?
[19:35] <mathiaz> jdstrand: *ufw*
[19:36] <jdstrand> mathiaz: /etc/ufw/applications.d
[19:36] <jdstrand> mathiaz: hi! :)
[19:36] <mathiaz> jdstrand: thanks!
[19:36] <jdstrand> sure
[19:37] <mathiaz> jdstrand: I'll mention ufw profile integration in my ufw talk about server pkg
[19:37] <mathiaz> jdstrand: I'll mention ufw profile integration in my *udw* talk about server pkg
[19:37] <jdstrand> heh
[19:37] <jdstrand> awesome! :)
[19:44] <mathiaz> jdstrand: hi!
[19:44] <mathiaz> jdstrand: is there a wiki page about developing an AppArmor profile
[19:44] <mathiaz> jdstrand: and how to integrate it in packages?
[19:45] <jdstrand> mathiaz: https://wiki.ubuntu.com/AppArmor has a bunch of stuff and links to various tutorials, etc
[19:46] <sebner> siretart`: heya, any idea when gstreamer-plugins-bad will be fixed?
[19:46] <jdstrand> mathiaz: https://wiki.ubuntu.com/ApparmorProfileMigration has the basic steps for packaging-- ie, start with apparmor-profiles and then migrate a profile to the package
[20:01] <mathiaz> kees: are you done for udw?
[20:04] <kees> mathiaz: yup!
[20:04] <kees> mathiaz: thanks :)
[21:09] <slangasek> ogra, tseliot: we *shouldn't* include plymouth in the initramfs by default, but the package in the archive still does; the bzr branch has changes that should remove the need for it in the initramfs by default (I hope)
[21:12] <slangasek> tseliot: the text plugin was already being included by the initramfs hook script when I got to it; it's right to have it there because plymouth uses it as a built-in fallback in certain cases (except not with ubuntu-logo, because the script plugin in the archive is broken - fixed in bzr).  I added the details plugin, which is also used by plymouth as a fallback in certain conditions.
[21:12] <slangasek> ogra: ^^ so any problems you're seeing are *not* due to a fallback.. :)
[21:12] <superm1> slangasek, i dont think tseliot is signed in, you'll probably want to reping later when he is
[21:13] <slangasek> superm1: heh, my tab completion is lying to me :/
[21:13] <slangasek> thought it was strange for him to be around at this hour... :)
[21:14] <slangasek> mathiaz: foreground or background> background, if it's not samba, where apparently this confuses the crap out of upstart :)
[21:38] <cody-somerville> I've noticed that the Ubuntu Core Development Team has been added to the kubuntu-dev team.
[21:39] <cody-somerville> Two questions)
[21:39] <cody-somerville> 1. Should I do the same for the xubuntu-dev team?
[21:39] <cody-somerville> 2. Is there someway that I don't have to get e-mails about build failures in the kubuntu-ppa team's ppas?
[21:39]  * sebner waves at mighty cody-somerville :)
[21:39] <cody-somerville> sebner, Hi :)
[21:41] <smoser> given a key id like '03683F77', is it posisble to dump the ascii armored key without first receiving (--recv) it ?
[21:45] <cjwatson> no, the key id isn't enough information
[21:45] <sladen> smoser: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x0620BBCF03683F77
[21:46] <smoser> thats exactly what i want, but expected i could get that more keyserver portably with 'gpg' somehow.
[21:49] <smoser> cjwatson, why isn't it enough. ?
[21:49] <smoser> basically i want the same as:
[21:49] <smoser>  k=03683F77; gpg --keyserver keyserver.ubuntu.com --recv $k ; gpg --export --armour $k; gpg --batch --yes --delete-keys $k
[21:52] <cjwatson> smoser: I thought you were asking whether you could do it without having to download anything
[21:53] <smoser> well that would be magic :)
[21:53] <sladen> smoser: there's nothing magic about it, all gnupg does is:
[21:53] <sladen> smoser: send(5, "GET /pks/lookup?op=get&options=mr&search=0x03683F77 HTTP/1.1\r\nHost: keyserver.ubuntu.com:11371\r\nAccept: */*\r\nPragma: no-cache\r\nCache-Control: no-cache\r\n\r\n",
[21:54]  * sebner is wondering if any archive admin is brave enough to kick firefox out of NEW (into the archive of course) :P
[21:55] <sladen> smoser: it's normal HTTP request, that you can do with your browser as demostrated in the example above
[21:56] <smoser> sladen, right. i just didn't think that the url you gave above would be an api rather than just a web browsing feature of a given keyserver
[21:58] <micahg> sebner: I thought it was already done
[21:59] <sebner> micahg: /me still sees it in NEW
[21:59] <micahg> sebner: https://edge.launchpad.net/ubuntu/+source/firefox
[21:59] <micahg> nm
[21:59]  * micahg is still learning...
[21:59] <sebner> micahg: https://edge.launchpad.net/ubuntu/lucid/+queue
[22:00] <micahg> it was approved to build but not publish
[22:00] <sebner> ack
[22:04] <slangasek> sebner: I'll be processing NEW shortly, fwiw
[22:05] <smoser> sladen, so i must be missing something.  how is it reasonably secure to import a key from an http (not https) server?
[22:06] <smoser> i'm obviously missing something.
[22:06] <cjwatson> smoser: because you can trivially check that the key ID matches for yourself
[22:06] <cjwatson> and that's the sole parameter you're supplying, so the transport layer makes no difference
[22:07] <smoser> so keyid is a hash (or otherwised derived input) from key
[22:07] <smoser> is that right?
[22:07] <sebner> slangasek: my hero :)
[22:08] <smoser> i dont expect anyone to give me a full crypto lesson here, feel free to say rtfm
[22:08] <cjwatson> smoser: for current key types, it's just the last eight hex digits, truncated
[22:08] <cjwatson> ... of the fingerprint
[22:09] <smoser> cjwatson, thanks.
[22:10] <cjwatson> you can import the ascii-armoured file into a temporary keyring and use --list-keys on it to check
[22:10] <cjwatson> or indeed if you just run 'gpg <file>' it'll show you
[22:50] <ari-tczew> can someone sponsor for main take a look on merges?
[22:58] <ari-tczew> bug 503136
[22:59] <ari-tczew> bug 499671
[23:26] <crimsun> would an archive admin please promote libglade2.0-cil-dev? (It being in universe on i386 is causing gbrainy to FTBFS.)
[23:28] <cjwatson> crimsun: done
[23:28] <crimsun> cjwatson: thanks!
[23:33] <cjwatson> sebner,micahg: accepted firefox binaries
[23:33] <sebner> cjwatson: great, thx :)