[06:18] <pitti> Good morning
[07:27] <lpotter> hmmmm
[08:35] <dholbach> good morning
[08:41] <seb128> hey dholbach
[08:43] <dholbach> hi seb128
[08:45] <seb128> dholbach, congrats for the Cc election ;-)
[08:45] <dholbach> thanks :)
[09:09] <zequence> I've uploaded a package (ubuntustudio-meta), but it doesn't seem to be building. Where can I see errors for things like that?
[09:11] <sladen> zequence: https://launchpad.net/ubuntu/+source/ubuntustudio-meta  there was an upload 48 hours ago; is there a newer one aswell?
[09:13] <zequence> sladen: The source is there, but no binaries
[09:15] <sladen> zequence: (if) it is the 0.143, buildlog will be here  https://launchpad.net/ubuntu/+source/ubuntustudio-meta/0.143/+build/8352681
[09:16] <sladen> zequence: but it claims to have built; in which case perhaps you need an archive admin to look into it
[09:17] <zequence> sladen: Right. Thanks!
[09:18] <Mirv> porters: bos01-ppc64el-027 hanged on build (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+build/8357535), will cancel and retry
[09:20] <Mirv> hmm, I didn't notice it in the snippet but looks like it was ppc64el ICE actually that then didn't really fail (the build status remained building)? https://launchpadlibrarian.net/227978020/buildlog_ubuntu-xenial-ppc64el.qtscript-opensource-src_5.5.1%2Bdfsg-2build1_CANCELLING.txt.gz < doko
[09:21] <doko> The bug is not reproducible, so it is likely a hardware or OS problem.
[09:21] <doko> just retry
[09:23] <Mirv> right, so it says
[12:46] <cjwatson> zequence: it's in NEW, awaiting review
[12:46] <cjwatson> or was
[12:47] <cjwatson> zequence: appears to have been accepted not long before you asked about it
[13:29] <ginggs> didrocks (or anyone else willing to sponsor): suitesparse ready for transition, please remove fop from -proposed, LP: #1518985
[13:31] <didrocks> ginggs: good, removing fop then, one sec
[13:33] <didrocks> ginggs: done, just wait for a publisher cycle to show up
[13:38] <ginggs> didrocks: thanks, are you sponsoring my suitesparse merge as well?
[13:40] <didrocks> ginggs: yeah, I'll have a look shortly
[13:40] <ginggs> didrocks: cool, thanks again!
[13:41] <didrocks> ginggs: thanks to *you*! :)
[14:03] <pitti> cjwatson: is there a LP redirect that would get me the latest .dsc for a given package?
[14:05] <lamont> pitti: you'd have to define "latest" (highest version? most recently uplaoded? published? etc) -- I too would be interested in the answer, but I suspect it's "no, you have to use the api"
[14:05] <pitti> lamont: highest version, yes
[14:06] <pitti> well, it's not too hard for me to figure out the version, but if there was some kind of /+latest.dsc redirect I wouldn't have to
[14:17] <xnox> why is $ pull-debian-source -> not working at all?! =(
[14:17] <xnox> pitti, don't think so, the thing that is shown as "latest" is any latest upload in the ui, rather than highest.
[14:18]  * xnox looks at stuff.
[14:20] <xnox> pitti, i think there was a magic url, into which one could plugin e.g. hello_1.2-3.dsc and it would download it, obviously one would have to know the full filename on wants to fetch.
[14:21] <pitti> xnox: ok, thanks; nevermind, it's fine
[14:21] <pitti> chdist --data-dir data/chdist grep-dctrl-sources xenial-amd64 -n -s Package,Version -F Testsuite autopkgtest|paste -sd '  \n' | sed 's/ [0-9]\+:/ /'
[14:21] <pitti> that pretty much gives me what I want -- a list of all sources and their versions which have a test
[14:23] <pitti> and with the version I can use https://launchpad.net/ubuntu/+archive/primary/+files/$src_$ver.dsc
[14:23] <xnox> aha https://github.com/xnox/apt-mirror/blob/master/apt-mirror-librarian 'https://launchpad.net/ubuntu/+archive/primary/+files/' + debfile but yeah, that's to actually download any .dsc from librarian. (possibly pre publish into the apt archive, but not sure)
[14:23] <xnox> yeap.
[14:23] <xnox> that's the url i was thinking about.
[14:24] <juliank> I can't reach launchpad.net (91.189.89.222)  - am I the only one?
[14:25] <JanC> works for me
[14:25] <juliank> Seems I have issues here
[14:27] <JanC> wait, I'm on .223
[14:28] <JanC> https://91.189.89.222/ gives me an error page from the reverse proxy
[14:29] <JanC> (for obvious reasons)
[15:10] <xnox> mardy, would the bug #1521226 be of interest to you?
[15:10] <xnox> =)
[15:10] <mardy> xnox: vaguely ;-)
[15:10]  * mardy tries to hide
[15:11] <xnox> mardy, it fails on -Wall -Werror stuff with something rather, new glib, gibberish =)
[15:11] <xnox> error: 'g_simple_async_result_propagate_error' is deprecated et.al.
[15:11] <xnox> maybe disabling -werror would be enough for now. or maybe you are up for porting things to the "new" apis.
[15:11] <mardy> xnox: ah, I can't tell you how much I love GLib deprecation policies :-)
[15:15] <seb128> mardy, what an idea to build with Werror
[15:15] <seb128> mardy, at least use -Wno-error=deprecated-declarations ;-)
[15:16] <mardy> seb128: actually, you are right, better get rid of Werror in the first place
[15:16] <mardy> seb128: and I'll add G_GNUC_BEGIN_IGNORE_DEPRECATIONS in the right places
[15:23] <Mirv> xnox: if you don't mind, ignore your fcitx-qt5 sync's problems and let me upload a no-changes rebuild as part of the Qt 5.5 landing this week
[15:26] <xnox> Mirv, i've synced it for very much different reasons. The sync is successful, the failures on power with respect to libxkbcommon are odd, given that libxkbcommon did not change since wily.
[15:27] <xnox> Mirv, that new version has corrected symbols for extra architectures.
[15:27] <Mirv> xnox: yes, I know the problem and that's why it wouldn't need now any changes after I land a synced Qt 5.5 in. it will need a rebuild however since it uses private symbols. the rebuild is already building at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages
[15:28] <Mirv> xnox: it's nice it has the symbol updates since I had the older version manually patched before your upload in that PPA
[15:28] <xnox> Mirv, ah cool, thanks for explaining.
[16:13] <juliank> mvo: 1.1.3 is visible on Launchpad now
[16:16] <mvo> juliank: lots go then
[16:16] <juliank> The APT 1.1 Ubuntu party starts :)
[16:17] <juliank> Thanks to pitti for already merging the goplay nmu
[16:18] <pitti> juliank: it wasn't actually a real merge; I synced, then found that weird gcc error, then uploaded a workaround
[16:19] <juliank> pitti: Right, thanks anyway :)
[16:19] <juliank> ppc64el is a strange beast
[16:20] <juliank> We have an even more crazy gcc workaround in apt: http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=0300f0077af832e87beb290f26b13404cab81fd3
[16:33] <pitti> hah
[16:42] <mvo> juliank: apt and libept are synced now, weeeeeeee
[16:43] <juliank> mvo: Great. python-apt can be synced  as well
[16:43] <mvo> juliank: done, woah
[16:43] <mvo> juliank: I'm so excited!
[16:44] <Laney> apt is synced?
[16:44] <Laney> nice!
[16:44] <ricotz> better don't break the world ;P
[16:45] <davmor2> just the rest of the universe ;)
[16:45] <ogra_> who needs apt ... its a snappy future !
[16:46]  * davmor2 snaps his fingers....computer is just sat there doing nothing. /me thinks ogra_ lies
[17:06] <jamespage> cjwatson, should have your ubuntu-repository-cache MP landed shortly - the tests where failing due to changes in Juju and the testing framework for the charms
[17:24] <shadeslayer> doko: ping
[17:24] <shadeslayer> doko: Is packagekit being finally updated in Xenial?
[17:40] <juliank> shadeslayer: PackageKit definitely needs to be merged soon for the APT transition at least.
[17:41] <juliank> The first PackageKit to support APT 1.1 is 1.0.11
[17:42] <dobey> pitti: ping. you around? need a manual ack on some autopkgtest issues
[17:52] <zequence> cjwatson: Didn't realize the packages go through review at this stage in development. They usually get published so quickly.
[17:54] <seb128> juliank, packagekit 1.0 was merged and got deleted since we need somebody to port aptdaemon for the api changes first, and somebody to update click to not use the packagekit plugin api since that was removed
[17:54] <seb128> mvo started on the click work but he seems to busy to land it and nobody else knows click enough/has slots for it
[18:17] <shadeslayer> juliank: I see
[18:18] <shadeslayer> juliank: I need it for muon in the next Kubuntu release too
[18:43] <smoser> hey. barry can you verify or suggest work around?  it seems that: http_proxy=http://.... pip install something
[18:43] <smoser> on trusty will just not work
[18:43] <smoser> http://paste.ubuntu.com/13581190/
[18:44] <smoser> i think its related to https://github.com/shazow/urllib3/issues/422
[18:44] <barry> smoser: does it work in xenial?
[18:44] <smoser> yes. and vivid
[18:45] <smoser> i'm just kind of surprised such a thing has lasted so long.
[18:45] <barry> smoser: i can't remember what the state of backports/srus are for the pip stack :/
[18:46] <barry> smoser: this seems familiar, but i don't remember the details
[18:46] <smoser> tox uses pip from the system ?
[18:46] <barry> smoser: i think it may depend on whether sitepackages=true in your tox.ini
[18:47] <barry> well, maybe not
[18:47] <barry> tox probably uses the system virtualenv, which uses the system pip
[18:48]  * barry can't understand why https://www.google.com gives an ssl connection error, but only on one fully up-to-date xenial machine
[18:48] <barry> all other https sites seem to work too
[18:50] <sladen> SHA256?
[18:55] <smoser> barry, ok. so it getting python-virtualenv from vivid (python-virtualenv_1.11.6+ds-1_all.deb) fixes it for me.
[18:55] <smoser> i guess virtualenv has an embedded pip that it uses
[18:56] <smoser> hm.. or  maybe not as i dont see it.
[19:06] <juliank> mvo: What's the plan with PackageKit and APT 1.1? That needs 1.0.11 or a backport.  seb12 8 wrote "we need somebody to port aptdaemon for the api changes first, and somebody to update click to not use the packagekit plugin api since that was removed"
[19:09] <infinity> mvo: I may be late to the party here, but what was wrong with parsing /etc/lsb-release?
[19:10] <juliank> infinity: You're really late ;)
[19:11] <infinity> juliank: Figured. :P
[19:12] <infinity> juliank: I'm assuming (well, hoping) there was also discussion about formalizing CODENAME in the os-release spec, so we're not using a distro-specific extention forever?
[19:12] <juliank> Will the auto-dep-wait stuff automatically be "un"waited? apt 1.1.3 has been built and is pending publications, and python-apt and libept are in dep-wait waiting for it
[19:12] <infinity> juliank: Yeah, it'll unwait once the deps are available.  apt's still in NEW, unless someone accepted it when I wasn't looking.
[19:13] <juliank> I at least don't find any mention of NEW on launchpad
[19:14] <infinity> https://launchpad.net/ubuntu/+source/apt/1.1.3
[19:14] <infinity> I do. :P
[19:14] <juliank> Oh yeah, on the right side
[19:15] <juliank> Annoyingly, once libept is built, it will also be NEW again
[19:15] <juliank> s/ again//
[19:16] <infinity> Not a big deal.
[19:16] <infinity> I'll give libaptwhatever a quick once-over and get the ball rolling.
[19:16] <infinity> Thanks for proper build-deps, BTW.
[19:16] <infinity> Since I'm doing an out-of-archive bootstrap right now, it's much appreciated.
[19:16] <juliank> Which proper build deps ?
[19:17] <infinity> As in, you're dep-waiting on the new apt, rather than counting on upload timing to get it right.
[19:17] <infinity> So I can't build in the wrong order by accident.
[19:17] <juliank> Yeah
[19:18] <juliank> infinity: I bootstrapped that in Debian experimental, so the deps were needed otherwise the packages would have built with unstable APT :)
[19:20] <smoser> anyone else see this, or is it just lucky me
[19:20] <smoser>  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1521302
[20:12] <stgraber> bdmurray: hmm, how comes that as a coredev working for Canonical I don't have access to crash reports on errors.ubuntu.com?
[20:13] <stgraber> bdmurray: I'm being told I'm not in the right group when I go to https://errors.ubuntu.com/problem/9d8b1bc865eba0604b89ca1f7a24f0a1a0186290 and after I do SSO auth
[20:13] <dobey> stgraber: are you in ~ubuntu-bug-control?
[20:16] <stgraber> pretty sure I am, yes
[20:17] <dobey> yeah, that's not it
[20:18] <dobey> i can see that link, so it's some group i'm in, at least :)
[20:23] <dobey> and looking at my teams list, i have no idea which one it'd be
[20:36] <yofel> dobey, stgraber: AFAIK you need to be in https://launchpad.net/~error-tracker-access
[20:36] <dobey> yofel: that doesn't exist
[20:37] <yofel> dobey: huh? The team does exist, I vaguely remember there being an email that you should apply for that to get access when the tracker was initially set up
[20:38] <dobey> yofel: well launchpad gives a 404, and i can't possibly be a member of it, and not be able to see it
[20:38] <yofel> good point..
[20:39] <Unit193> https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035321.html Heh.
[20:48] <bdmurray> stgraber: it doesn't look like you are in error-tracker-access
[20:49] <stgraber> bdmurray: can you add me? I sure used to have access to that stuff back in the days ;)
[20:49] <bdmurray> stgraber: fixed now
[20:49] <stgraber> thanks
[20:50] <dobey> so confused
[20:52] <stgraber> dobey: no idea why you have access though :)
[20:53] <dobey> or why trying to view that team gives me a 404
[20:53] <stgraber> it's a private team
[20:53] <stgraber> so that part's normal
[20:53] <stgraber> (and you're not a member of it, just checked)
[20:53] <dobey> private private then i guess
[20:56] <mvo> infinity: lsb-release> ogra_ is unhappy about that python dependency there. and yes, a upstream key would be ideal, but I failed to send a upstream bugreport :/ sorry for that
[22:06] <cjwatson> jamespage: great, thanks
[22:07] <cjwatson> zequence: new package names (source or binary) cause manual review no matter what stage of development we're at
[23:01] <rxcomm> Can anyone point me to documentation on how to use the hashsum.mod module in grub2?