[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