[00:27] <roaksoax> cjwatson: still around? can you check where my iupload for crmsh go?
[00:28] <roaksoax> (it is a new package)
[00:32] <roaksoax> uhmmm weird, I might have messed up and uploaded it somehwere else
[03:32] <TheMuso> @pilot out
[04:14] <pitti> Good morning
[04:14] <pitti> robert_ancell: I am now
[04:14] <robert_ancell> pitti, I emailed you a question about apport. No rush though
[04:14] <pitti> robert_ancell: ah, good
[04:53] <pitti> robert_ancell: I responded in bug 1204284, is that what you want to know?
[04:53] <pitti> robert_ancell: ah, I'll respond to your mail as well, there was a different q
[04:55] <robert_ancell> pitti, thanks, that looks like it
[04:58] <pitti> robert_ancell: responsed to mail as well, that might be an interesting alternative
[04:59] <pitti> wgrant: ooh, a saucy langpack! thanks
[06:38] <wgrant_> pitti: Oh, earlier than I expected.
[06:51] <cjwatson> roaksoax: It was unlucky enough to coincide with a brief period yesterday when there was a problem on the Launchpad database server, and so failed.  I've asked for the upload to be reprocessed
[07:20] <pitti> infinity: I built the first saucy langpacks, just testing
[07:20] <pitti> infinity: would this be a bad time to throw 800 packages at the buildds for some reason?
[07:21] <pitti> infinity: maybe you can update the chroots before?
[07:21] <pitti> infinity: (all build queues empty)
[07:24] <diwic> TheMuso, around?
[07:45] <dholbach> good morning
[07:48] <pitti> infinity, lamont: FYI, temporarily recruiting allspice and roseapple for i386 duty
[08:46] <infinity> pitti: Might not have been the best time since there's an Alpha in progress, but meh.
[08:47] <pitti> infinity: yeah, I was originally hoping to get them into the images, but there were some delays in the LP export side; I guess they'll just wait in -proposed until after the freeze
[08:47] <infinity> pitti: Assuming they're in the block of doom.
[08:48] <infinity> Ahh, which they are.
[08:52] <cjwatson> The new sources probably aren't, but hey.
[08:57] <seb128> sarnold, hey, do you have any estimate on when you are going to review bug #1186553? it has been waiting for security review for 8 weeks, would be nice to get that unblocked so we can update webkit...
[09:18] <henrix> @pilot in
[10:05] <Laney> ev: do you know when we'll get the new activity-log-manager?
[10:08] <seb128> Laney, ev: oh, yes, please don't make the system settings conflict with ubuntu-desktop (don't add that new depends until the conflicts is resolved by updating alm in saucy)
[10:08] <Laney> right
[10:09] <ev> Laney: I'll sort that out now unless there are objections
[10:09] <Laney> ev: Change the depends or update a-l-m? Either is fine by me if it works :-)
[10:10] <ev> update a-l-m. Change what depends?
[10:10] <Laney> u-s-s -> activity-log-manager | whoopsie-preferences
[10:11] <Laney> Also, good job on finding QDBusWatcher - works well!
[10:11] <ev> oh right
[10:11] <Laney> ServiceWatcher
[10:12] <ev> and cheers
[10:13] <Laney> I didn't manage to dig that one up
[10:52] <doko> tkamppeter, ping
[10:53] <doko> tkamppeter, why does ghostscript build with the embedded openjpeg?
[10:54] <doko> tkamppeter, and please check if it links to the external lcms2 now
[11:20] <tkamppeter> doko, GS uses internal openjpeg due to fixes which were not upstream that time and internal liblcms2 due to an API addition (for threaded use) which was not upstream that time (see debian/changelog, versions 9.06~dfsg~20120803-0ubuntu1, 9.06~dfsg-0ubuntu1, 9.07~dfsg-0ubuntu1, 9.07~dfsg2-0ubuntu1). I will re-check with the next upstream release (9.08) which will get released before FF end of August.).
[11:37] <diwic> cking, ping
[11:37] <cking> diwic, pong
[11:38] <diwic> cking, I'm getting questions from Intel about our power management policy
[11:38] <diwic> cking, in particular, why power management is disabled when AC power is connected
[11:38] <cking> diwic, can you forward me those questions from intel?
[11:38] <diwic> cking, i e, /sys/devices/.../power/control is always on
[11:39] <cking> diwic, which release?
[11:39] <diwic> cking, I think he's on 12.04
[11:39] <cking> diwic, can you send me the emails and I will get onto it sometime this week
[11:40] <diwic> cking, forwarded, but it's more of a generic "Does anyone know the Ubuntu power-policy on laptop?" question
[12:23] <smoser> ok... odd question for this channel.
[12:23] <smoser> is it possible to get genisoimage for osx ? if not that then how about mtools
[12:32] <slangasek> smoser: there's certainly nothing fundamental in genisoimage that prevents it building on osx.  I don't know if anyone provides builds though, if that's what you're asking.
[12:35] <smoser> slangasek, thtas what i'm asking. having never used it. i have no idea even what to google for.
[12:36] <smoser> "osx genisoimage" didn't help much
[12:36] <ogra_> smoser, first hit for me http://www.brucedavidson.me/install-cdrtools-on-mountain-lion/
[12:37] <ogra_> (though i used "mountain lion" replacing "osx"
[12:37] <ogra_> )
[12:38] <slangasek> smoser: "fink genisoimage"?
[12:38] <slangasek> or what ogra_ said
[12:39] <smoser> see, i'm so uphip to apple that I don't know if slangsek's "fink" comment was a joke or not.
[12:39] <smoser> but, thanks ogra_ .
[12:44] <slangasek> smoser: fink has nothing to do with being hip to apple, it's an apt-get for OSX ;)
[12:45] <ogra_> wasnt that UNIX in general ?
[12:45]  * ogra_ think he remembers using it on old SGI machines
[12:45] <ogra_> *thinks
[12:48] <slangasek> ogra_: fink was a project for OSX
[12:48] <slangasek> a port of apt-get
[12:48] <slangasek> (well, 'apt')
[12:49] <ogra_> hmm, then the fink i thinnk about might have been another project
[13:13] <roaksoax> cjwatson: coolnthanks!
[13:37] <ev> mpt: meet the thing that's going to solve all our problems: http://www.acunu.com/acunu-analytics.html
[13:37] <ev> err http://www.acunu.com/uploads/1/1/5/5/11559475/070913_aa_datasheet_v5.pdf
[13:44] <pitti> Laney: OOI, did you force the propagation of https://launchpad.net/ubuntu/+source/gvfs/1.17.2-0ubuntu3?
[13:44] <Laney> pitti: not me
[13:44] <Laney> check bzr log of the hints branch
[13:44] <pitti> Laney: gvfs' tests fail because it cannot modprobe scsi_debug, apparently some weird kernel regression
[13:44] <Laney> was it a -4 thing?
[13:44] <pitti> Laney: ah, I was wondering how it propagated
[13:44] <Laney> I guess /someone/ did, but it wasn't me :-)
[13:44] <pitti> Laney: could be; I'll re-run the test now
[13:45] <pitti> Laney: "the hints branch"?
[13:45]  * pitti checsk https://code.launchpad.net/~ubuntu-release
[13:45] <pitti> ah, there
[13:45] <Laney> lp:~ubuntu-release/britney/hints-ubuntu/
[13:45] <Laney> Also, that reminds me. I got an email for that failure but I was the sponsor - shouldn't the uploader have gotten it (as well? he wasn't in To:)
[13:46] <pitti> Laney: ah, there we go, http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/269
[13:46] <tedg> cjwatson, With click 0.2.6 I'm getting an exception when trying to install packages.
[13:47] <pitti> Laney: in theory, yes; jibel, is that a bug of that particular uplaod (jbicha does have public mail addresses in LP), or we don't do that in general?
[13:48] <cjwatson> tedg: traceback?
[13:48] <tedg> cjwatson, Ah, I think I got it... it seems to be that the package needs a path?
[13:48] <cjwatson> tedg: I don't know, what are you running?
[13:49] <tedg> cjwatson, hmm, no.  It might be just me.  But in my ~/Desktop directory they won't install.  But copying to /tmp makes things happy.
[13:50] <tedg> cjwatson, Seems like root should have access to Desktop... but eh, not a click issue.
[13:50] <cjwatson> tedg: Could I please have an actual example and traceback and stuff? :)
[13:50] <tedg> cjwatson, heh, http://paste.ubuntu.com/5907638/
[13:51] <tedg> cjwatson, command: $ sudo click install --force-missing-framework com.ubuntu.ubuntu-clock_0.5_all.click
[13:52] <JackYu> barry, hi, we have updated the source code at bug #1203931, would you please check it again for us:)?
[13:52] <barry> JackYu: i've put it on my list (a.k.a. browser tab :)
[13:53] <JackYu> barry, wow, great, tks.
[13:55] <cjwatson> tedg: Missing --user=tedg (or similar)
[13:55] <cjwatson> tedg: Or use pkcon
[13:56] <cjwatson> Though indeed that's unrelated to this tb
[13:56] <cjwatson> Dunno why root wouldn't have access to ~/Desktop/
[13:58] <tedg> cjwatson, Is it because of dpkg --force-not-root ?  Does that put it as a different user that might not have access?
[13:58] <tedg> Or is that "not root directory"
[13:58] <pitti> wgrant, StevenK: I'd appreciate a quick assessment how much work bug 1201485 would be for a proper LP fix
[13:58] <JackYu> barry, I'm not clear about the ' It's confusing to also include the source since the tarball will be downloaded.'. Do you mean we not include the debian/ in the source tarball?
[14:00] <cjwatson> tedg: No, it's not --force-not-root, although now that I think about it, the install runs as user clickpkg, not root
[14:01] <cjwatson> tedg: So maybe we need to arrange to copy the .click file first, or to pipe it in, or something
[14:01] <cjwatson> tedg: Could you file a bug on click?
[14:01] <barry> JackYu: my own personal suggestion is to have two separate branches, one for what will turn into the "upstream tarball", essentially the thing that will create the tar.gz you upload to LP, and a second branch which only includes the debian/ directory for packaging.  the former wouldn't include a debian/ and the latter would *only* have the debian/ dir
[14:01] <barry> JackYu: kind of like these:
[14:01] <barry> https://code.launchpad.net/~ubuntu-system-image/ubuntu-system-image/client
[14:01] <barry> https://code.launchpad.net/~ubuntu-system-image/ubuntu-system-image/client.pkg
[14:01] <tedg> cjwatson, Sure, will do.
[14:02] <wgrant> pitti: We'd need to copy an additional type of custom uploads. I think that should be relatively easy, but I'll have to investigate a bit.
[14:02] <cjwatson> Yeah, following the refactoring I did for UEFI copies I think it should be easy enough
[14:03] <JackYu> barry, wow, I see... You mean in different branches.
[14:04] <barry> JackYu: right.  it's not a requirement, so do what works best for you guys.  it's just that i've tried a bunch of different arrangements, and this separation works best for me.  i think it will also be more conducive to creating a ppa recipe and such.
[14:04] <JackYu> barry, it's a good suggestion:).
[14:04] <barry> JackYu: :)
[14:05] <barry> JackYu: it also makes it so much easier to review and sponsor
[14:05] <barry> (for me anyway)
[14:06] <JackYu> barry, yep, it make work easier. I will discuss this with our team.
[14:06] <barry> JackYu: sounds great.  just ping me when you decide and/or have the new branches ready
[14:36] <ahasenack> hi, is there a way for a build to know if it's happening inside a ppa builder?
[14:36] <mpt> ev, "roll-up cubes on data" sounds delicious.
[14:36] <ahasenack> I would like to disable a test conditionally, because it requires a launchpad login and network access
[14:36] <ahasenack> I was wondering if there was some env var (ok, it's a launchpad question, not strictly ubuntu-devel)
[14:37] <JackYu> barry, we will create debian/ branch for these two projects  tomorrow (since it's almost middle night here:) ).
[14:38] <JackYu> barry, I have updated the tarballs, please check if they are good when you are availably, thanks in advance:).
[14:40] <ev> mpt: lol
[14:41] <henrix> @pilot out
[14:41] <barry> @pilot out
[14:42] <barry> JackYu: sounds good!
[14:42] <barry> JackYu: have a good night
[14:51] <lfaraone> so while trying to fix LP #1204195 on raring, I noticed that for some reason all of the changes in various patches are being collapsed into a single debian-changes by the builder, despite not happening when I run debuild -S locally. see https://luke.faraone.cc/pub/openafs_1.6.1-2ubuntu2.1_amd64-20130723-2115.build
[14:51] <lfaraone> why might this be happening / what should I do to fix this?
[15:01] <lfaraone> this strangely did not happen on precise, https://luke.faraone.cc/pub/openafs_1.6.1-1+ubuntu0.2_amd64-20130723-2113.build
[15:03] <cjwatson> That's part of your source package, not done by the builder
[15:04] <cjwatson> I mean, not done by Launchpad builders
[15:04] <cjwatson> In that log you're building the source package too
[15:08] <lfaraone> cjwatson: sure. but why don't I get that behaviour when I run debuild locally?
[15:09] <cjwatson> lfaraone: Dunno, it seems to be reasonably sensibly picking up --single-debian-patch from debian/source/options within the build; perhaps you have an elderly dpkg-dev?
[15:10] <lfaraone> cjwatson: https://luke.faraone.cc/pub/openafs_1.6.1-2+ubuntu2.1_source.build.cobalt is my local build output
[15:10] <lfaraone> cjwatson: ah, I'm using precise locally.
[15:14] <lfaraone> Removing debian/source/options fixed the issue.
[15:18] <kenvandine> jamesh, if you're around, with one minor fix to your unity-lens-friends MP, i'll approve it
[15:19] <jamesh> kenvandine: hi.  I've been meaning to get back to that MP.  I can actually reinstate some of that code I deleted, since I added a "notify shell that results have changed" call to the new API
[15:20] <kenvandine> jamesh, awesome, even better :)
[15:21] <jamesh> kenvandine: what change did you want?
[15:21] <kenvandine> the path to the module in the scope file
[15:21] <kenvandine> the .so gets installed in libdir
[15:21] <kenvandine> not /usr/lib/unity/
[15:22] <jamesh> $(libdir) rather than $(libdir)/unity ?
[15:22] <kenvandine> multiarch libdir
[15:22] <jamesh> ah.
[15:22] <kenvandine>  /usr/lib/x86_64-linux-gnu/unity/unity-scope-friends.so
[15:23] <jamesh> I should be able to swing that.  I'll probably have to do the substitution by hand rather than via configure so it doesn't end up as '${prefix}/lib/unity/...' on a default build
[15:26] <kenvandine> yeah
[15:26] <jamesh> I'll see about making the change tomorrow.  It's late here now
[15:31] <kenvandine> jamesh, thanks, good night!
[15:34] <roaksoax> Daviey: if you have a minute, could you process (accept) crmsh (it's in the NEW queue :))
[15:45] <Daviey> roaksoax: I can't review it right this moment, sorry
[15:45] <Daviey> I can later.
[15:46] <roaksoax> Daviey: that works! thanks :)
[17:03] <doko> seb128, xnox: how do I build gtk+3.0 without having libatk-bridge2.0-dev?
[17:04] <doko> and libatk-bridge2.0-dev needs gconf for the build, and that wants gtk+-3.0 ...
[17:07] <doko> --without-atk-bridge ?
[17:08] <Laney> doko: configure.ac suggests you have to disable the x11 backend
[17:12] <seb128> doko, libatk-bridge2.0-dev shouldn't need gconf
[17:12] <seb128> doko, that build-depends seem buggy, let me try in a pbuilder
[17:38] <doko> Laney, seb128, yes, gconf2 doesn't seem to be necessary
[17:41] <seb128> doko, I already uploaded an update to drop it
[17:41] <doko> thanks
[18:41] <roaksoax> can someone please process crmsh from the saucy new queue?
[19:37] <NCommander> ogra_, ping, how do we handle rootfs in flash-kernel these days. It doesn't appear to be set anywhere on the kernel commandline anymore.
[19:38] <ogra_> hmm, it should, by d-i or ubiqiuty ... for pandas we had a /etc/default/flash-kernel that held the defaults (like we do for grub)
[19:38]  * ogra_ hasnt touched f-k in a long time
[19:39] <NCommander> ogra_, well you did the last upload :-), I haven't touched it since precise
[19:39] <NCommander> ogra_, looking on a highbank system, we're not seeing it on bootargs; I get this sinking feeling that this is a bug
[19:40] <NCommander> ^- infinity - any insights?
[19:55] <infinity> NCommander: It's in boot.script on omap4, I forget what highbank does, as I didn't write that support.  But it works, afaik, so it must be doing something right.
[19:56] <infinity> mahmoh, dannf: ^^
[19:56] <NCommander> infinity, on raring? flash-kernel doesn't specify it
[19:56]  * NCommander thinks he knows how its doing it
[19:59] <ogra_> NCommander, the last uploader was rsalveti and before that three dannf ones specifically for highbank ...
[20:00] <ogra_> NCommander, update your package :P
[20:00] <ogra_> (all three uploads from dan were in raring)
[20:00]  * rsalveti hides
[20:00] <ogra_> heh
[20:01] <ogra_> no worries
[20:01] <ogra_> hmm
[20:01] <ogra_> though ...
[20:01] <ogra_> now that i read the changelog ...
[20:01] <ogra_> flash-kernel (3.0~rc.4ubuntu32) raring; urgency=low
[20:01] <ogra_>   * flash-plugin-installer: make installable on armhf/generic for highbank
[20:01] <ogra_> thats funny :)
[20:03] <dannf> heh. stupid muscle memory
[20:11] <roaksoax> I have a quick question. Say a source package with -1ubuntu1 revision build 2 binaries that I want to drop in -1ubuntu2. Should I create virtual packages for those 2 packages that I;m dropping or what should be done in that case?
[20:14] <jbicha> it depends on what those packages are
[20:18] <roaksoax> jbicha: these packages don't have others depending on them, they enhance functionality
[20:25] <NCommander> ogra_, I think we're embedding it in the ramdisk these days vs. on the kernel command line directly.
[20:35] <tvoss> slangasek, ping
[20:36] <slangasek> tvoss: good evening!
[20:59] <vrubium> Hi all, Im running saucy and whent trying to update it asks me remove unity-common, should I file a bug?
[20:59] <slangasek> vrubium: no
[20:59] <slangasek> you should let it remove unity-common
[20:59] <vrubium> slangasek: it seems unusual to remove unity-common, won't it break unity?
[21:00] <slangasek> nope
[21:00] <slangasek> you should be worried when you see leaf-node packages being removed, like unity itself - not things like unity-common, which are internal implementation details :)
[21:01] <vrubium> slangasek:
[21:02] <vrubium> slangasek: sometimes it's trick to identify those packages, do you recommend any procedure?
[21:02] <slangasek> vrubium: well, if the name starts with "lib" or ends with "-common", they're internal implementation details
[21:02] <slangasek> vrubium: also, if you use update-manager and update-manager allows the removal without complaint, it's safe
[21:03] <slangasek> furthermore, unless you have saucy-proposed enabled in your sources (which would be an error), the risk of an upgrade removing packages it shouldn't is now very low
[21:04] <vrubium> slangasek: thanks for the tip, typically I update using apt-get because it's quicker and normally is straighforward to see if anything is going to break
[21:16] <mahmoh> NCommander: ogra_: infinity: highbank uses boot.scr too iirc, rootfs is in the initrd yes


[21:41] <phillw> Hi, anyone from -meeting about?
[21:43] <JoseeAntonioR> phillw: what's the matter?
[21:43] <TheLordOfTime> i think phillw wants to book meetings on the fridge calendar
[21:43] <JoseeAntonioR> that's done at #ubuntu-news.
[21:44] <TheLordOfTime> phillw:  ^
[21:44] <phillw> JoseeAntonioR:  I would lime to book the following.....
[21:44] <phillw> They will still be at 20:00 UTC / GMT
[21:44] <phillw> Tue 25th June (pre Alpha 1)Tue 23rd July (pre Alpha 2)Tue 27th August (Pre Beta 1)Tue 24th September (Pre Final Beta)Tue 15th October (Final push for the release of 13.10).
[21:44] <JoseeAntonioR> phillw: I said, #ubuntu-news :)
[21:45]  * phillw goes and moves :)
[21:45] <TheLordOfTime> lol


[00:00] <zmoylan-pi> only 2 usb ports?! what is this 1999? :-P
[00:01] <daftykins> 2 more on the side ;)
[00:01] <daftykins> but if you're using a lot of USB gear, you're doing it wrong!
[00:01] <zmoylan-pi> only 4 usb ports?! what is this 2004? :-P
[00:02] <daftykins> still use my webcam by being plugged into the side of the left one actually, seems alright
[00:02] <zmoylan-pi> it's an anti theft strategy when the pc is scattered in 20 external devices each with their own cable and power supply :-D
[00:04] <daftykins> i only got my first displayport graphics card back 1 year ago, yet my monitors still had it! albeit v1.1 - that was quite handy
[00:04] <daftykins> although they're trying to get too clever, if i turn one screen off it'll move my programs to the one that remains - but i used to like just leaving them where they were :P
[00:05] <zmoylan-pi> i _hate_ when hardware tries to be /clever/ 9 times out of 10 it does the wrong thing...
[00:06] <daftykins> *nod* that and HDMI-CEC are definitely those type
[00:06] <daftykins> better just *off* :>
[06:01] <knightwise> mornin g
[06:01] <knightwise>  how izz you all doing today
[06:52] <MooDoo> morning all
[07:39] <SuperMatt> woo, moved office!
[07:44] <MooDoo> SuperMatt: did it all go smoothly?
[07:45] <SuperMatt> yeah, I have all my stuff, nothing went missing, thankfully
[07:48] <MooDoo> nice
[08:06] <davmor2> Morning all
[08:30] <MooDoo> morning davmor2
[08:31] <davmor2> ay up me owld mukka ow am ya?
[08:36] <MooDoo> davmor2: hayfever, cold, urgh......how are you?
[08:38] <foobarry> hayfever kicked off today
[08:38] <davmor2> Tree pollen gets us before the rest and rapeseed pollen it lethal and there is none of that about right.....in the rural Shropshire Countryside :D  Aldi's hayfever tablets are awesome by the way
[08:39] <MooDoo> I've already got some, it's just the cold that's making me feel crappy.
[08:48] <brobostigon> morning boys and girls.
[08:49] <MooDoo> morning brobostigon
[08:53] <JamesTait> Good morning all! Happy Monday, and happy Firefly Day! 😃
[08:54] <brobostigon> mornin MooDoo
[08:58] <davmor2> JamesTait: https://www.youtube.com/watch?v=JPwkDF5AxQM can only be
[09:01] <JamesTait> Yup.
[09:14] <davmor2> JamesTait: first thing I downloaded on Google play video :D
[09:19] <diplo> Morning all
[09:21] <davmor2> Morning diplo
[12:35] <davmor2> JamesTait: Just found the episode of Castle where Richard dresses as Mal :D Class act that one :)
[12:36] <zmoylan-pi> space cowboy \o/
[12:36] <SuperMatt> Quite near the beginning, if I recal
[12:36] <SuperMatt> Halloween episode
[12:38] <davmor2> yeap
[12:38] <zmoylan-pi> castle had quite a few firefly references iirc
[12:46] <knightwise> Hey everone
[12:46] <knightwise> how are you guys doing today
[12:49] <davmor2> zmoylan-pi: there are a bunch of references like the spa is serenity, there is talk of yeah, you'd better run and so on
[12:50] <knightwise> hmm.. Bash shell under windows does have some drawbacks. the screen refresh in irssi sucks hairy camel testicles
[15:19] <Ybslik> Hi I am very new at all this. I have loaded Ubuntu 16.4 onto a new Pc. I want to use this New Pc as a Tor Node, and I need help in setting it up
[15:25] <brobostigon> Ybslik: https://www.torproject.org/docs/tor-relay-debian thats a good place to start, :)
[15:31] <Ybslik> Hi Yes I have read the article but I find that they are talkin as if I know what they mean, maybe to paoint, but when it says add lines to the 'torrc' file  - where is the 'torrc' file and how do i open it.  I am not a dummy but this has stumped me, I was only able to get  this IRC loaded because it led me through the process with what to type in. I hope you know wher I am at.
[15:32] <brobostigon> i would suggest torrc is probably either in your home directory or /etc ? i would also suggest using a text editor to edit said config file. :)
[15:37] <Ybslik> Yes thankyou, now please be patient, I am used to being in windows and just click on items to open them,  I have found an icon with a filing cabinet on it opening that shows me i'm in Home no folder is listed as torrc - and where do I find /etc?
[16:56] <Lupus> Hello!
[16:59] <davmor2> Lupus: hello
[16:59] <Lupus> Hi!
[16:59] <Lupus> Can you help me with something?
[16:59] <davmor2> just ask if someone can help they will
[16:59] <Lupus> I want to install libssh-0.1 on my Ubuntu Server 17.04 (64bit), but I encounter an error at make.
[17:00] <Lupus> I'm running it in VirtualBox.
[17:00] <foobarry> why are you compiling it Lupus ?
[17:00] <Lupus> I have to compile an executable file written in C that requires libssh-0.1. I tried libssh-0.11 but I have an error at compilation.
[17:00] <Lupus> I need libssh-0.1.
[17:00] <foobarry> is it really old?
[17:01] <Lupus> Yes.
[17:01] <Lupus> https://pastebin.com/GLwfm70T
[17:01] <Lupus> This is my error.
[17:01] <Lupus> At the end of the make...
[17:01] <foobarry> do you know what version of ubuntu it did work with?
[17:02] <Lupus> I'm not sure.
[17:02] <Lupus> I'll try to install Ubuntu Server 12.04, but it will be removed today!
[17:02] <Lupus> Tomorrow*
[17:03] <foobarry> running such an old thing has major security issues
[17:03] <Lupus> It's okay.
[17:03] <Lupus> I'm running the Ubuntu Server in VirtualBox.
[17:04] <foobarry> try to find where it was available as a package
[17:05] <foobarry> maybe 2010
[17:05] <Lupus> I don't know...
[17:05] <Lupus> https://www.libssh.org/files/0.1/libssh-0.1.tgz
[17:06] <foobarry> recompile with -fPIC
[17:06] <foobarry> did you try that?
[17:06] <Lupus> I tried.
[17:07] <Lupus> But nothing..
[17:07] <foobarry> --enable-shared
[17:07] <foobarry> tried that?
[17:07] <Lupus> Yes.
[17:07] <foobarry> http://stackoverflow.com/questions/13812185/how-to-recompile-with-fpic
[17:07] <Lupus> ./configure --enable-shared.
[17:07] <Lupus> Yes.
[17:07] <Lupus> I tried and gcc -o libssh.so -shared client.o packet.o dh.o crypt.o connect.o error.o buffer.o string.o kex.o channels.o options.o keys.o auth.o base64.o keyfiles.o misc.o gzip.o wrapper.o sftp.o -lnsl -lresolv -lz -lcrypto
[17:07] <Lupus> I can give you the login for my Ubuntu Server.
[17:08] <Lupus> If you can solve it.
[17:08] <foobarry> i've got to put the kids to bed :|
[17:08] <Lupus> It's ok.
[17:08] <foobarry> what is the app you are trying to cmpile? something properietary?
[17:08] <foobarry> someone else might offer later this evening
[17:10] <Lupus> A friend gave me a source code because he can't compile it.
[17:10] <Lupus> It is for ssh authentication or something like that.
[17:10] <foobarry> :o
[17:10] <Lupus> What?
[17:10] <foobarry> that will be horiifically insecure
[17:10] <foobarry> if it relies on such ancient libs
[17:10] <Lupus> It's okay.
[17:10] <Lupus> I want to help him.
[17:10] <Lupus> It's okay bro.
[17:11] <Lupus> But I need libssh-0.1.
[17:16] <Lupus> Are you here?


[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?    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 :)