[04:43] <pitti> sergiusens: xenial snapcraft tests are done
[04:44] <pitti> flocculant: Laney fixed it (thanks!), should be all good now, right? unfortunately this wasn't obvious on ubuntu desktop
[06:39] <flocculant> pitti: yup all seems fine thanks. And yes, it wasn't obvious anywhere but xubuntu and mate - I did check those, ubuntu, lubuntu and gnome :)
[06:40] <flocculant> studio would have been broken too - but that appears to have other issues anyway - no dailies since the 18th
[06:57] <sakrecoer> thanks for bringin it up flocculant . atm there is something with gnupg1
[07:00] <sakrecoer> but the few times i've tried to install the iso after it build successfully, the installation would fail (Ubuntu-Studio that is)
[07:10] <Mirv> could someone remove s390x binaries for src:ubuntu-system-settings-online-accounts in yakkety? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings-online-accounts
[07:24] <pitti> Mirv: y-release already does not have s390x binaries
[07:24] <pitti> Mirv: the problem is that the new version in -proposed builds them
[07:24] <pitti> Mirv: i. e. the package wasn't changed to not build on s390x
[07:25] <pitti> like that we'd need to manually remove the binaries for every new upload, that's impractical
[07:26] <pitti> Mirv: you could also make the removed package, like libsystemsettings-dev, a build-depends
[07:26] <pitti> (nicer than mangling Arch:)
[07:33] <flocculant> infinity: studio's iso is stuck rebuilding since Saturday. Also has some issues which mean little to me according to the build logs
[07:34] <flocculant> or Laney if Laney really is being brave and doing b1 for people :p
[07:56] <Mirv> pitti: right, I was under impression they had already integrated a change like that in this release, but it seems not. I will propose MP myself if they don't have one.
[07:58] <Mirv> pitti: actually, it seems they already do build depend on libsystemsettings-dev, they just apparently had built this build in a silo at a time when u-s-s was again available
[07:58] <Mirv> https://launchpadlibrarian.net/273706024/ubuntu-system-settings-online-accounts_0.7+16.10.20160718-0ubuntu1.diff.gz debian/control
[07:59] <pitti> Mirv: oh, ok; so if we remove those, the next build should work as intended?
[08:00] <Mirv> pitti: so it would look like to me, as libsystemsettings-dev is unavailable on s390x now
[08:00] <pitti> Mirv: done
[08:01] <pitti> Mirv: the version number is odd, though -- July 18 is over a month ago
[08:01] <Mirv> thank you. and u-s-s itself has now a dependency on upstart to prevent those binaries from resurfacing.
[08:03] <Mirv> pitti: it languished in a silo for a longer period as the silo had other package that needed fixes and rebuilds while this remained non touched. then QA took its time, and then we delayed the publishing to yakkety in order to get the transition done.
[08:03] <Mirv> but seems all normal according to ticket logs
[08:03] <Mirv> also in the middle there was two weeks of "nothing happened" it seems, so upstream was doing something else or on holidays
[08:04] <pitti> ack
=== ant_ is now known as Guest67209
[09:11] <Mirv> not sure why but I can't see the removal at https://launchpad.net/ubuntu/yakkety/s390x/ubuntu-system-settings-online-accounts
[10:03] <mvo> hi, quick question - snap-confine appears to be ready for release into xenial-updates, its in there for 9 days and all bugs are verification-done. anything else that needs to happen here?
[10:03] <mvo> i.e. anytihng we can do to help :)
[10:12] <pitti> mvo: no, JFDI thing; it wasn't old enough on Friday yet, then weekend :)
[10:12]  * pitti does a round of releasing
[10:12] <pitti> hm, all the bugs are still marked unfixed in y
[10:12] <mvo> pitti: ha! indeed, this weekend thing
[10:12] <mvo> pitti: oh, let me double check that
[10:13] <pitti> mvo: e. g. bug 1612684 says that it will be released in 1.0.40 which isn't in y yet
[10:13] <ubot5> bug 1612684 in snap-confine (Ubuntu) "dies when run in a place that is not inside the snap chroot" [Undecided,New] https://launchpad.net/bugs/1612684
[10:13] <pitti> so it's not just "missing changelog ref", but actually missing
[10:14] <mvo> pitti: yes, let me chase that, sorry, I assumed it was already uploaded but was wrong
[11:00] <Mirv> pitti: it feels your removal didn't work http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings-online-accounts ( + the https://launchpad.net/ubuntu/yakkety/s390x/ubuntu-system-settings-online-accounts )
[11:06] <xnox> looks like it needs to be removed again in yakkety-proposed/s390x, or the removal was not published yet.
[11:14] <sakrecoer> this was brought to my attention: http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/yakkety/daily-live-20160822.log seems the build was succesfull, but the tracker it is nowhere to find
[11:15] <sakrecoer> wait.. sorry.. that is not studio ..
[11:37] <LocutusOfBorg> hi cjwatson sorry for bothering, but I don't think your haskell-werewolf removal worked
[11:37] <LocutusOfBorg>  libghc-werewolf-dev | 1.0.2.2-1build2 | yakkety-proposed/universe | powerpc
[11:37] <LocutusOfBorg> it is a removal that affects -proposed only (it built here by error)
[11:38] <ogra> not enough silver bullets ?
[11:38] <LocutusOfBorg> I hope to see haskell-migrate later today or something similar, if my guessing is correct
[11:39]  * davmor2 hands ogra more silver bullets
[11:41] <LocutusOfBorg> or any other archive admin, removing a package that never landed on yakkety release should be "easy" (for an unknown to me value of easy)
[11:52]  * apw notes that is two complaints of removals not seeming to have worked ...
[11:59] <cjwatson> LocutusOfBorg: I never removed haskell-werewolf/powerpc; my logs tell me that the one you asked me for was haskell-http-link-header/powerpc.
[12:00] <cjwatson> (Removals don't work if they weren't asked for.)
[12:00] <apw> :)
[12:02] <cjwatson> LocutusOfBorg: removed now
[14:23] <sakrecoer> sorry for nagging, but.. any chance ubuntu studio will have an iso ready today/tonight?
[14:23] <sakrecoer> the error seem to be "gnupg1 : Breaks: gnupg (< 1.4.20-6+exp1) but 1.4.20-6ubuntu1 is to be installed kactivitymanagerd : Breaks: kactivities (< 5.20~) but 5.18.0-0ubuntu1 is to be installed"
[14:24] <sakrecoer> i'm affraid i'm not very technical, but if there is anything i can do to help make it easier, let me know :)
[14:44] <apw> the first of those looks a little like they have renamed gnupg to gnupg1 in debian, which will wreak havoc with our delta
[14:45] <xnox> apw, yeah, and we need to merge new gpg2 to take that.
[14:46] <xnox> surely kactivitymanagerd should do depend on gnupg for now in ubuntu or some such.
[14:46] <xnox> or we should just merge new gnupg in place.
[14:50] <jbicha> Mirv: do you know what specific s390x packages should be removed for qtorganizer5-eds for the evolution 3.22 transition?
[14:52] <jbicha> xnox: I think it would be better to do the ggp transition after beta 1 (livecd-rootfs uses gpg for instance)
[15:10] <renatu> Hey guys. Could you remove binaries of sync-monitor from yakkety/sync-monitor. to unblock this silo? https://requests.ci-train.ubuntu.com/#/ticket/1827
[15:11] <renatu> yakkety/s390x
[15:56] <robru> pitti: infinity: can you two discuss the correct checkUpload call I should use in the case that the source package is NEW? infinity already chose flashplugin-nonfree/universe when the code was initially written but pitti says this is invalid. I'm not sure what would be correct.
[15:58] <cjwatson> It's probably a Launchpad bug that sourcepackagename is required there.
[15:59] <cjwatson> The underlying code allows querying without a sourcepackagename; it's just not declared that way in the webservice interface.
[16:28] <robru> cjwatson: right, but I still need something to use for now. infinity chose flashplugin-nonfree/universe, pitti says flashplugin-nonfree is in multiverse so this is invalid, but it's been working in production for many months.
[16:29] <robru> I'm not sure if we should pick a different source package name that's really in universe or just leave it
[17:27] <pitti> robru: or change universe to multiverse
[17:28] <pitti> robru: but I think taking an actual universe package is more correct, as train uploads usually don't go into multiverse
[17:28] <robru> pitti: I don't believe that's correct, the purpose of the test is to ensure that the person has permission to upload to universe, which is the default place for NEW uploads.
[17:28] <pitti> but yes, flashplugin-nonfree/universe is not a thing
[17:28] <robru> pitti: but apparently testing if the user has permission to  upload flashplugin-nonfree into universe is successful at determining if the user has permission to upload NEW things into universe.
[17:29] <pitti> robru: oh -- then please don't call it flashplugin-nonfree, but "i-am-a-new-package" or so
[17:30] <pitti> semantically, *nobody* should be able to upload flashplugin-nonfree to universe
[17:30] <robru> pitti: I was under the impression that it needed to be an existing package that could never ever be in main.
[17:31] <pitti> robru: maybe this is supposed to catch some weird corner case or LP API quirk, but then it deserves a long comment :)
[17:31] <pitti> like that it looks just plain wrong
[17:31] <robru> pitti: if "i-am-a-new-package" would have worked then we would have just used the actual name of the package. infinity was the one who came up with this as-is
[17:32] <pitti> well, I couldn't even say what it *means* to upload flashplugin-nonfree to universe
[17:32] <pitti> that's simply an invalid question
[17:33] <pitti> well, that's all what I can say about it :) maybe infinity remembers the specifics, then I suggest documenting this in a comment
[17:34]  * pitti bids good night
[17:42] <sergiusens> slangasek hi, mind letting snapcraft into xenial-updates?
[18:20] <slangasek> sergiusens: done; NB this shouldn't block on me, we have a weekly rotation for the SRU team: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[18:23] <sergiusens> slangasek yeah, sorry, I just lazily picked you as you were up to speed with the status for this
=== tsimonq2alt is now known as tsimonq2
[18:51] <renatu> pitti, Hi, Could you help me. I need remove binaries of sync-monitor from yakkety/s390x. to unblock this silo? https://requests.ci-train.ubuntu.com/#/ticket/1827
[19:20] <slangasek> renatu: it's a bit out of pitti's work hours; let me see
[19:20] <renatu> slangasek, thanks
[19:24] <slangasek> renatu: resolved.  so the version currently in yakkety-proposed will need to land first, which I think will mean
[19:24] <slangasek> renatu: landing-053 will need to merge the result of that landing and rebuild?
[19:25] <slangasek> (I'm assuming sync-monitor 0.2+16.10.20160804-0ubuntu1 is a landing, though I don't easily find the ticket)
[19:26] <renatu> slangasek, I do not think that we have any sync-monitor pending to land
[19:26] <renatu> let me re-check
[19:26] <slangasek> renatu: well, the binaries I just removed are from yakkety-proposed; did someone force-merge a landing that wasn't in yakkety yet?
[19:27] <slangasek> renatu: https://launchpad.net/ubuntu/+source/sync-monitor/0.2+16.10.20160804-0ubuntu1 look familiar?
[19:27] <renatu> let me see
[19:27] <slangasek> appears to be this landing: https://requests.ci-train.ubuntu.com/#/ticket/1643
[19:28] <renatu> humm yes, this was approved recently
[19:28] <renatu> ok I will make sure to merge it before land my silo
[19:28] <slangasek> so someone force-landed it
[19:28] <renatu> thanks
[19:28]  * slangasek nods
[19:29] <slangasek> robru: ^^ seems a bad use of force-merge fwiw, since that landing was stalled indefinitely in yakkety-proposed due to uninstallable s390x binaries
[19:31] <robru> slangasek: Mirv did that one, it's possible some other issue obscured the s390x issue at the time it was forced?
[19:31] <slangasek> now running through http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html for other instances of '/s390x unsatisfiable Depends', should let us clear up a few more landings
[19:32] <slangasek> robru: sure, possible :)
[19:32] <robru> This s390x thing just won't die
[19:33] <slangasek> well, as has been noted, the ubuntu phone stack's dependency on upstart needs to be transitioned to systemd
[19:34] <robru> slangasek: might be easier to just delete all of s390x and start over rather than pick apart all these binaries ;-)
[19:34] <slangasek> nope
[19:34] <robru> Heh
[19:36]  * slangasek wonders who subscribed foundations-bugs to libstring-copyright-perl without filing an MIR
[19:36]  * slangasek wonders if it was himself
[20:16] <slangasek> oh hey, haskell stuff migrating?
[20:54] <sakrecoer> hello, our iso still fails for same reason. we are having troubles finding what is using gpg1, we have no working image to look in... could this have something to do with it? https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1615039
[20:54] <ubot5> Launchpad bug 1615039 in gnupg2 (Ubuntu) "[FFe] /usr/bin/gnupg --version should be 2.1" [Undecided,New]
[20:54] <sakrecoer> our= ubuntustudio
[21:09] <LocutusOfBorg> haskell is migrating :)
[21:13] <slangasek> sakrecoer: sakrecoer where are you seeing the error in question?
[21:13] <renatu> slangasek, hey got the same error again: https://requests.ci-train.ubuntu.com/#/ticket/1827
[21:14] <sakrecoer> slangasek: here: https://launchpadlibrarian.net/280394054/buildlog_ubuntu_yakkety_i386_ubuntustudio_BUILDING.txt.gz
[21:14] <sakrecoer> gnupg1 : Breaks: gnupg (< 1.4.20-6+exp1) but 1.4.20-6ubuntu1 is to be installed kactivitymanagerd : Breaks: kactivities (< 5.20~) but 5.18.0-0ubuntu1 is to be installed
[21:14] <jbicha> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio
[21:14] <slangasek> robru: does something need manually rerun so that renatu's landing (https://requests.ci-train.ubuntu.com/#/ticket/1827) doesn't show as 'dep-wait' on an arch that is not out-of-date?
[21:15] <sakrecoer> thank you jbicha
[21:15] <robru> slangasek: status job runs every 20 minutes
[21:16] <slangasek> sakrecoer: what is referencing gnupg1, and why?
[21:17] <sakrecoer> slangasek: we can't seem to find out. we have no working image to check with.
[21:17] <robru> slangasek: how long ago did you delete the binaries?
[21:18] <slangasek> robru: 2 hours ago
[21:19] <slangasek> sakrecoer: python3-gnupg Depends: gnupg1; this is buggy, looks like it was a bad autosync, right before DIF.
[21:19] <robru> slangasek: according to https://launchpad.net/ubuntu/+source/sync-monitor/0.2+16.10.20160804-0ubuntu1 s390x is still there
[21:19] <slangasek> sakrecoer: so someone needs to fix that to depend on gnupg (< 2) in preference to gnupg1
[21:20] <slangasek> robru: the build record doesn't disappear just because the binaries had been deleted
[21:21] <sakrecoer> slangasek: ok, any suggestion on a someone succeptible to fix that i can reach out to?
[21:21] <robru> slangasek: that says that was published 30 minutes ago. what did you delete 2 hours ago?
[21:21] <slangasek> robru: it was published to yakkety from yakkety-proposed. the deletion of the binaries from s390x 2 hours ago is what /allowed/ it to publish
[21:21] <jbicha> sakrecoer: deken depends on python-gnupg which depends on gnupg1
[21:22] <jbicha> found by digging through germinate
[21:22] <robru> slangasek: I don't know what to tell you. bileto is looking at the package and seeing successful s390x builds and thus reporting the s390x failures in the PPA.
[21:22] <slangasek> robru: "and seeing successful s390x builds and thus reporting" - ok, then it's a bileto bug ;)
[21:22] <sakrecoer> thanks you jbicha! :)
[21:23] <robru> slangasek: I doubt it, this code has been working well for months and I haven't touched it
[21:23] <sakrecoer> thank you slangasek
[21:23] <slangasek> robru: what you have just described is a wrong check
[21:23] <jbicha> sakrecoer: here, let me revert python-gnupg to 0.3.8-2 to see if that fixes things for this week
[21:24] <slangasek> robru: the package built previously on s390x.  The binaries were then removed.  Bileto needs to know whether the new version of the package is regressing architecture support, which it doesn't know by looking at whether the package previously built, it has to look at whether the built binaries are removed
[21:24] <robru> slangasek: this is how it's been even since lp:cupstream2distro, no problems for months and months and months. http://bazaar.launchpad.net/+branch/bileto/view/head:/bileto/worker/package.py#L127
[21:25] <slangasek> robru: telling me that no one has reported this bug to you is not a counterproof
=== Adri2000_ is now known as Adri2000
[21:25] <sakrecoer> thank you very much jbicha !
[21:25] <robru> slangasek: I'm telling you that it has never failed to correctly determine what arches we care about.
[21:25] <slangasek> jbicha: why would you revert python-gnupg, instead of just adjusting the dependency as I suggested above?
[21:26] <robru> slangasek: if getPublishedBinaries is reporting more binaries than there should be, then it's a bug in lp.
[21:26] <slangasek> robru: ah, you didn't say you were checking getPublishedBinaries, which *is* the correct check AFAIK
[21:27] <jbicha> slangasek: because they actually changed the code to gpg1 https://launchpadlibrarian.net/279890088/python-gnupg_0.3.8-2_0.3.8-3.diff.gz
[21:27] <robru> slangasek: ah yes, I said "builds" by mistake, I meant binaries.
[21:27] <slangasek> jbicha: that sounds like a good reason
[21:28] <robru> slangasek: maybe you deleted binaries for some binary packages but not all binary packages produced by that source?
[21:28] <slangasek> robru: the only ones I didn't delete were the architecture: all ones; I suppose that could be the issue, let me see
[21:30] <slangasek> robru: (I've generally assumed that when removing binaries with -a <arch>, I don't need to remove the arch: all ones - AFAIK they'll just come right back on the next build since the arch: all binaries are published for all archs, so I wouldn't expect bileto to care about this)
[21:31] <robru> slangasek: hm, shouldn't be arch: all, it does specifically filter out binaries that are architecture_specific=False
[21:31] <slangasek> ok
[21:31] <slangasek> then it may simply be that as of the last status job run, LP was still catching up
[21:34] <jbicha> sakrecoer: done, so we'll just have to retry the iso build tomorrow once germinate has picked up the change
[21:34] <robru> slangasek: I'm gonna head out for lunch, will follow up later
[21:38] <sakrecoer> jbicha: you rock! thanks!!! :)
[21:39] <sakrecoer> i'm signing off, read you tomorrow! o/
[21:43] <jbicha> sakrecoer: for reference, I used https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.yakkety/all
[21:48] <renatu> slangasek, robru, The silo was ok some time ago. But it change to failed recently
[21:49] <renatu> slangasek, it was ok when you told me that you had deleted the package. But then after I mark it as approved it changed to fail
[21:49] <renatu> I am not sure if is related with the fact that I marked it as approved
[22:38] <robru> renatu: no, marking it as approved won't make it start considering more architectures
[22:47] <robru> slangasek: this is what bileto is seeing in lplib: http://paste.ubuntu.com/23079883/
[22:49] <slangasek> robru: heh; then perhaps that's a britney bug, because those are the same binaries I removed from yakkety-proposed
[22:49] <slangasek> robru: so, removing them again :)
[22:50] <robru> slangasek: thanks
[22:54] <flocculant> slangasek: not sure who best to point this at (possibly cyphermox) but using iso from today - which had installed perfectly with UK language and UK keyboard - installer crashed when I tried to use French - seem to be a few dupes of this bug, bug 1615847
[22:54] <ubot5> bug 1615847 in ubiquity (Ubuntu) "Ubiquity crashes with non english setup" [Undecided,New] https://launchpad.net/bugs/1615847
[23:02] <flocculant> hesitating to set bugs as dupes, but journal errors seem to be the same
[23:06] <slangasek> "could not convert string to float" lol ok
[23:13] <flocculant> slangasek: I gave up trying to write the description with a french layout and opted for editing it afterwards:)
[23:13] <flocculant> anyway - thanks for looking there
[23:13]  * flocculant wanders off again