=== maclin1 is now known as maclin [02:00] Hey, fancy release team members! [02:01] I'd quite like to get mesa out of artful-proposed! [02:01] It's blocked by glbindings hitting new and exciting gcc warnings on armhf, thouh. [02:02] Those warnings aren't in mesa-adjacent code, though. glbindings is just broken. [03:40] RAOF: stderr output from the compiler due to C++, yeah, that's a pretty sure bet that it's not mesa's fault :) overriding [03:41] Ta muchly! [03:42] slangasek: want to help android-tools migrate out of -proposed? LP: #1699928 [03:42] Launchpad bug 1699928 in goget-ubuntu-touch (Ubuntu) "Please delete obsolete android binaries" [Undecided,New] https://launchpad.net/bugs/1699928 [03:47] jbicha: ubuntu-device-do / ubuntu-device-flash are not listed on update_excuses and they don't appear to be NBS; removing the binaries is not a correct solution here unless you also show that they won't come back on the next upload [03:50] ok [04:01] it doesn't build; maybe we should just remove it for all architectures :( [04:04] slangasek: are you interested in removing phablet-tools and goget-ubuntu-touch because it won't build? (no other rdeps) [04:11] goget builds on zesty but not yakkety [04:20] jbicha: those being client tools rather than part of the touch platform, I'd like a clearer statement from the project owners that they should be dropped [04:22] heh, "owners" [04:22] I got that backwards, it builds on yakkety but not zesty [05:12] -queuebot:#ubuntu-release- New binary: gflags [arm64] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop) [05:12] -queuebot:#ubuntu-release- New binary: gflags [ppc64el] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop) [05:13] -queuebot:#ubuntu-release- New binary: gflags [amd64] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop) [05:13] -queuebot:#ubuntu-release- New binary: gflags [i386] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop) [05:14] -queuebot:#ubuntu-release- New binary: gflags [s390x] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop) [05:14] -queuebot:#ubuntu-release- New binary: ntfs-3g [ppc64el] (artful-proposed/main) [1:2016.2.22AR.2-2] (core) [05:14] -queuebot:#ubuntu-release- New binary: ntfs-3g [i386] (artful-proposed/main) [1:2016.2.22AR.2-2] (core) [05:14] -queuebot:#ubuntu-release- New binary: gflags [armhf] (artful-proposed/main) [2.2.0-2] (kubuntu, ubuntu-desktop) [05:14] -queuebot:#ubuntu-release- New binary: ntfs-3g [s390x] (artful-proposed/main) [1:2016.2.22AR.2-2] (core) [05:15] -queuebot:#ubuntu-release- New binary: ntfs-3g [arm64] (artful-proposed/main) [1:2016.2.22AR.2-2] (core) [05:15] -queuebot:#ubuntu-release- New binary: ntfs-3g [armhf] (artful-proposed/main) [1:2016.2.22AR.2-2] (core) [05:16] -queuebot:#ubuntu-release- New binary: ntfs-3g [amd64] (artful-proposed/main) [1:2016.2.22AR.2-2] (core) [08:44] -queuebot:#ubuntu-release- New: accepted gflags [amd64] (artful-proposed) [2.2.0-2] [08:44] -queuebot:#ubuntu-release- New: accepted gflags [armhf] (artful-proposed) [2.2.0-2] [08:44] -queuebot:#ubuntu-release- New: accepted gflags [ppc64el] (artful-proposed) [2.2.0-2] [08:44] -queuebot:#ubuntu-release- New: accepted ntfs-3g [amd64] (artful-proposed) [1:2016.2.22AR.2-2] [08:44] -queuebot:#ubuntu-release- New: accepted gflags [arm64] (artful-proposed) [2.2.0-2] [08:44] -queuebot:#ubuntu-release- New: accepted gflags [s390x] (artful-proposed) [2.2.0-2] [08:44] -queuebot:#ubuntu-release- New: accepted gflags [i386] (artful-proposed) [2.2.0-2] [08:44] -queuebot:#ubuntu-release- New: accepted ntfs-3g [armhf] (artful-proposed) [1:2016.2.22AR.2-2] [08:45] -queuebot:#ubuntu-release- New: accepted ntfs-3g [arm64] (artful-proposed) [1:2016.2.22AR.2-2] [08:45] -queuebot:#ubuntu-release- New: accepted ntfs-3g [ppc64el] (artful-proposed) [1:2016.2.22AR.2-2] [08:45] -queuebot:#ubuntu-release- New: accepted ntfs-3g [i386] (artful-proposed) [1:2016.2.22AR.2-2] [08:45] -queuebot:#ubuntu-release- New: accepted ntfs-3g [s390x] (artful-proposed) [1:2016.2.22AR.2-2] === estan_ is now known as estan [10:16] -queuebot:#ubuntu-release- New binary: gce-compute-image-packages [i386] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud) [10:16] -queuebot:#ubuntu-release- New binary: gce-compute-image-packages [s390x] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud) [10:16] -queuebot:#ubuntu-release- New binary: gce-compute-image-packages [ppc64el] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud) [10:17] -queuebot:#ubuntu-release- New binary: gce-compute-image-packages [amd64] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud) [10:19] -queuebot:#ubuntu-release- New binary: gce-compute-image-packages [arm64] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud) [10:19] -queuebot:#ubuntu-release- New binary: gce-compute-image-packages [armhf] (artful-proposed/universe) [20170622-0ubuntu1] (ubuntu-cloud) [10:30] Hey! Anyone here could force ignore octave-io's failing armhf test? Checking the logs it's been failing for longer and from the logs (and one re-run) I see that random tests seem to be failing, not the same ones everytime [10:30] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#octave-io [10:41] sil2100: I bumped the existing hint [10:41] Laney: thank you! [10:53] Also, is there any AA on duty right now to take a look at the binNEW's for gce-compute-image-packages? [10:58] would someone please 'force-badtest sunpy/all/armhf' ? existing hint in a.p.w's file [11:01] . [11:01] Laney: thanks! [11:35] Any archive admins here who could take a look at LP: #1699333 and LP: #1699334 please? [11:35] Launchpad bug 1699333 in Ubuntu "[needs-packaging] vala-panel" [Wishlist,Confirmed] https://launchpad.net/bugs/1699333 [11:35] Launchpad bug 1699334 in Ubuntu "[needs-packaging] vala-panel-appmenu" [Wishlist,Confirmed] https://launchpad.net/bugs/1699334 [11:35] Laney? infinity? ^ [11:35] I'd really like to land those for 17.10 Alpha 1. [11:44] I can't, sorry === ahoneybun_ is now known as ahoneybun [12:54] flexiondotorg, what are you looking for on those, they arn't uploaded as far as i can see [12:54] are you looking for an aa or a sponsor ? [12:55] apw Yes, looking for an aa to upload them. [12:55] typically ones doesn't need an aa, for an upload one is looking for a coredev or motu sponsor [12:55] Then I can updated the Ubuntu MATE seeds. Then email the DMB so I can maintain them in the archive long term. [12:56] to look at accepting them you need a release-team memeber in artful [12:56] (being picky on terms as there are more of the other types than pure-aa's) [12:57] I'll ask in #ubuntu-motu [12:57] flexiondotorg: ask in #ubuntu-devel, the MOTU channel isn't as popular [13:18] apw: Accepting from the NEW queue is ~ubuntu-archive [13:18] although ~ubuntu-release can technically do that for the devel series ... [13:18] It's not really allowed :) [13:22] Laney, i thought that you could review them, and recommend, but likely so, i was more trying to get a wider view on sponsorship [13:38] slangasek: so can you proceed with #1700080 ? :) [13:38] we're getting near it… [13:38] probably [13:38] maybe [13:38] hopefully [13:53] also https://bugs.launchpad.net/ubuntu/+source/libkface/+bug/1699727 [13:53] Ubuntu bug 1699727 in libkface (Ubuntu) "Please remove libkface from artful - required for OpenCV 3.1 transition" [Undecided,New] [13:53] * acheronuk heads to find cold beer..... [14:26] Any archive admin around to take a look at the gce-compute-image-packages binNEWs? [14:29] sil2100, there are some worrying lintian warnings on those, particularly about the library naming [14:48] mapreri: done [14:49] ta [14:50] so, we are probably left with only one failing packages once the new opencv upload I just did builds and mrpt/armhf is retried. [14:52] slangasek: #1699727 too? [15:26] mapreri: also done [15:27] ta² [15:31] apw: it's some GCE internal thing so yeah, not perfect - what are the lintian warnings? [15:44] acheronuk, valorie: any plans on untangling the akonadi-contacts -> qtwebengine-opensource-src -> libv8-dev dependency chain? You can't rely on v8 being present across all Ubuntu archs, it's highly non-portable, so someone needs to decide what happens to this part of the Kubuntu stack where it's not available [15:58] slangasek: QtWebEngine and what now hard coded depends on it is just not going to be buildable outside amd64/i386 + armhf for now. So we are going to have to ask for some some deletions on architecture that although we did not officially support in kubuntu, did happne to build until now :(s [15:58] acheronuk: should I start deleting those now? [16:01] slangasek: can you wait so talk to santa? (https://launchpad.net/~panfaust) I doubt it would matter as most is pretty self obvious, but he has been leading on the Apps update (inc this PIM stuff) [16:03] acheronuk: do you expect him to be around on IRC, or do you suggest taking this to email/bug? [16:05] slangasek: I have just pinged him on telegram. Hopefully he will get on here soon. not quite sure why he does not have a IRC BNC, his internet in his home was very bad, but he will usually respond in shortish time (famous last words) [16:06] ok [16:06] slangasek: if you feel any urgency, then please post to kubuntu-devel mailing list as well [16:06] "urgency" and "email" are inversely correlated ;) [16:07] lol. I know, but at least it's just there when people care to check [16:10] evening santa :) [16:12] santa_: FYI http://paste.ubuntu.com/24933682/ [16:12] santa_: hi there. Should I start picking at the tree of binaries on {arm64,ppc64el,s390x} that are out-of-date because of lack of V8 and removing them? [16:13] actually, v8 is available on ppc64el but there was a build failure... so nevermind that part, I'll have a closer look first [16:14] hi [16:14] QtWebEngine can only be built for x86, x86-64, ARM, Aarch64, MIPSel, and MIPS64 architectures. [16:14] there we go, sounds like fair game to remove that right now also due to lack of upstream support [16:14] slangasek: QtWebEngine explicitly states it will not build for ppc64el [16:14] (but upstream may want to revisit that) [16:15] or it did last time I looked a a log [16:15] they may, but seem in no hurry [16:17] slangasek: indeed we have several things which are not going to build for some architectures because of libv8 and QtWebengine. so go ahead with the removals please [16:17] ok [16:17] it'll take a while to hunt them all, but I'll make a start and see if we can't clean up update_excuses [16:18] -queuebot:#ubuntu-release- New binary: htslib [s390x] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset) [16:18] we also have the akonadi autopkgtest failure [16:18] I overrode it (but wasn't happy about it) [16:18] -queuebot:#ubuntu-release- New binary: htslib [i386] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset) [16:19] -queuebot:#ubuntu-release- New binary: htslib [armhf] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset) [16:19] -queuebot:#ubuntu-release- New binary: htslib [ppc64el] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset) [16:20] -queuebot:#ubuntu-release- New binary: htslib [amd64] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset) [16:20] -queuebot:#ubuntu-release- New binary: htslib [arm64] (artful-proposed/universe) [1.4.1-2ubuntu1] (no packageset) [16:21] slangasek: thank you, please just keep in mind that autotests for kde are extremely tricky to set up, even if there's asbsolutely no upstream issues in the code tested. also note that we have been working very, very, very, very hard to try to keep them in shape [16:22] in fact, today I have spent all night trying to use the qemu backend instead of schroot for the stuff I have to check the autopkgtests in advance [16:23] also note that in all the time I have been fixing autopkgtest (and I fixed dozens and dozens of them) I still didn't find find any actual upstream code issue [16:24] I understand. I'm not saying these things are easy to manage, but I do think it's better to disable tests in source, or wrap them to pass even if there are errors, than to have constantly-failing tests [16:24] yeah, that's what I'm working on [16:26] one problem I have with akonadi is that it fails in different ways in schroot, lxc and the ubuntu official infra [16:27] so I'm working right now on trying to swtich my invention from schroot to qemu [16:27] * switch [16:28] * slangasek nods [18:26] -queuebot:#ubuntu-release- Unapproved: kexec-tools (yakkety-proposed/main) [1:2.0.10-2ubuntu1.2 => 1:2.0.10-2ubuntu1.3] (core) [18:55] good news, everyone! a bunch more kde packages can now have their autopkgtests run [19:01] slangasek: we added some comments to LP: #1699928 for you [19:01] Launchpad bug 1699928 in phablet-tools (Ubuntu) "Please delete obsolete android binaries" [Undecided,New] https://launchpad.net/bugs/1699928 [19:43] -queuebot:#ubuntu-release- Unapproved: shim-signed (zesty-proposed/main) [1.28 => 1.30~17.04.1] (core) [19:46] slangasek: I think you mistyped your nick; sfarnsworth ;) [19:46] -queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.28~16.10.1 => 1.30~16.10.1] (core) [19:46] -queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.28~16.04.1 => 1.30~16.04.1] (core) [19:49] -queuebot:#ubuntu-release- Unapproved: shim-signed (trusty-proposed/main) [1.19~14.04.1 => 1.30~14.04.1] (core) [20:32] slangasek, https://launchpad.net/ubuntu/+source/ocaml/4.02.3-9ubuntu3 looks futile effort to me, due to patch that passes -fPIC to the build and thus it results in just being PIC, rather than PIE, no?! [20:32] https://launchpadlibrarian.net/322273615/buildlog_ubuntu-artful-amd64.ocaml_4.02.3-9ubuntu3_BUILDING.txt.gz Ctrl+f PIC [20:32] (thanks to the ubuntu-only patch from doko) [20:32] should ocaml be PIE, or PIC? [20:32] (on all arches) [20:37] xnox: AFAIK, PIE and PIC are only materially different when you're linking an executable; which bit do you see that's problematic? [20:43] slangasek, the bit i see problematic is that the patch lacks description (either inside, or in the name) and the debian changelog entry are useless. [20:43] instead of stating why something is changed, it simply states what has been changed. [20:44] And it is not obvious why. [20:44] -Wl,--no-relax linker flag added, and -fPIC enabled, but on amd64 only. [20:44] xnox: ah. well, I believe that was on rbalint's list of packages to rebuild [20:45] rebuilding stock debian experimental release on ubuntu, succeeds the build on all arches and at least the build time test suite passes. [20:45] which means he tested that rebuilding it made a difference [20:45] slangasek, i'm not questioning your rebuild alone; i'm questioning why we have the delta at all. [20:45] but the -fPIC patch is perhaps superfluous now that the compiler default has changed [20:45] that's what i'm thinking, but i'm not sure. [20:45] also no idea what -Wl,--no-relax does [20:46] and why that is _removed_ [20:47] i'll email doko [21:32] xnox,slangasek: yes, ocaml was on the PIE rebuild list because as far as i remember lwt failed to build on arm64 artful without PIE-d ocaml [21:33] like it did fail to build on Debian as well when i tested the PIE rebuild #837669 [21:34] i don't have the failing log because i have an the email saying that build failed but the linked log seems to be replaced with a successful run [21:34] by launchpad [21:36] rbalint, yes there is only one build-log per upload per arch. [21:41] xnox: when i tested ocaml build it picked static libs from _system's_ ocaml #837359, thus converting to PIE looks like 1. enable PIC, 2. rebuild with PIE, 3. (optional) drop PIC [21:42] xnox: so regarding your question of PIE/PIC ocaml IMO PIC can be dropped now again [21:52] i think we are at step 2, everywhere now, but i'm not sure. Will double check. E.g. see https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages?field.name_filter=ocaml&field.status_filter=published&field.series_filter=artful [22:03] -queuebot:#ubuntu-release- Unapproved: libepoxy (zesty-proposed/main) [1.3.1-1ubuntu1.17.04.1 => 1.3.1-1ubuntu1.17.04.2] (desktop-core) [22:03] -queuebot:#ubuntu-release- Unapproved: libepoxy (xenial-proposed/main) [1.3.1-1ubuntu0.16.04.1 => 1.3.1-1ubuntu0.16.04.2] (desktop-core) [22:48] -queuebot:#ubuntu-release- Unapproved: kexec-tools (xenial-proposed/main) [1:2.0.10-1ubuntu2.2 => 1:2.0.10-1ubuntu2.3] (core) [23:04] Laney: do you happen to know if there's a limit on the number of triggers that can be specified? Because I keep trying to run 'run-autopkgtest -s artful -a i386 --trigger kf5-messagelib/4:16.12.3-0ubuntu1 --trigger kf5-kdepim-apps-libs/4:16.12.3-0ubuntu1 --trigger libkf5gravatar/4:16.12.3-0ubuntu1 --trigger libkf5pimcommon/4:16.12.3-0ubuntu1 --trigger sonnet/5.35.0-0ubuntu2 --trigger [23:04] akonadi-contacts/4:16.12.3-0ubuntu1 --trigger akonadi-mime/4:16.12.3-0ubuntu1 --trigger akonadi-notes/4:16.12.3-0ubuntu1 --trigger akonadi/4:16.12.3-0ubuntu1 --trigger akonadi-search/4:16.12.3-0ubuntu1 --trigger kmailtransport/16.12.3-0ubuntu1 --trigger libkf5grantleetheme/16.12.3-0ubuntu1 --trigger libkf5libkleo/4:16.12.3-0ubuntu1 --trigger libkf5pimcommon/4:16.12.3-0ubuntu1 kf5-messagelib' and [23:04] I see it land in the queue, then disappear again [23:04] Laney: btw I don't seem to be receiving any of the nuisance emails you said you set up for me [23:05] o.O at some point you should probably give up and use all-proposed :) [23:05] except I'm not sure that registers as a result for the packages in question [23:06] oh, in that command there is no actual package to test? they are all --trigger [23:07] kf5-messagelib [23:07] ok, newline [23:07] if I split the list in half, it goes :P [23:08] in my (short) experience I saw stuff scheduled with all-proposed being correctly recognized as a result for the tested package, and have that test make britney happy about the triggers [23:08] it's not about it being a result for the /tested/ package [23:08] it's about having it be a result for all the other packages listed in triggers [23:09] yeah, you'd need a separate run for each of them, then? [23:09] as you're doing, i mean [23:10] it's not meant to be a run for each of them. I want a single run, with all these packages from -proposed, that's credited to all the packages in the list [23:10] slangasek: actually, no matter what, wouldn't it only show up in the tested package's results? [23:10] because this is a KDE transition and I don't actually need the test suite to run 14 times [23:10] slangasek: right, i get that [23:10] nacc: it shows up in the results of each of the packages listed as --trigger [23:11] slangasek: oh interesting, I guess I didn't realize that, but it makes sense [23:11] but if I don't list the triggers, I don't think autopkgtest is smart enough to credit the passing result for every package that happened to be pulled from -proposed with --all-proposed [23:11] slangasek: yeah, I don't think it does either [23:11] slangasek: and i (honestly) thought it didn't in general until you just TIL'd me [23:12] (same) [23:14] ok, I can confirm now that I have the tests running that I want, having split the trigger lists. What I don't know is why they didn't go before [23:14] or if I'll actually get results back :P [23:14] slangasek: heh [23:21] http://autopkgtest.ubuntu.com/running#pkg-kf5-messagelib [23:21] fun [23:21] completely blank output from the runners?