[00:00] <TheMuso> 6666666666666666666666666666666@pilot in
[00:00] <TheMuso> gah
[00:00] <TheMuso> @pilot in
[01:39] <ScottK> pitti: I've now double verified the jockey fix works off of the rebuilt image.  Thanks again.
[02:43] <Logan_> james_w: Hey, are you around?
[04:02] <TheMuso> @pilot out
[04:24] <ScottK> TheMuso: Did the mumble patch get sent to Debian?
[04:25] <TheMuso> ScottK: Indeed it did, debian bug 706053:
[04:25] <ScottK> TheMuso: Thanks.
[04:25] <TheMuso> ScottK: np
[05:32] <pitti> Good morning
[05:32] <pitti> ScottK: splendid!
[07:24] <dholbach> good morning
[08:22] <xnox> ogra_: Laney dobey : yeah, ubiquity has a few wrappers and currently gksudo is the default. We were considering to add pkexec support, didn't realise ubiquity is the only one holding gksudo now.
[08:23] <ogra_> pkexec will work fine, but you need to export debus stuff etc
[08:23] <ogra_> *dbus
[08:23] <xnox> sorry that it didn't make it for raring.
[08:23] <pitti> and ubuntu-nexus7-installer apparently (but that's not shipped)
[08:23] <xnox> yeah, we have dbus in ubiqutiy already ;-) nothing works without it.
[08:23] <ogra_> thats in universe i hope
[08:23] <ogra_> shouldnt be in main at all
[08:23] <pitti> but aside from this, it's great that we got rid of it (mostly)
[08:24] <pitti> I hear it doesn't work on touch devices at all (aside from being two different UIs)
[08:24] <infinity> ogra_: It's not in the archive at all.
[08:24] <infinity> ogra_: So, even better.
[08:24] <pitti> right, I was just trying to purge it from my system :)
[08:24] <ogra_> phew
[08:51] <darkxst> infinity, any idea what is going on here?
[08:51] <darkxst> Rejected:
[08:51] <darkxst> Orphaned debug packages: udev-udeb-dbgsym 198-0ubuntu12~raring2 (amd64), udev-dbgsym 198-0ubuntu12~raring2 (amd64), systemd-dbgsym 198-0ubuntu12~raring2 (amd64)
[08:51] <darkxst> (trying to build systemd in a ppa)
[08:52] <infinity> Which PPA is this?
[08:52] <infinity> And did you somehow force building dbgsym packages in a PPA that wasn't configured to just do it automatically?
[09:00] <infinity> pitti: I'm confused by this calibre upload.  It claims to remove "non-free bundled" things.  But there's no new orig, so how can it?
[09:01] <pitti> infinity: ah, this only removes it from the binaries indeed
[09:01] <pitti> infinity: in Debian I uploaded a new upstream version with those bits gone from the orig
[09:01] <pitti> I can upload a new +repack tar if you want
[09:01] <infinity> pitti: That would be preferable.
[09:02] <infinity> pitti: Though, if the edubuntu folks aren't willing to respin for it, the point's slightly moot.
[09:02] <infinity> highvoltage / stgraber: I'm not sure I got a straight answer. :P
[09:02] <ogra_> why cant you just sync from debian ?
[09:02] <ogra_> stuck in NEW ?
[09:02] <infinity> ogra_: New upstream.
[09:03] <pitti> no, it's in exp
[09:03] <pitti> but that might stretch the definition of final freeze too much?
[09:03] <infinity> And I assume pitti's being cautious.
[09:03] <ogra_> ah
[09:03] <pitti> I mean, I'm fine with syncing, but I don't want to push it further than necessary
[09:03] <infinity> pitti: Well, it affects exactly one image, so you can talk highvoltage and stgraber into your experimental upload, or give me the repacked one, or just not worry about it and scream "la la la, I don't see a bug".
[09:04] <ogra_> yeah, sounded like you would just do the same in both distros ... i didnt get it was a new upstream in debian
[09:04] <pitti> ok, I'll prepare the +repack one until stgraber/highvoltage answer, and then we can pick any of the three :)
[09:04] <highvoltage> infinity: ah I thought you said that you already respun?
[09:04] <infinity> pitti: That works.
[09:04] <stgraber> infinity: so I guess we can live with a respin, but if we do respin, I'd like the casper fix in there, considering it seems to be hitting us around 50% of the time and it annoys me ;)
[09:04] <infinity> highvoltage: No, no.  I was debating accepting calibre, which would trigger a respin.
[09:05] <infinity> stgraber: Well, if I take casper, I'm respinning the world, not just you.
[09:05] <pitti> I wasn't even aware that calibre was on any image, sorry for the hassle
[09:05] <infinity> Everything is on the edubuntu DVD.
[09:05] <highvoltage> ah I see. well, it's a pretty serious bug, but it has low direct user impact. I'm fine either way really.
[09:05] <pitti> (FTR, there is the trick with copying a package to -updates and only respinning one flavour with that)
[09:05] <infinity> It's pretty much the whole archive, minus sl and lolcat.
[09:06] <pitti> *chuckle*
[09:06] <stgraber> infinity: hehe, it's your bad for getting lolcat in the archive so late ;)
[09:06] <infinity> ;)
[09:06] <pitti> stgraber, highvoltage: so, there is no functional bug, but the orig.tar and the deb ship non-free bits in universe
[09:06] <highvoltage> pitti: correct
[09:06] <stgraber> infinity: anyway, you're right about casper. I was vaguely hoping we'd find an horrible ubiquity bug so we would need to respin the world and get us that fix in the process, but apparently we haven't found one yet.
[09:07] <infinity> stgraber: We might still have a last-minute installer upload.  Have faith!
[09:07] <pitti> there we are, complaining about the *lack* of RC bugs!
[09:07] <pitti> what a nice problem to have
[09:07] <stgraber> infinity: considering how often we're finding RC bugs on Wednesday afternoons/evenings I still have faith ;)
[09:08] <infinity> stgraber: So, regarding calibre, since you're the only image it affects, repack of the current version, or sync of the new upstream from Debian?
[09:08] <cjwatson> It'd be kind of nice to be able to prepublish early today and have a relaxed day tomorrow :)
[09:08] <infinity> stgraber: Whatever you prefer, I'll go with.  But I do want to accept it, cause non-free bundling bugs irk me, and I don't want it baked into the release pocket.
[09:08] <stgraber> infinity: anyway, I'd rather we don't ship something non-free in universe, so yeah, I'm not against the respin, however I just want that one issue dealt with, nothing else.
[09:09] <stgraber> so that'd be pitti's repacked source and not a new version synced from Debian
[09:09] <infinity> Check.
[09:09] <infinity> pitti: Repack it is.
[09:09]  * pitti rejects his previous upload
[09:10] <pitti> ok, this looks good: diff -u <(tar tf calibre_0.9.18+dfsg.orig.prev.tar.xz|sort) <(tar tf calibre_0.9.18+dfsg.orig.tar.xz|sort)
[09:11] <highvoltage> infinity, stgraber: could you poke me when the new image is ready? I'll probably catch it when the notification hits #edubuntu, but still
[09:11] <infinity> Except the part where that needs a new upstream version.  Like +dfsg2 or something.
[09:11] <infinity> +dfsger
[09:11] <infinity> highvoltage: Can do.
[09:12] <pitti> infinity: yes, I called it calibre_0.9.18+dfsg1.orig.tar.xz now
[09:12] <infinity> pitti: Aww, I liked dfsger. :)
[09:12] <pitti> +reallyfree?
[09:12] <infinity> And when you notice it still has non-free crap in it, you can do +dfsgest.
[09:13] <pitti> and continue with +superdfsgest, +hyperdfsgest?
[09:13] <infinity> pitti: You missed duper, but yes.
[09:14] <Laney> dfsg-me-harder
[09:16] <darkxst> infinity, gnome3-staging, and it is configured to build debsym's
[09:16] <infinity> darkxst: URL to the PPA?
[09:20] <darkxst> infinity, https://launchpad.net/~gnome3-team/+archive/gnome3-staging/
[09:21] <infinity> darkxst: So, I'm going to politely disagree that that PPA is configured for ddebs.
[09:21] <infinity> darkxst: Given that no other build in there has produced any.
[09:22]  * pitti squeezes new calibre through his DSL
[09:22] <ogra_> the diff looks weird as well
[09:22] <ogra_> seems to not have any changes but the version bump
[09:22] <StevenK> pitti: Oooh, which version?
[09:22] <pitti> StevenK: see above, just a repack of the orig
[09:22] <pitti> StevenK: I uploaded 0.9.27 to debian experimental last night
[09:23] <pitti> StevenK: raring has 0.9.18
[09:23] <StevenK> Oh, bloody hell, there's *more* non-free bits in it?
[09:25] <infinity> darkxst: Though, it's also fairly clear that you didn't break this.
[09:26] <darkxst> infinity, it was meant to be configured
[09:27] <infinity> darkxst: It was recently changed to enable dgbsyms, I guess?
[09:27] <darkxst> 3-4 weeks ago I guess
[09:27] <infinity> More like a day or two ago...
[09:28] <infinity> Given that GDM built on 2013-04-22 didn't build with debug symbols.
[09:28] <darkxst> infinity, rt ticket #21277 if that helps
[09:48] <tjaalton> xnox: any luck with the plymouth & lightdm updates? they're in -proposed now too
[09:51] <xnox> tjaalton: right, hit eod without testing. It booted fine today.
[09:53] <xnox> will test more, after fixing this RC bug.
[09:53] <tjaalton> xnox: sure, thanks
[10:16] <infinity> darkxst: Oh, so the problem is that there's a systemd.ddeb but no systemd.deb.  This doesn't break the archive because of the sketchy way we do ddebs there, but soyuz has a sad about the mismatch.
[10:16] <infinity> pitti: ^
[10:17] <pitti> ah, thanks
[10:21] <darkxst> infinity, pitti is that easy to fix?
[10:22] <pitti> darkxst: if you add "export NO_PKG_MANGLE=1" to debian/rules, it won't build ddebs
[10:22] <pitti> that's the easiest workaround I can think of
[10:23] <darkxst> ok will do that then
[10:23] <infinity> pitti: If you want to fix that up in PPA versions for the gnome3 folks, and then queue that up for S, that would be nice, mind you.
[10:24] <infinity> pitti: Cause this'll hit when we finally finish ddebs in soyuz.
[10:24] <pitti> yeah, I need to think about how to do that properly in pkg-create-dbgsym
[10:25] <pitti> or we just apply the blacklist to dh_strip as well, which would be a much simpler fix in systemd itself
[10:25] <pitti> darkxst: in fact, if you just append this to debian/rules it ought to work:
[10:25] <pitti> override_dh_strip:
[10:25] <pitti>         dh_strip $(BINARY_BLACKLIST)
[10:25] <pitti> (leading tab, not spaces)
[10:26] <darkxst> hmm just uploaded the MANGLE one
[10:40] <jamespage> @pilot in
[10:43] <jamespage> jodh, you've been busy writing dep-8 tests :-)
[10:53] <rbasak> Does anyone know how apt-get might be trying to fetch changelogs on apt-get upgrade? Is there a configuration option like a hook or something or some kind of third party addon that I'm unaware of? Example: https://launchpadlibrarian.net/138138265/apt-output.txt
[10:53] <Laney> rbasak: apt-listchanges
[10:54] <rbasak> Laney: thanks!
[10:54] <Laney> np
[10:54] <infinity> That's not listchanges...
[10:55] <infinity> listchanges doesn't hit the internets, it unpacks the debs.
[10:55] <stgraber> I've had a couple of people poke me about it telling me that they can't upgrade or install new packages because they're shown the changelog instead and don't know how to proceed from there
[10:55] <infinity> That might be apt-listbugs?
[10:55] <infinity> Or whatever that was called.
[10:56] <rbasak> THis is bug 1169044, which is a complaint about upgrades being interactive. THe two reported problems are debconf prompts for questions apparently already answered, and this. It sounds like a local configuration issue but I wasn't clear on exactly how it might be happening.
[10:57] <infinity> rbasak: Right, so the "I had to close less" thing is apt-listchanges, and local configuation.
[10:58] <infinity> (dpkg-reconfigure apt-listchanges and he can make it not force a prompt by, say, mailing instead)
[10:59] <stgraber> infinity: apt-listchanges sure grabs stuff from the internet here
[10:59] <stgraber> Get:1 Changelog for pastebinit (http://changelogs.ubuntu.com/changelogs/pool/main/p/pastebinit/pastebinit_1.3-4ubuntu1/changelog) [10.1 kB]
[10:59] <stgraber> after I installed apt-listchanges on my machine and did an upgrade (well, after downgrading pastebinit as my system was up to date)
[10:59] <infinity> stgraber: Weird.  It also tears apart debs, so that's curiously weird.
[11:00] <stgraber> maybe we patched it to stop doing that since we're stripping part of the changelogs?
[11:01] <Laney> I think it asks apt to get them somehow, which may hit the world wide webnets
[11:01] <infinity> Maybe.  I don't run it on my laptop, only servers.
[11:01] <Laney> that not (yet) available ... thing comes from apt, at least
[11:04] <Laney> seems to be a fallback that we patched into apt-listchanges to use apt-get changelog
[11:06] <infinity> Laney: That feels a bit silly, but okay.
[11:08] <stgraber> infinity: I guess that was to make it work for LTS-to-LTS updates, not that anyone sane would really read the whole changlog of all the packages involved in that kind of upgrades ;)
[11:11] <jodh> jamespage: indeed - now to get them accepted ;)
[11:12] <jamespage> jodh, I'm defer until S opens if thats OK with you
[11:12] <jodh> jamespage: sure
[11:16] <jodh> rbasak: could this be bug 788519?
[11:17] <cjwatson> infinity: We had to make it not rely on tearing apart debs once we changed the packaging toolchain to strip changelogs in debs down to the top ten items or whatever it is.
[11:18] <rbasak> jodh: looks like it. Thanks!
[11:19] <jodh> rbasak: np.
[11:53] <jamespage> @pilot out
[14:49] <roadmr> xnox: hello! got a minute to talk about bug 1171815?
[14:51] <xnox> roadmr: not right now. busy with release critical bug atm.
[14:51] <xnox> roadmr: that bug is not urgent for raring, can discuss post-release.
[14:51] <roadmr> xnox: oh ok, we'll do it later then. Thanks and good luck with the bug!
[16:03] <Dr_ST> hi folks
[16:04] <Dr_ST> I'm trying to build a "static" binary in Ubuntu but fail with the error message ->/usr/bin/ld: cannot find -lgcc_s (Ubuntu 12.04.2 LTS)
[16:04] <Dr_ST> does that ping something to anyone?
[17:21] <Cas> Hi I am looking for more input on why this Naultilus change requires all application developers to set an env var when using xdg-open just to focus the new window: https://bugs.launchpad.net/ubuntu/+source/deluge/+bug/1168858
[17:22] <seb128> Cas, what nautilus change? if it was working before it was by luck, focus stealing prevention is meant to stop random stuff to pop themself on the front
[17:22] <Cas> if you use xdg-open you expect the window to be focused
[17:22] <seb128> right, so make xdg-open send the right timestamp
[17:23] <seb128> so the system knows when you user action happened and can decide if that's the result of an action or some program just trying to steal focus
[17:27] <Cas> I don't understand the difference
[17:29] <seb128> Cas, if you do "sleep 10; xdg-open http://www.google.com" on a command line and start typing in gedit, when your browser opens it shouldn't take the focus since that would make what you type go from gedit to your browser and break what you are doing
[17:31] <seb128> Cas, giving the timestamp allows the system to determine if you the command has been triggered by a real user action (like a click) and when
[17:31] <seb128> Cas, things should get the focus only if you did the action and nothing since
[17:31] <seb128> Cas, like if chrome takes 45 seconds to start and you started typing an email during that time it should under your composer
[17:33] <Cas> ok
[17:34] <Cas> but that doesn't change the fact that every application using xdg-open will now open nautilus in the background
[17:34] <Cas> in 13.04
[17:36] <seb128> Cas, not sure there are so many applications using xdg-open, that's wrong to do from an app
[17:36] <seb128> toolkits like gtk have proper apis to do that
[17:39] <Cas> sure but I have read bugs that the default apps are not always the same and xdg-open is preferred
[18:12] <dobey> Cas: xdg-open, the gtk+/glib API to open a url/file, and whatever qt/kde APIs there are to open a url/file, all basically do the same thing to determine which app to open the file/url in.
[18:29] <Cas> seb128, what is the problem with adding the env timestamp in xdg-open
[18:29] <Cas> using system time
[18:50] <seb128> Cas, not sure if the timestamps from x11 and the one you are using are the same format, and that's wrong because in the "sleep 10; xdg-open ..." case you would steal the focus of somebody typing, where you should not
[18:50] <seb128> since the time used wouldn't be the one from when the action was done, but enforcing the current time
[18:51] <Cas> but even if I made a call to xdg-open it would still be timestamped at the call time not the sleep time
[18:52] <Cas> what I am suggesting is that if the env DESKTOP_STARTUP_ID is not set then use current time in xdg-open
[18:52] <seb128> right, those wrapper script cases are a bit buggy
[18:53] <Cas> the problem is that xdg-open is the only way on linux to open the default application without using an api
[18:53] <Cas> but now users will find nautilus opens behind the terminal when attempting to use it
[18:54] <seb128> well, non geeky users don't run xdg-open on the command line
[18:54] <seb128> so it's a limited issue
[18:54] <Cas> err what
[18:54] <seb128> we tread users who had their input "stolen" by random apps for users who have to click on something to focus it
[18:54] <seb128> tread->trade
[19:03] <dobey> seb128: eh, those cases are buggy regardless. the program is never going to do exactly what the user wants. and if you write a script that does "sleep 10; xdg-open something" you deserve to have your focus stolen
[19:03] <dobey> the whole timestamp window/startup thing is nothing but a huge race condition