[00:52] <mwhudson> is someone repeatedly retrying all failed powerpc builds or something?
[01:24] <slangasek> mwhudson: yes, this is a common post-FF pasttime; it does pick up some legit toolchain fixes from time to time, but I've complained to the LP folks about generating emails to the uploaders instead of to the person clicking the retry button ;)
[01:25] <mwhudson> heh yes
[01:25] <mwhudson> retrying in launchpad is mostly "forget that you ever tried to build this"
[05:39] <pitti> Good morning
[05:41] <pitti> bdmurray: oh, the problem is not the /u/, I added a backwards compatible @route to accept and ignore that part; the problem is the trailing /
[05:41] <pitti> bdmurray: I'll update it, thanks for pointing out
[07:09] <ricotz> chrisccoulson, hey :)
[07:10] <ricotz> chrisccoulson, please retry the failed amd64 builds of thunderbird -- https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages
[07:17] <wgrant> seb128: I've mostly fixed yakkety translations today. Everything's copied from xenial (successfully, this time...) and the queue is slowly importing.
[07:18] <wgrant> They're not publicly visible yet, in case someone wants to check before we open it up.
[07:19] <seb128> wgrant, hey, ah, great, thanks!
[07:19] <seb128> what needs to be checked?
[07:19] <seb128> dpm, ^ you might know what to look at/want to check?
[07:20] <dpm> seb128, I certainly can, give me a few minutes
[07:20] <seb128> dpm, thanks!
[07:20] <dpm> thank you for following up!
[07:23] <wgrant> Sorry for the delay. The failed initial copy a couple of months ago required some handholding to clean up from.
[08:15] <seb128> cjwatson, ^ just in case you didn't notice, w_grant did the yakkety translations copy/import
[08:24] <dpm> seb128, wgrant, the templates look ok to me, I think I'll go ahead and make them visible to translators
[08:24] <seb128> dpm, great!
[08:24] <seb128> thanks
[08:26] <dpm> wgrant, ok, templates are now visible to translators and the translations focus is set to yakkety. Could you help us setting up the cron job in LP to do the exports for language packs?
[08:26] <wgrant> dpm: We should probably wait for the first round of imports to complete first.
[08:27] <dpm> ack
[08:51] <pitti> juliank: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt → apparently the new test hardcodes "amd64"
[08:51] <pitti> dpkg: error processing archive /tmp/tmp.xtWvRfrzRe/aptarchive/pool/initramfs-tools_1_amd64.deb (--unpack):
[08:51] <pitti>  package architecture (amd64) does not match system (armhf)
[08:51] <juliank> pitti: There's a bug in some re-ordering in the test suite, I'm already on it
[08:52] <pitti> juliank: ah cool, danke
[08:54] <juliank> pitti: Apparently gpg 2.1.15 also introduces a failure in the apt test suite due to additional output in the apt-cdrom test case.
[09:03] <pitti> jdstrand: click-apparmor seems unhappy in y, known? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apparmor-easyprof-ubuntu
[09:05] <juliank> pitti: The new browse.cgi is really awful. It breaks all my bookmarks
[09:05] <juliank> Which is http://autopkgtest.ubuntu.com/packages/a/apt/
[09:05] <juliank> and redirects to http://autopkgtest.ubuntu.com/browse.cgi/packages/a/apt/
[09:06] <juliank> which does not work
[09:06] <juliank> remove the a/ - still does not work, you also need to remove the trailing slash ...
[09:06] <juliank> Not to mention that browse.cgi just looks bad in the URL
[09:07] <juliank> Can this be fixed?
[09:08] <juliank> (Bookmark is actually the wrong term, it's what chrome suggests in its omnibox, and I can't really change that ...)
[09:09] <roaksoax> y
[09:16] <pitti> juliank: drop teh trailing slash
[09:17] <pitti> juliank: the /a/ is fine
[09:17] <pitti> juliank: if you tell me how to configure apache to hide the browse.cgi, I'm happy to do that
[09:17] <Laney> probably via some mod_rewrite fun
[09:17] <juliank> pitti: Well, the old interface normalized to a trailing slash, so the redirect should preferably handle that :)
[09:18] <pitti> https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/deployment/charms/trusty/autopkgtest-web/hooks/install#n32
[09:18] <pitti> that's the current config
[09:18] <pitti> juliank: I'll look into redirecting the trailing slash, hang on
[09:18] <juliank> For the trailing slash, maybe having a        RedirectMatch permanent "^/packages(.*)/" "/browse.cgi/packages\$1" before the other one works?
[09:18] <pitti> yep, something like that
[09:21] <juliank> I'm not sure, but would using RewriteRule instead of RedirectMatch permanent work, like RewriteRule "^/packages(.*)/" "/browse.cgi/packages\$1" [H=cgi-script]
[09:21]  * juliank is no apache expert
[09:24] <juliank> Well could try that with /test instead of /packages on the LHS and see what happens :D
[09:25] <pitti> juliank: trying in my juju-local deployment
[09:25] <juliank> pitti: Why is the new thing there anyway?
[09:26] <pitti> https://lists.ubuntu.com/archives/ubuntu-devel/2016-August/039486.html
[09:26] <juliank> cool
[09:31] <juliank> Hmm, apparently I am subscribed to ubuntu-devel but disabled mail delivery.
[09:31] <juliank> Weird
[09:34] <pitti> juliank: works now
[09:35] <juliank> Yay, thanks
[09:48] <Laney> Rewrite would be nicer, then you can hide the "browse.cgi"
[09:48] <Laney> AIUI
[09:48] <Laney> :)
[09:49] <pitti> Laney: how would Rewrite fix that? this is just cosmetics and aliases, not defining what the canonical path loooks like?
[09:49]  * pitti is an apache n00b, sorry
[09:50] <Laney> pitti: I think that rewrites do the rewriting internally
[09:51] <Laney> this is all bikeshedding on top of your good work though, sorry for that
[09:51] <pitti> Laney: no, don't be, I'm glad for hints how to hide browse.cgi
[09:51] <pitti> I tinkered around with that for some 10 mins but couldn't figure it out
[09:52] <Laney> I'll play if you like
[09:52] <Laney> (later)
[09:52] <pitti> Laney: flask has this flask.url_for() thing which knows about it's "base URL", and that includes browse.cgi
[09:53] <pitti> well, maybe not if the path that the browser reports never contains that
[09:53] <pitti> Laney: yes, not a biggie; I'll also keep it on the list to try
[09:53] <juliank> Oh the server should still report the browse.cgi path to the script
[09:53] <juliank> even if it's not visible in the browser due to a rewrite
[09:53] <juliank> AFAIUI
[09:53] <pitti> the issue is that generated URLs by the flask app should then also not contain it
[09:54] <juliank> Ah
[09:54] <juliank> yes
[09:54] <pitti> well, of course I could just manually sed it out, but that feels hackish
[09:54] <pitti> s/sed/subst/
[09:56] <Laney> pitti: http://flask.pocoo.org/docs/0.10/deploying/fastcgi/#configuring-apache seems like a good basis
[09:56] <pitti> I actually tried ScriptAlias / (seemed straightforward), but that didn't work for some reason
[09:56] <Laney> or s/0.10/latest/
[09:57] <pitti> but I'll try again
[09:57] <pitti> Laney: we still need /request.cgi though, so we cannot completely hide that
[09:58] <Laney> nod
[10:09] <cjwatson> seb128,wgrant: yep, I saw, thanks, that's a relief :)
[10:45] <Mirv> mitya57: a person reported transmission-qt crashing on startup with the new qtbase, but works if appmenu-qt5 removed. is this expected behavior with the new patches, and should there be a Conflicts added somewhere instead to force removal of appmenu-qt5?
[10:46] <Mirv> (mind you, this is talking about a qtbase not in archives yet)
[10:49] <doko> caribou: https://bugs.launchpad.net/ubuntu/+source/tomsfastmath/+bug/1619239
[10:56] <chrisccoulson> ricotz, ah, someone else retried them before I got a chance to take a look ;)
[10:56] <rbasak> caribou: did you notice that your clamav merge is stuck in proposed?
[11:01] <Mirv> mitya57: not that I could reproduce that though in LXC/yakkety at least. the reported was however on xenial + Qt 5.6 though, would https://launchpad.net/ubuntu/+source/appmenu-qt5/0.3.0+16.10.20160628.1-0ubuntu1 be required too?
[11:01] <ricotz> chrisccoulson, yeah, I asked colin some moments ago ;)
[11:03] <caribou> rbasak: no, will look at it
[11:07] <doko> Laney, seb128, jbicha: anybody looking at the gtk+3.0 autopkg test failures?
[11:11] <Laney> doko: Afraid not - I didn't upload it - but I think that they were previously analysed and it was decided they were all hintable
[11:11] <Laney> Looks like that wasn't done, but if someone confirms then I can add that
[11:12] <doko> I can't, don't know the history about it
[11:13] <doko> coreycb, jamespage: https://bugs.launchpad.net/ubuntu/+source/python-gnocchiclient/+bug/1536887  now needed for aodh
[11:38] <seb128> doko, same as Laney, I think pitti said it was all fine to override but unsure if he did it, jbicha did the upload so maybe check with him otherwise
[11:55] <caribou> rbasak: the merge introduced a depend on a Universe library :-(
[11:56] <caribou> rbasak: & I didn't spot it because I didn't upload it myself so I forgot to follow-up
[11:56] <rbasak> caribou: np, I should have spotted that on review.
[11:58] <caribou> rbasak: so I guess next step is to MIR tomsfastmath as doko proposed
[12:00] <rbasak> caribou: ah, sorry I missed that. Yes, or drop the dependency if possible, depending.
[12:01] <caribou> rbasak: I would opt for MIR as it drops an in-package copy of the code plus a bunch of patches
[12:01] <caribou> rbasak: I'll look at that once I'm off the hook with my OOM kernel issues
[12:02] <rbasak> caribou: OK. Thanks!
[12:03] <coreycb> doko, ok I'll take a look, thanks
[12:15] <jbicha> I don't even understand the gjs autopkgtest failure
[12:27] <pitti> seb128: no, not all -- isenkram needs to be looked at
[12:27] <pitti> just cjs and gjs are "known"
[12:27] <pitti> (regresssion due to gcc-6)
[12:27] <seb128> k
[12:27] <seb128> jbicha, doko, ^ somebody needs to look at that one
[12:27] <seb128> pitti, tahnks
[12:27] <seb128> thanks
[12:28] <doko> seb128: look at what?
[12:29] <seb128> doko, why p_itti said is a sumarry of the gtk autopkgtest status
[12:31] <jbicha> gjs didn't start failing until last week though but I can't even find the error in the logs
[12:31] <pitti> well, teh isenkram failure looks like a bug in isenkram itself
[12:32] <pitti> so if we want to ignore that, ok
[12:33] <pitti> jbicha: yeah, I grepped for "not ok", "error", "fail", a nuisance to find what's wrong
[12:37] <pitti> doko: qt and gtk will land next run
[12:38] <seb128> pitti, thanks
[12:39] <jbicha> thank you
[13:01] <juliank> pitti: The most recent apt:amd64 autopkgtest just reported "code 20" as result
[13:01] <juliank> (no space left on device during install)
[13:02] <juliank> Anyway, I have a fix for the apt gpg regression, still nothing for the non-amd64, though; I guess I'll just revert the commits now and fix that properly in the next few days
[13:32] <pitti> juliank: that's not your fault indeed; somewhere between yakkety, cloud-init and our clouds the root partition of the cloud image doesn't get resized properly (bug 1619285)
[13:41] <pitti> doko: python3-stdlib-extensions/3.5.2-1 and binutils/2.27-8ubuntu1 hinted through (ENOSPC problem)
[13:41] <doko> ahh, ok
[13:42] <doko> pitti: please hint python3.6 too
[13:43] <pitti> doko: done
[14:21] <Laney> pitti: are all autopkgtests going to fail on that bug?
[14:21] <pitti> Laney: only the bigger ones
[14:21] <xnox> and only on kvm
[14:22] <Laney> is bigger well defined?
[14:24] <pitti> Laney: 2 GB :)
[14:24] <Mirv> mitya57: ok an addendum I can confirm the crash on yakkety + silo 34 when appmenu-qt5 is installed
[14:24] <pitti> well, the system itself already takes about 1.1
[14:24] <pitti> xnox: yes, lxc is fine
[14:25] <Laney> isenkram works locally :|
[14:48] <juliank> python-apt test suite failure with gpg 2.1 should be fixed now upstream (just uploaded there), will sync that tomorrow
[14:55] <doko> jamespage, zul: horizon in Debian has a higher epoch (3) than in Ubuntu (2), and blocking some dependencies, like https://launchpad.net/ubuntu/+source/designate-dashboard/2.0.0-2/+build/10530093
[14:55] <jamespage> doko, that will get fixed with the b3 updates today
[14:55] <jamespage> its in the git repo, just not uploaded
[14:56] <doko> ta
[15:06] <bdmurray> pitti: Did you see my comment regarding ubuntu-release-upgrader tests starting to fail recently?
[15:07] <pitti> bdmurray: oh, did they? we've had force-badtest hints for it for a long time
[15:07] <pitti> committer: Steve Langasek <steve.langasek@canonical.com>
[15:07] <pitti> branch nick: hints-ubuntu
[15:07] <pitti> timestamp: Thu 2016-01-28 13:46:20 -0800
[15:07] <pitti> message:
[15:07] <pitti>   Force-badtest on ubuntu-release-upgrader, whose tests regressed for reasons unknown
[15:08] <pitti> oh, seems they worked again for a bit, and have flipped back and forth
[15:08] <bdmurray> pitti: they stopped working around the 25th
[15:08] <bdmurray> the xenial ones show pass but they haven't run since then
[15:10] <tdaitx> it seems the linux powerpc/ppc64el asm/ioctls.h is missing a include for asm-generic/ioctls.h (it's there for the other archs)
[15:14] <jdstrand> pitti: yes, I am aware. that is bug #1615757. cjwatson has a fix but there was a local build failure that he was trying to figure out
[15:17] <pitti> jdstrand: ah, thanks
[15:18] <cjwatson> jdstrand: I figured that out last weekend; it's just waiting for QA approval now
[15:32] <Saviq> cjwatson, hey, doesn't https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827315 affect LP builders? we've just hit that in our jenkins builders and wondering if we should just get sbuild 0.71 - will you guys backport it to ppa:launchpad/buildd-staging ?
[15:36] <tdaitx> pitti, xnox it seems the linux powerpc/ppc64el asm/ioctls.h is missing a include for asm-generic/ioctls.h (it's there for the other archs), who could know something about it?
[15:37] <xnox> tdaitx, #ubuntu-kernel and then ping apw or infinity. But both are here too =) so free ping =)
[15:37] <tdaitx> tks
[15:38] <xnox> tdaitx, is something parsing those headers in funny ways?
[15:39] <tdaitx> xnox, the reprapper package includes amf tools and that one uses a type and a macro that is available in asm-generic/ioctls.h, thus it fails to build on powerpc/ppc64el
[15:40] <Laney> URGH
[15:40] <Laney> this isenkram failure
[15:40] <tdaitx> xnox, ops, sorry, reprapper is the one using the type and macro
[15:41] <tdaitx> amf tools is packed inside it and causes reprapper to FTBFS due to another unrelated issue, I got confused =)
[15:42] <Laney> https://sources.debian.net/src/isenkram/0.24/isenkram/lookup.py/#L142
[15:42] <Laney> but it's getting a squid error back
[15:42] <Laney> and trying to parse that
[15:42] <Laney> what the :/
[15:43] <pitti> Laney: those URLs don't work any more I think
[15:43] <Laney> well I don't know why squid is giving an error
[15:43] <Laney> but the whole thing is ...
[15:43] <cjwatson> Saviq: I have a stupid annoying headache and can't currently work out whether that affects us or not.  Could we have a reminder bug against launchpad-buildd?
[15:44] <pitti> Laney: it's now https://anonscm.debian.org/cgit/collab-maint/isenkram.git
[15:44] <pitti> Laney: the gitweb? stuff stopped working a few weeks/months ago
[15:44] <Laney> the URL works
[15:44] <Laney> try it
[15:44] <Saviq> cjwatson, ack
[15:44] <pitti> Laney: "
[15:44] <pitti> 404 - No such project
[15:45]  * Laney is looking at a big list of packages and modaliases
[15:46] <pitti> Laney: hm, these gitweb? things haven't worked for me for a longer time now
[15:46] <pitti> odd
[15:46] <Laney> I just copied and pasted it from that file
[15:46] <pitti> so did I
[15:46] <Laney> ..
[15:46] <Laney> laney@nightingale> GET "https://anonscm.debian.org/gitweb/?p=collab-maint/isenkram.git;a=blob_plain;f=modaliases;hb=HEAD" | head -1                              ~/dev/canonical/release/hints-ubuntu
[15:46] <pitti> wget says the same
[15:47] <Laney> Package: alsa-firmware-loaders
[15:47] <Laney> http*s*
[15:47] <pitti> Laney: oh, that's not what the isenkram source says :)
[15:47] <Laney> the EFF did it!
[15:48] <tdaitx> pitti, Laney: that url works just fine for me
[15:48] <Laney> anyway, this is crazy
[15:50] <tdaitx> Laney, pitti oh wait, GET worked, but not on the browser (I get a "404 - No such project" page)
[15:51] <Laney> I think https everywhere is redirecting me
[15:52] <pitti> Laney: at least one less mystery today..
[15:53] <Laney> the new one uses appstream as well as this file
[15:53]  * Laney will sync that tomorrow
[15:53] <Laney> lies, merge -> this bug still exists
[15:53] <tdaitx> Laney, pitti alright, if I open the URL in the GET command it works, if I used the one with %3B (which replaces ;) it does not
[15:53] <Laney> haha
[15:53] <Laney> tdaitx: it's okay, I got this
[15:57] <tdaitx> anyway, using httpS is ok, accessing the http redirects to https BUT it replaces ";" with "%3B" and then it does not work
[15:59]  * Laney has filed a bug upstream
[15:59]  * Laney will upload a small workaround for now
[16:21] <seb128> cyphermox, Laney, ubiquity on the yakkety daily doesn't seem to have the nm page, did the fix that landed in xenial did in yakkety?
[16:22] <Laney> https://launchpad.net/ubuntu/+source/ubiquity/16.10.1
[16:22] <seb128> hum, it might be normal in a vm, ignore me
[16:24] <seb128> the slides are missing, bug #1618956 ... wondering if that's a webkitgtk issue?
[17:14] <mitya57> Mirv, replied on the bug; we need a rebuild of appmenu-qt5 or disable one of the patches
[17:14] <mitya57> whatever you prefer
[17:15] <mitya57> https://launchpad.net/ubuntu/+source/appmenu-qt5/0.3.0+16.10.20160628.1-0ubuntu1 is unrelated
[17:54] <hjd> Hi. I'm a bit confused regarding the code branches for recent releases. For instance https://code.launchpad.net/ubuntu/+source/multipath-tools contains up until Wily, and the git part seems to contain parts(?) of the changes for xenial, but I'm unable to find a branch for yakkety?
[18:43] <sarnold> hjd: https://launchpad.net/ubuntu/+source/multipath-tools
[19:15] <hjd> sarnold: Unless, I'm missing something obvious that's just the packages. I'm looking for the repos.
[19:16] <sarnold> hjd: I'm not 100% sure those still exist; there's been multiple atempts to add source control to packaging and I'm not sure which if any are succeeding
[19:16] <sarnold> hjd: that one -might- be in the server team's latest attempt; look for nacc on #ubuntu-server, perhaps
[19:17] <hjd> To elaborate a bit: I have a small patch (https://code.launchpad.net/~hjd/ubuntu/trusty/multipath-tools/bug1231182/+merge/192794) which seems like it made its way into trusty, though after it ceased being the development versions. So later releases retain the typo. Therefore I'm looking for a way to open a merge proposal against the current development version or other way...
[19:20] <sarnold> hjd: ha I don't even see 'avail' in what looks like the current thing https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/tree/debian/control?h=debian/sid
[19:20] <sarnold> oh of course the important debian/sid bit is way at the end of the url where it can't be seen
[19:21] <sarnold> https://code.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/+git/multipath-tools
[19:21] <sarnold> https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/tree/debian/control?h=ubuntu/devel
[19:24] <hjd> sarnold: It's not in Debian. :) The binary package (and in turn the typo) is part of the Ubuntu delta, try searching on https://launchpad.net/ubuntu/+source/multipath-tools/0.5.0+git1.656f8865-5ubuntu5
[19:24] <sarnold> hjd: yeah the last link I pasted has the typo included
[19:24] <sarnold> annoying that it was fixed and then lost again :(
[19:25] <hjd> Indeed :) So I thought I'd resubmit the patch, but I'm a bit stumped as to where/how...
[19:29] <sarnold> hjd: try suggesting a merge to that https://code.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/+git/multipath-tools tree
[19:34] <hjd> sarnold: Ok thanks. Will do :)
[19:45] <cjwatson> hjd: those imports were more-or-less deliberately not re-enabled after wily because they were hopelessly unreliable; basically they worked as long as nobody committed to them directly.  the hope is that in the not too distant future we'll get a git replacement
[19:46] <cjwatson> hjd: but you can submit a patch as a straight diff
[19:46] <cjwatson> (in a bug or whatever)
[19:52] <hjd> cjwatson: Oh, I wasn't aware they were so unreliable.
[19:53] <cjwatson> A lot of it can (unfortunately) be traced back to the decision to have explicit file-ids in bzr, I believe
[19:53] <cjwatson> So there's good reason to believe that a git version will be inherently more reliable
[19:54] <sarnold> cjwatson: is there a quick summary of that problem?
[19:54] <cjwatson> Err, pass
[19:54] <sarnold> I always thought the problem was that some people kept working with the packages directly and the people using the source ontrol systems didn't always import the changes made to the packages before fiddling with them..
[19:54] <sarnold> heh, alright :)
[19:54] <cjwatson> It was meant to deal with that
[19:57] <hjd> Readded a patch at bug 1231182 now. Can
[19:57] <hjd> 't remember which team to assign, but maybe a bot does that automatically these days?
[20:02] <hjd> (I tried to make a git branch first, but it didn't find how to submit a merge proposal for the other repo. I may have simply messed up though, because it's the first time I've used the git-parts of LP, https://code.launchpad.net/~hjd/+git/multipath-tools)
[20:22] <hjd> Thanks for the help and good night everyone :)
[20:24] <ahoneybun> I know Unity7 is in not getting any big new features but where would I go to add a calculator to the Dash?
[21:12] <xnox> sil2100, Mirv: i think something is terribly broken in ubuntu-touch seeds/depends on amd64
[21:12] <xnox> it depends on qml-module-ubuntu-components-gles
[21:13] <xnox> and it depends on ubuntu-sdk-libs
[21:13] <xnox> the two eventually conflict as they try to install -gles and non-gles variants of things down the road.
[21:14] <xnox> ah
[21:14] <xnox> ubuntu-sdk-libs depends on qml-module-ubuntu-components
[21:14] <xnox> horum lost again.
[21:16] <xnox> ubuntu-touch -> qml-module-ubuntu-components
[21:17] <xnox> got it.
[21:18] <xnox> ubuntu-touch -> qml-module-ubuntu-components-gles
[21:18] <xnox> ubuntu-touch -> ubuntu-sdk-libs -> qml-module-ubuntu-components
[21:18] <xnox> the -gles and non-gles conflict.
[21:19] <xnox> and many similar.
[22:11] <doko> all these ci-train builds are really annoying ...
[23:02] <cjwatson> doko: the ci-train folks find your test rebuilds annoying too :)