pittisergiusens: xenial snapcraft tests are done04:43
pittiflocculant: Laney fixed it (thanks!), should be all good now, right? unfortunately this wasn't obvious on ubuntu desktop04:44
flocculantpitti: 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:39
flocculantstudio would have been broken too - but that appears to have other issues anyway - no dailies since the 18th06:40
sakrecoerthanks for bringin it up flocculant . atm there is something with gnupg106:57
sakrecoerbut the few times i've tried to install the iso after it build successfully, the installation would fail (Ubuntu-Studio that is)07:00
Mirvcould 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-accounts07:10
pittiMirv: y-release already does not have s390x binaries07:24
pittiMirv: the problem is that the new version in -proposed builds them07:24
pittiMirv: i. e. the package wasn't changed to not build on s390x07:24
pittilike that we'd need to manually remove the binaries for every new upload, that's impractical07:25
pittiMirv: you could also make the removed package, like libsystemsettings-dev, a build-depends07:26
pitti(nicer than mangling Arch:)07:26
flocculantinfinity: studio's iso is stuck rebuilding since Saturday. Also has some issues which mean little to me according to the build logs07:33
flocculantor Laney if Laney really is being brave and doing b1 for people :p07:34
Mirvpitti: 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:56
Mirvpitti: 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 available07:58
Mirvhttps://launchpadlibrarian.net/273706024/ubuntu-system-settings-online-accounts_0.7+16.10.20160718-0ubuntu1.diff.gz debian/control07:58
pittiMirv: oh, ok; so if we remove those, the next build should work as intended?07:59
Mirvpitti: so it would look like to me, as libsystemsettings-dev is unavailable on s390x now08:00
pittiMirv: done08:00
pittiMirv: the version number is odd, though -- July 18 is over a month ago08:01
Mirvthank you. and u-s-s itself has now a dependency on upstart to prevent those binaries from resurfacing.08:01
Mirvpitti: 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
Mirvbut seems all normal according to ticket logs08:03
Mirvalso in the middle there was two weeks of "nothing happened" it seems, so upstream was doing something else or on holidays08:03
=== ant_ is now known as Guest67209
Mirvnot sure why but I can't see the removal at https://launchpad.net/ubuntu/yakkety/s390x/ubuntu-system-settings-online-accounts09:11
mvohi, 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
mvoi.e. anytihng we can do to help :)10:03
pittimvo: no, JFDI thing; it wasn't old enough on Friday yet, then weekend :)10:12
* pitti does a round of releasing10:12
pittihm, all the bugs are still marked unfixed in y10:12
mvopitti: ha! indeed, this weekend thing10:12
mvopitti: oh, let me double check that10:12
pittimvo: e. g. bug 1612684 says that it will be released in 1.0.40 which isn't in y yet10:13
ubot5bug 1612684 in snap-confine (Ubuntu) "dies when run in a place that is not inside the snap chroot" [Undecided,New] https://launchpad.net/bugs/161268410:13
pittiso it's not just "missing changelog ref", but actually missing10:13
mvopitti: yes, let me chase that, sorry, I assumed it was already uploaded but was wrong10:14
Mirvpitti: 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:00
xnoxlooks like it needs to be removed again in yakkety-proposed/s390x, or the removal was not published yet.11:06
sakrecoerthis 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 find11:14
sakrecoerwait.. sorry.. that is not studio ..11:15
LocutusOfBorghi cjwatson sorry for bothering, but I don't think your haskell-werewolf removal worked11:37
LocutusOfBorg libghc-werewolf-dev | | yakkety-proposed/universe | powerpc11:37
LocutusOfBorgit is a removal that affects -proposed only (it built here by error)11:37
ogranot enough silver bullets ?11:38
LocutusOfBorgI hope to see haskell-migrate later today or something similar, if my guessing is correct11:38
* davmor2 hands ogra more silver bullets11:39
LocutusOfBorgor 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:41
* apw notes that is two complaints of removals not seeming to have worked ...11:52
cjwatsonLocutusOfBorg: I never removed haskell-werewolf/powerpc; my logs tell me that the one you asked me for was haskell-http-link-header/powerpc.11:59
cjwatson(Removals don't work if they weren't asked for.)12:00
cjwatsonLocutusOfBorg: removed now12:02
sakrecoersorry for nagging, but.. any chance ubuntu studio will have an iso ready today/tonight?14:23
sakrecoerthe 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:23
sakrecoeri'm affraid i'm not very technical, but if there is anything i can do to help make it easier, let me know :)14:24
apwthe first of those looks a little like they have renamed gnupg to gnupg1 in debian, which will wreak havoc with our delta14:44
xnoxapw, yeah, and we need to merge new gpg2 to take that.14:45
xnoxsurely kactivitymanagerd should do depend on gnupg for now in ubuntu or some such.14:46
xnoxor we should just merge new gnupg in place.14:46
jbichaMirv: do you know what specific s390x packages should be removed for qtorganizer5-eds for the evolution 3.22 transition?14:50
jbichaxnox: I think it would be better to do the ggp transition after beta 1 (livecd-rootfs uses gpg for instance)14:52
renatuHey guys. Could you remove binaries of sync-monitor from yakkety/sync-monitor. to unblock this silo? https://requests.ci-train.ubuntu.com/#/ticket/182715:10
robrupitti: 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:56
cjwatsonIt's probably a Launchpad bug that sourcepackagename is required there.15:58
cjwatsonThe underlying code allows querying without a sourcepackagename; it's just not declared that way in the webservice interface.15:59
robrucjwatson: 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:28
robruI'm not sure if we should pick a different source package name that's really in universe or just leave it16:29
pittirobru: or change universe to multiverse17:27
pittirobru: but I think taking an actual universe package is more correct, as train uploads usually don't go into multiverse17:28
robrupitti: 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
pittibut yes, flashplugin-nonfree/universe is not a thing17:28
robrupitti: 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:28
pittirobru: oh -- then please don't call it flashplugin-nonfree, but "i-am-a-new-package" or so17:29
pittisemantically, *nobody* should be able to upload flashplugin-nonfree to universe17:30
robrupitti: I was under the impression that it needed to be an existing package that could never ever be in main.17:30
pittirobru: maybe this is supposed to catch some weird corner case or LP API quirk, but then it deserves a long comment :)17:31
pittilike that it looks just plain wrong17:31
robrupitti: 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-is17:31
pittiwell, I couldn't even say what it *means* to upload flashplugin-nonfree to universe17:32
pittithat's simply an invalid question17:32
pittiwell, that's all what I can say about it :) maybe infinity remembers the specifics, then I suggest documenting this in a comment17:33
* pitti bids good night17:34
sergiusensslangasek hi, mind letting snapcraft into xenial-updates?17:42
slangaseksergiusens: done; NB this shouldn't block on me, we have a weekly rotation for the SRU team: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing18:20
sergiusensslangasek yeah, sorry, I just lazily picked you as you were up to speed with the status for this18:23
=== tsimonq2alt is now known as tsimonq2
renatupitti, 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/182718:51
slangasekrenatu: it's a bit out of pitti's work hours; let me see19:20
renatuslangasek, thanks19:20
slangasekrenatu: resolved.  so the version currently in yakkety-proposed will need to land first, which I think will mean19:24
slangasekrenatu: landing-053 will need to merge the result of that landing and rebuild?19:24
slangasek(I'm assuming sync-monitor 0.2+16.10.20160804-0ubuntu1 is a landing, though I don't easily find the ticket)19:25
renatuslangasek, I do not think that we have any sync-monitor pending to land19:26
renatulet me re-check19:26
slangasekrenatu: well, the binaries I just removed are from yakkety-proposed; did someone force-merge a landing that wasn't in yakkety yet?19:26
slangasekrenatu: https://launchpad.net/ubuntu/+source/sync-monitor/0.2+16.10.20160804-0ubuntu1 look familiar?19:27
renatulet me see19:27
slangasekappears to be this landing: https://requests.ci-train.ubuntu.com/#/ticket/164319:27
renatuhumm yes, this was approved recently19:28
renatuok I will make sure to merge it before land my silo19:28
slangasekso someone force-landed it19:28
* slangasek nods19:28
slangasekrobru: ^^ seems a bad use of force-merge fwiw, since that landing was stalled indefinitely in yakkety-proposed due to uninstallable s390x binaries19:29
robruslangasek: Mirv did that one, it's possible some other issue obscured the s390x issue at the time it was forced?19:31
slangaseknow 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 landings19:31
slangasekrobru: sure, possible :)19:32
robruThis s390x thing just won't die19:32
slangasekwell, as has been noted, the ubuntu phone stack's dependency on upstart needs to be transitioned to systemd19:33
robruslangasek: might be easier to just delete all of s390x and start over rather than pick apart all these binaries ;-)19:34
* slangasek wonders who subscribed foundations-bugs to libstring-copyright-perl without filing an MIR19:36
* slangasek wonders if it was himself19:36
slangasekoh hey, haskell stuff migrating?20:16
sakrecoerhello, 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/161503920:54
ubot5Launchpad bug 1615039 in gnupg2 (Ubuntu) "[FFe] /usr/bin/gnupg --version should be 2.1" [Undecided,New]20:54
sakrecoerour= ubuntustudio20:54
LocutusOfBorghaskell is migrating :)21:09
slangaseksakrecoer: sakrecoer where are you seeing the error in question?21:13
renatuslangasek, hey got the same error again: https://requests.ci-train.ubuntu.com/#/ticket/182721:13
sakrecoerslangasek: here: https://launchpadlibrarian.net/280394054/buildlog_ubuntu_yakkety_i386_ubuntustudio_BUILDING.txt.gz21:14
sakrecoergnupg1 : 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 installed21:14
slangasekrobru: 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:14
sakrecoerthank you jbicha21:15
robruslangasek: status job runs every 20 minutes21:15
slangaseksakrecoer: what is referencing gnupg1, and why?21:16
sakrecoerslangasek: we can't seem to find out. we have no working image to check with.21:17
robruslangasek: how long ago did you delete the binaries?21:17
slangasekrobru: 2 hours ago21:18
slangaseksakrecoer: python3-gnupg Depends: gnupg1; this is buggy, looks like it was a bad autosync, right before DIF.21:19
robruslangasek: according to https://launchpad.net/ubuntu/+source/sync-monitor/0.2+16.10.20160804-0ubuntu1 s390x is still there21:19
slangaseksakrecoer: so someone needs to fix that to depend on gnupg (< 2) in preference to gnupg121:19
slangasekrobru: the build record doesn't disappear just because the binaries had been deleted21:20
sakrecoerslangasek: ok, any suggestion on a someone succeptible to fix that i can reach out to?21:21
robruslangasek: that says that was published 30 minutes ago. what did you delete 2 hours ago?21:21
slangasekrobru: it was published to yakkety from yakkety-proposed. the deletion of the binaries from s390x 2 hours ago is what /allowed/ it to publish21:21
jbichasakrecoer: deken depends on python-gnupg which depends on gnupg121:21
jbichafound by digging through germinate21:22
robruslangasek: 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
slangasekrobru: "and seeing successful s390x builds and thus reporting" - ok, then it's a bileto bug ;)21:22
sakrecoerthanks you jbicha! :)21:22
robruslangasek: I doubt it, this code has been working well for months and I haven't touched it21:23
sakrecoerthank you slangasek21:23
slangasekrobru: what you have just described is a wrong check21:23
jbichasakrecoer: here, let me revert python-gnupg to 0.3.8-2 to see if that fixes things for this week21:23
slangasekrobru: 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 removed21:24
robruslangasek: 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#L12721:24
slangasekrobru: telling me that no one has reported this bug to you is not a counterproof21:25
=== Adri2000_ is now known as Adri2000
sakrecoerthank you very much jbicha !21:25
robruslangasek: I'm telling you that it has never failed to correctly determine what arches we care about.21:25
slangasekjbicha: why would you revert python-gnupg, instead of just adjusting the dependency as I suggested above?21:25
robruslangasek: if getPublishedBinaries is reporting more binaries than there should be, then it's a bug in lp.21:26
slangasekrobru: ah, you didn't say you were checking getPublishedBinaries, which *is* the correct check AFAIK21:26
jbichaslangasek: because they actually changed the code to gpg1 https://launchpadlibrarian.net/279890088/python-gnupg_0.3.8-2_0.3.8-3.diff.gz21:27
robruslangasek: ah yes, I said "builds" by mistake, I meant binaries.21:27
slangasekjbicha: that sounds like a good reason21:27
robruslangasek: maybe you deleted binaries for some binary packages but not all binary packages produced by that source?21:28
slangasekrobru: the only ones I didn't delete were the architecture: all ones; I suppose that could be the issue, let me see21:28
slangasekrobru: (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:30
robruslangasek: hm, shouldn't be arch: all, it does specifically filter out binaries that are architecture_specific=False21:31
slangasekthen it may simply be that as of the last status job run, LP was still catching up21:31
jbichasakrecoer: done, so we'll just have to retry the iso build tomorrow once germinate has picked up the change21:34
robruslangasek: I'm gonna head out for lunch, will follow up later21:34
sakrecoerjbicha: you rock! thanks!!! :)21:38
sakrecoeri'm signing off, read you tomorrow! o/21:39
jbichasakrecoer: for reference, I used https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.yakkety/all21:43
renatuslangasek, robru, The silo was ok some time ago. But it change to failed recently21:48
renatuslangasek, it was ok when you told me that you had deleted the package. But then after I mark it as approved it changed to fail21:49
renatuI am not sure if is related with the fact that I marked it as approved21:49
robrurenatu: no, marking it as approved won't make it start considering more architectures22:38
robruslangasek: this is what bileto is seeing in lplib: http://paste.ubuntu.com/23079883/22:47
slangasekrobru: heh; then perhaps that's a britney bug, because those are the same binaries I removed from yakkety-proposed22:49
slangasekrobru: so, removing them again :)22:49
robruslangasek: thanks22:50
flocculantslangasek: 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 161584722:54
ubot5bug 1615847 in ubiquity (Ubuntu) "Ubiquity crashes with non english setup" [Undecided,New] https://launchpad.net/bugs/161584722:54
flocculanthesitating to set bugs as dupes, but journal errors seem to be the same23:02
slangasek"could not convert string to float" lol ok23:06
flocculantslangasek: I gave up trying to write the description with a french layout and opted for editing it afterwards:)23:13
flocculantanyway - thanks for looking there23:13
* flocculant wanders off again23:13

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!