[00:42] -queuebot:#ubuntu-release- New sync: tldextract (bionic-proposed/primary) [2.2.0-1]
[00:53] <tsimonq2> slangasek: Thanks!
[01:15] -queuebot:#ubuntu-release- New binary: kproperty [s390x] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:16] -queuebot:#ubuntu-release- New binary: kproperty [amd64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:16] -queuebot:#ubuntu-release- New binary: kproperty [ppc64el] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:17] -queuebot:#ubuntu-release- New binary: kdb [s390x] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:18] -queuebot:#ubuntu-release- New binary: kdb [ppc64el] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:18] -queuebot:#ubuntu-release- New binary: kproperty [i386] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:19] -queuebot:#ubuntu-release- New binary: kproperty [arm64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:19] -queuebot:#ubuntu-release- New binary: kproperty [armhf] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:19] -queuebot:#ubuntu-release- New binary: kdb [amd64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:20] -queuebot:#ubuntu-release- New binary: kdb [i386] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:20] -queuebot:#ubuntu-release- New binary: kdb [arm64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[01:21] -queuebot:#ubuntu-release- New binary: kdb [armhf] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[04:09] <slangasek> ginggs: I'm not sure precisely what changed or why we're getting different behavior on Ubuntu than on Debian, but we did recently update the autopkgtest branch on the infra to a more recent version
[04:11] -queuebot:#ubuntu-release- New: accepted kdb [amd64] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kdb [armhf] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kdb [ppc64el] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kproperty [amd64] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kproperty [armhf] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kproperty [ppc64el] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kdb [arm64] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kdb [s390x] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kproperty [i386] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kdb [i386] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kproperty [s390x] (bionic-proposed) [3.1.0-2]
[04:11] -queuebot:#ubuntu-release- New: accepted kproperty [arm64] (bionic-proposed) [3.1.0-2]
[05:12] <slangasek> tsimonq2: I suspect the wrong use of -proposed might be a regression in autopkgtest upstream not setting the correct pins
[05:13] <slangasek> tsimonq2: or our branch of it, whichever is currently deployed; checking now
[05:13] <tsimonq2> slangasek: ack, lmk
[05:15] <slangasek> yeah, I think the upstream fix for the APT::Default-Release problem does not DTRT
[05:15] <slangasek> juliank: 'Pin: release bionic'... does that only match bionic release pocket?
[05:21] <slangasek> yeah, this pin is too broad
[05:26] <slangasek> Laney, elbrus: ^^ the 'release foo' pin also matches foo-proposed in Ubuntu, which means we've incorrectly been doing the equivalent of --all-proposed for all tests... patching in another temporary workaround
[05:45] <fossfreedom> hi - I'm a bit lost (actually very) why "postfix" mail server is being pulled into our Ubuntu Budgie iso - can someone help decipher this please (assuming I'm looking at the right area) http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-budgie.bionic/all
[05:46] <slangasek> fossfreedom: usually makes sense to look at those specific seeds that are part of the image, rather than 'all'
[05:47] <fossfreedom> k - is that the "desktop.seed" ?
[05:48] <slangasek> fossfreedom: so if I look at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-budgie.bionic/desktop I find it being pulled in by liblockfile1 -> bsd-mailx -> default-mta
[05:48] <slangasek> this seems to be a change in liblockfile1 which previously did not depend on bsd-mailx
[05:49] <slangasek> and should probably be fixed to again not do so
[05:51] <slangasek> that seems to be an unexpected side effect of a Debian NMU
[05:51] <slangasek> oh no, sorry, I was reading that the wrong way around
[05:52] <slangasek> bsd-mailx depends liblockfile1, liblockfile1 doesn't depend bsd-mailx :P
[05:52] <slangasek> so it's smartmontools -> bsd-mailx -> postfix
[05:53] <slangasek> fossfreedom: so, why do you install smartmontools?  No other desktop flavor does
[05:53] <fossfreedom> we do?
[05:55] <slangasek> apparently it's tlp -> smartmontools
[05:55] <fossfreedom> ah - tlp is something we have always pulled in
[05:56] <fossfreedom> but I dont ever remember postfix being pulled in as well...
[05:57] <slangasek> so I guess you'd perhaps like tlp to not pull in smartmontools
[05:57] <slangasek> fossfreedom: well, it was the case already in artful
[05:59] <fossfreedom> hmm - wonder why mailx is a recommends on smartmontools - seems like an odd recommeds
[06:02] <slangasek> because it wants to deliver reporting via email
[06:03] <acheronuk> slangasek: seems someone synced kproperty and kdb 3.1, but not the other build dep kreport for kexi 3.1, or kexi 3.1 itself. so those new versions won't get out of proposed. kexi suite is leaf stuff for kde, so could we have permission to complete syncing those packages, assuming the original sync'r (jbicha) is not intending to or does not have a FFe in place?
[06:07] <fossfreedom> slangasek, ah - ok.  Thenn yes, I guess tlp shouldnt have that recommendation ... but looking back even xenial had it as well.
[06:09] <slangasek> acheronuk: that sounds ok, provided you do due diligence on what's being pulled in that it's not going to have further knock-on effects
[06:09] <slangasek> acheronuk: (which it sounds like you may have already done)
[06:12] <acheronuk> slangasek: yeah. I will check it fully again before I push any buttons. thanks
[06:22] <infinity> To be clear, nothing "changed".  tlp and postfix were both in ubuntu-budgie-desktop in artful.
[06:22] <infinity> It's just that someone finally noticed.
[06:22] <infinity> slangasek, acheronuk, fossfreedom ^
[06:22] <infinity> (artful-amd64)root@nosferatu:/home/adconrad# apt-cache show postfix | grep ^Task
[06:22] <infinity> Task: mail-server, ubuntu-budgie-desktop
[06:23] <infinity> Oh, maybe acheronuk wasn't involved in that discussion.  Well, the other two were. :P
[06:24]  * acheronuk was not
[06:44] <slangasek> jbicha: gnucash FFe> since I use the package I was going to kick the tires on it before acking, and it FTBFS from me locally.  Does it work for you?
[06:53] <fossfreedom> infinity, would you be ok if I made a debdiff to downgrade smartmontools from recommends to suggests for TLP to resolve the postfix inclusion?
[07:04] <juliank> slangasek: oh they all have Codename: bionic. Yeah they match all of them, then.
[07:26] <slangasek> juliank: any further thoughts on a pin that might DTRT everywhere?  Or should we just detect Ubuntu?
[07:28] <juliank> I don't think there is any pin that works everywhere
[07:29] <juliank> Basically we want to pin bionic, bionic-updates, and bionic-security, right? (which only really becomes important once it's a stable release)
[07:36] <infinity> slangasek, juliank: What are we trying to pin?
[07:37] <infinity> "Pin: release a=<suite>" gets you just suites.
[07:37] <infinity> If you're after telling bionic, bionic-updates, etc apart.
[07:38] <infinity> We use that in buildds chroots to force backports from NoInstallAuto back to normal.
[07:38] <infinity> Package: *
[07:38] <infinity> Pin: release a=*-backports
[07:38] <infinity> Pin-Priority: 500
[07:39] <infinity> (PS: it also takes wildcards, which proved handy for lazy me)
[07:39] <juliank> Its about autopkgtests
[07:39] <infinity> juliank: I figured that, I couldn't find context to decide what the desired outcome was, that's all.
[07:39] <apw> so about trying to pin a!=*-proposed ?
[07:40] <infinity> juliank: But "they're all bionic" is solved by "use a="
[07:40] <infinity> apw: That's not how pins work. :)
[07:40] <infinity> But if you don't want proposed, you can pin it negative.
[07:40] <juliank> i think we want to pin release bionic to 990, and override bionic-proposed
[07:40] <apw> infinity, i am sure not :)  i was trying to find out what he wants :)
[07:41] <juliank> So when testing for stable we test against updates?
[07:41] <infinity> juliank: Testing proposed tests against release+updates.
[07:41] <infinity> juliank: If we ever got around to testing security, it would be release+security
[07:42] <infinity> juliank: And there's no reason this logic needs to differ between stable and devel, since devel always has those pockets (but they're empty).
[07:42] <juliank> Yeah
[07:43] <infinity> And in the rare cases where those pockets aren't empty in devel (like when I do weird things during release week), testing in the "stable way" would be correct anyway.
[07:44] <infinity> I'm confused how this came up, though.  I thought pitti and I sorted all the pinning stuff eons ago.
[07:44] <infinity> Unless someone broke it.
[07:45] <juliank> infinity: Debian set apt::Default-Release config option recently
[07:45] <infinity> Note that it pins in such a way as to not *exclude* proposed, in case deps need to get pulled in.
[07:46] <infinity> juliank: Right, that's not going to work for us, cause we use partial suites, not releases.
[07:46] <infinity> But the way we've been doing it for the last couple of years works, no?
[07:50] <juliank> I'd think so
[07:53] <infinity> https://salsa.debian.org/ci-team/autopkgtest/commit/7130136a49a2c055d19782f84dba6ea2b27c7006
[07:53] <infinity> I see a fine mix of "release fluffy" and "release a=fluffy.."
[07:53] <infinity> Make them all a=, and it's probably happy.
[07:53] <infinity> Though, that's just looking at a commit, not the existing code.
[07:56] <infinity> Ahh, but here's where the working logic was torn out:
[07:56] <infinity> https://salsa.debian.org/ci-team/autopkgtest/commit/8ef72c014cf29c1fe3fb72e1ac8c09aa16dadf65
[07:56] <infinity> So making the new code match behaviour should be easy enough.
[07:57] <infinity> juliank: I'm supposedly not here, so I'll go away now, but if you need eyeballs, poke me.
[07:57] <infinity> juliank: Making the new function produce an identical (except for exact numbers, I guess) output to the original should be both easy and testable, though.
[07:58] <infinity> It's pretty clear that Paul just didn't really grok how we use this.
[07:59] <infinity> (or maybe how Ubuntu suites work)
[08:02] <doko> apw: could you have a look at linux-gcp? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/armhf/l/linux-gcp/20180326_074742_bb201@/log.gz
[08:06] <tsimonq2> infinity, slangasek: I'm Not Here but could I please get node-define-property demoted to bionic-proposed? Debian bug 892656,
[08:06] <ubot5> Debian bug 892656 in src:node-define-property "node-define-property: FTBFS and Debci failure" [Serious,Open] http://bugs.debian.org/892656
[08:06] <tsimonq2> https://launchpad.net/~tsimonq2/+archive/ubuntu/upload-testing/+sourcepub/8878227/+listing-archive-extra : it's FTBFS no-change rebuilding against only packages in release, and its failing autopkgtests are blocking nodejs' migration.
[08:09] <tsimonq2> Nevermind.
[08:09] <tsimonq2> Not yet.
[08:10] <apw> doko, damn debhelper and it checking things are correct
[08:10]  * tsimonq2 botched the whole "test it's FTBFS in release" by not remembering that I copy-package'd nodejs from proposed to do other testing...
[08:24] <doko> apw: feel free to override it so gdb can migrate
[08:26] <apw> doko, i am slighly confused how on earth it ever actaully built, given it no longer does, but hey
[08:27] <apw> doko, oh, i see, britney is testing it on arches it doesn't build on, nice
[08:29] <apw> doko, sorted
[08:35] <LocutusOfBorg> hello, please remove this *source* package
[08:35] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/msgpack-python
[08:35] <LocutusOfBorg> it has been superseeded by python-msgpack, providing the same binaries, but different source package name
[08:40] <apw> LocutusOfBorg, looking
[08:42] <LocutusOfBorg> thanks! I don't know how much it is worth the effort, but having a clean archive is nice :)
[08:42] <apw> always worth the effort
[08:42] <LocutusOfBorg> nice :)
[08:42] <LocutusOfBorg> I requested on #debian-devel the same for debian
[09:17] <ginggs> apw: src:libthrust can be removed for a similar reason, debian bug #892808
[09:17] <ubot5> Debian bug 892808 in src:libthrust "src:libthrust: cuda toolkit ships a newer version" [Serious,Open] http://bugs.debian.org/892808
[09:22] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-themes [sync] (xenial-proposed) [14.04+16.04.20180307-0ubuntu1]
[09:46] <LocutusOfBorg> hello doko, did you find the gcc-8 issue? (static libraries without fPIC), preventing meson from building
[09:47] <LocutusOfBorg> I can confirm, fPIC is not there libtool: compile:  /<<PKGBUILDDIR>>/build/./gcc/gdc -B/<<PKGBUILDDIR>>/build/./gcc/ -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include -isystem /<<PKGBUILDDIR>>/build/sys-include -O2 -g -nostdinc -pipe -Wno-deprecated -I ../../../../src/libphobos/libdruntime -I . -c ../../../../src/libphobos/libdruntime/rt
[09:47] <LocutusOfBorg> /sections_elf_shared.d -o rt/sections_elf_shared.o >/dev/null 2>&1
[09:47] <LocutusOfBorg> btw, I don't understand why files for static library are put in rt/foo.o and the same files are rebuilt for the dynamic version, in .libs/foo.o
[09:48] -queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.5.10-0ubuntu1]
[10:08] <LocutusOfBorg> apw, maybe I didn't wait long enough, but you deleted the old msgpack-python from universe and not from main? https://launchpad.net/ubuntu/+source/msgpack-python/+publishinghistory
[10:13] <LocutusOfBorg> apw, maybe I didn't wait long enough, but you deleted the old msgpack-python from universe and not from main? https://launchpad.net/ubuntu/+source/msgpack-python/+publishinghistory
[10:19] -queuebot:#ubuntu-release- New: accepted tldextract [sync] (bionic-proposed) [2.2.0-1]
[10:23] -queuebot:#ubuntu-release- New binary: tldextract [amd64] (bionic-proposed/none) [2.2.0-1] (no packageset)
[10:23] -queuebot:#ubuntu-release- New: accepted tldextract [amd64] (bionic-proposed) [2.2.0-1]
[10:31] <Laney> juliank: are you looking into that autopkgtest bug?
[10:36] <juliank> Laney: No, I'm doing other stuff, but I can advise on apt parts
[10:38] <Laney> ok :/
[10:38] -queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (xenial-proposed) [2.8.0-1ubuntu1~16.04.5]
[10:38] <Laney> might want to wait until e_lbrus is back then, he mentioned in here that he was away this week
[10:40] -queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [sync] (trusty-release) [176.0.0-0ubuntu1~14.04.0]
[10:40] <Laney> I'll file it, looks like nobody else did
[10:46] <ginggs> Laney: where can I see the source for the "live" autopkgtest? I want to check if we got https://salsa.debian.org/ci-team/autopkgtest/commit/702c31af9e65e71f837703e9a651acfbd62ad471
[10:50] <Laney> ginggs: You can see the commit at the top of any log.gz.
[10:53] <xnox> LocutusOfBorg, ruby-defaults.... it's literarly just an update to the Vcs URL =/
[10:53] <xnox> LocutusOfBorg, just think about all the CO2 emissions that running all the autopkgtests is causing to boil the planet
[10:53] <ginggs> Laney: ok, i see "git checkout: 7130136 Use apt pinning instead of APT::Default-Release" but from which repo is that?
[10:54] <xnox> LocutusOfBorg, 1,000+ of VMs are spinned up, because of an URL update =(
[10:55] <Laney> ginggs: That commit is upstream, but the repository in use is https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/development/+ref/master .
[10:57] <ginggs> Laney: thanks!
[10:59] <ginggs> something broke a bunch of node autopkgtests recently; node-mapnik, node-ansi, node-archy
[11:03] <LocutusOfBorg> xnox, queues were empty, and my debcheckout is happier, moreover autosync will happen again...
[11:04] <LocutusOfBorg> I know and understand your point, I was really worried when pressing yes :(
[11:06] <xnox> LocutusOfBorg, seriously, we are post featurefreeze, and the update to url does not warrant that sync at all. please do not sync any changes, which are metadata only of urls / standards version, things that do not affect binary packges what's so ever.
[11:06] <xnox> LocutusOfBorg, it can wait 6 weeks, until we open the flood gates again.
[11:10] -queuebot:#ubuntu-release- New binary: kreport [s390x] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[11:10] -queuebot:#ubuntu-release- New binary: kreport [ppc64el] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[11:14] -queuebot:#ubuntu-release- New binary: kreport [amd64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[11:14] -queuebot:#ubuntu-release- New binary: kreport [i386] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[11:20] -queuebot:#ubuntu-release- New binary: kreport [arm64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[11:23] -queuebot:#ubuntu-release- New binary: kreport [armhf] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
[11:43] -queuebot:#ubuntu-release- New binary: lexicon [amd64] (bionic-proposed/universe) [2.1.21-1] (no packageset)
[12:10] -queuebot:#ubuntu-release- Unapproved: ubuntu-themes (xenial-proposed/main) [14.04+16.04.20171116-0ubuntu1 => 14.04+16.04.20180326-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
[12:38] <Laney> ginggs: Stop doing the weird quoting stuff in d/tests/control, it's not needed in recent autopkgtest (5.2)
[12:39] <Laney> and once https://salsa.debian.org/ci-team/autodep8/merge_requests/2/diffs is fixed, you can drop that kind of test altogether and use the generated one
[12:44] <ahasenack> Laney: hi, good morning/afternoon, did you get anything interesting out of those gvfs ppc64el autopkgtest runs from last week?
[12:44] <ginggs> Laney: sounds good - last week e.lbrus asked me about sync-ing autokpgtest 5.2 from debian, but I only saw the message yesterday
[12:45] <Laney> ginggs: doesn't really matter for autopkgtest.u.c, we use it from git there
[12:47] <ginggs> Laney: understood, but for the package in the archive?
[12:47] <Laney> sorry, don't understand the question
[12:47] <Laney> I don't mind if you want to sync if it's that
[12:48] <ginggs> Laney: that was it
[13:16] -queuebot:#ubuntu-release- New: accepted kreport [amd64] (bionic-proposed) [3.1.0-2]
[13:16] -queuebot:#ubuntu-release- New: accepted kreport [armhf] (bionic-proposed) [3.1.0-2]
[13:16] -queuebot:#ubuntu-release- New: accepted kreport [ppc64el] (bionic-proposed) [3.1.0-2]
[13:16] -queuebot:#ubuntu-release- New: accepted lexicon [amd64] (bionic-proposed) [2.1.21-1]
[13:16] -queuebot:#ubuntu-release- New: accepted kreport [arm64] (bionic-proposed) [3.1.0-2]
[13:16] -queuebot:#ubuntu-release- New: accepted kreport [s390x] (bionic-proposed) [3.1.0-2]
[13:16] -queuebot:#ubuntu-release- New: accepted kreport [i386] (bionic-proposed) [3.1.0-2]
[13:17] <smoser> hi, could  someone take a look at my grub-legacy-ec2 upload (new queue) . it is stripped out of cloud-init source into its own package. see bug 1758420
[13:17] <ubot5> bug 1758420 in cloud-init (Ubuntu) "separate grub-legacy-ec2 from cloud-init" [Medium,In progress] https://launchpad.net/bugs/1758420
[14:01] <juliank> "adequate" autopkgtest is broken (I retriggered that with hello, and it failed same way; probably some ldd change)
[14:07] <apw> smoser, is there any reason we cannot just call this 20 or something to avoid an epoch for the rest of time ?
[14:08] <smoser> slangasek suggested the epoch.
[14:09] <apw> smoser, ok, then i guess it is ok, /me hates them
[14:09] <apw> smoser, what are we gaining by splitting this out ?
[14:10] <smoser> smoser>      you have a suggestion for a version?
[14:10] <smoser> slangasek>   smoser: 1:1+mariadb10.1
[14:10] <smoser>  * slangasek amuses himself far too much with his own joke
[14:10] <smoser> slangasek>   smoser: I think an epoch is genuinely reasonable here
[14:10] <smoser> apw: its described in the bug some. it has basically no relation to cloud-init.
[14:10]  * rbasak 's ears perk up
[14:10] <rbasak> mariadb?
[14:11] <rbasak> Oh.
[14:11] <rbasak> :)
[14:11] <apw> smoser, and as it is included in the said cloud-init, presumably this needs some breaks action
[14:11] <smoser> apw: well it owuldnt htough, would it?
[14:12] <smoser> it was a binary package built by cloud-init source
[14:12] <smoser> and now its a binary package built by its own source
[14:12]  * apw has a sense of dejavue, i think i say this every time
[14:12] <smoser> so it definitely does conflict with itself
[14:12] <apw> so as long as cloud-init doesn't ever upload it again you are ok
[14:12] <smoser> and with the binary package produced from cloud-init source
[14:13] <smoser> the same is true though for cloud-init deciding to have a package named 'grep' , right ?
[14:13] <smoser> and grep doesnt have a breaks on cloud-init.
[14:13] <apw> it is ok because this entire package it taken over
[14:14] <smoser> right.
[14:14] <apw> well if you added a package to cloud-init called grep i suspect i'd get to reject it
[14:14] <smoser> that would be fun. :)
[14:15] <apw> and this is only directly seeded right ?
[14:15] <smoser> but the same process that stops me from doing that for 'grep' will subsequently stop me from doing it for 'grub-legacy-ec2'
[14:15] <smoser> yes.
[14:15] <smoser> one other quote from slangasek:
[14:15] <apw> right, your cloud-init would fail to upload at the binary stage i guess, so you get to lose
[14:15] <smoser> slangasek   smoser: ordering> new grub-legacy-ec2 source should be uploaded, accepted, and migrate to release pocket before being dropped from cloud-init source (because an unsatisfiable recommends will not stop proposed-migration from updating a package)
[14:16] <apw> ack
[14:17] <smoser> apw: thank you for your help.
[14:31] <LocutusOfBorg> apw, I'm not sure you really fixed msgpack :p
[14:32] <LocutusOfBorg> now I see the new package both in proposed and release at the same time...
[14:32] <LocutusOfBorg>  python-msgpack | 0.5.4-0ubuntu2 | bionic          | source, amd64, arm64, armhf, i386, ppc64el, s390x
[14:32] <LocutusOfBorg>  python-msgpack | 0.5.4-0ubuntu2 | bionic-proposed | source
[14:32] <LocutusOfBorg>  msgpack-python | 0.5.4-0ubuntu1 | bionic           | source
[14:32] <apw> LocutusOfBorg, indeed, and yet here is the command in my history
[14:32] <apw> maybe i forgot to say yes or something dump
[14:33] <LocutusOfBorg> I see msgpack-python removed from universe, not from main... maybe this is the reason?
[14:34] <apw> i did change overrides on python-msgpack at the same time, but they shouldn't overlap as that command is versioned
[14:34] <apw> anyhow, i've applied the axe to its neck again, lets see what falls out
[14:38] <LocutusOfBorg> the msgpack-python is now gone
[14:38] <LocutusOfBorg> I'm tempted to no-change rebuild python-msgpack to make britney happy if it doesn't autoheal in the next hour or so, what do you think?
[14:39] <apw> britney is likely to auto-heal
[14:39] <apw> but why is it unhappy in the first placce
[14:41] <LocutusOfBorg> I honestly don't think it will auto-heal, because removing the old package should have no effect on the new one...
[14:41] <apw> LocutusOfBorg, i don't see it even in britney's view ... it is already in -release
[14:41] <LocutusOfBorg> rmadison and web has a different pov
[14:41] <LocutusOfBorg> 	proposed, release (main)	5 hours ago
[14:41] <apw> its not cleared from -proposed completly indeed, but it is promoted
[14:41] <LocutusOfBorg> it is at the same time on both places, this is why I don't think britney will change the situation
[14:42] <apw> yeah likely britney was moving it just as i changed its overrides, or something
[14:42] <apw> it is however fully promoted, there is just some archive sadness
[14:42] <apw> which can be repaired whenever
[14:43] <apw>  python-msgpack | 0.5.4-0ubuntu2 | bionic          | source, amd64, arm64, armhf, i386, ppc64el, s390x
[14:43] <apw> LocutusOfBorg, you see that at least right?  so everything is out in -release
[14:43] <LocutusOfBorg> yes
[14:43] <LocutusOfBorg> just the source is around in proposed
[14:43] <cjwatson> a no-change rebuild is a silly solution to that :)
[14:43] <apw> and that would have been the only thing which was being overrideen, so classic overrides racy fun
[14:43] <LocutusOfBorg> I think I got it, when you promote, did you promote the stuff in proposed?
[14:44] <apw> i see no reason i cannot just remove the source from -proposed and be happy
[14:44] <cjwatson> https://launchpad.net/ubuntu/+source/python-msgpack/+publishinghistory gives a much clearer view than the main DSP page
[14:44] <cjwatson> apw: you can
[14:44] <LocutusOfBorg> yes cjwatson this is what I proposed above, unless there is a bug somewhere
[14:44] <cjwatson> LocutusOfBorg: I'm saying it's a silly solution *so don't do it* :P
[14:44] <apw> cjwatson, and i am sure it was my change-overrides to promte the source which triggered it to remain
[14:44] <cjwatson> apw: I doubt it.  There are some races
[14:44] <apw> it was about the right time, but hey, anyhow, removing
[14:44] <LocutusOfBorg> also abusing time of AAs might be a silly idea :)
[14:45] <cjwatson> removals aren't an abuse of time
[14:45] <apw> meh, archive scrubbing is a thing, a thing we do, its like floors when you own a dog
[14:45] <LocutusOfBorg> nice, now the situation is happy again thanks!
[14:46] <LocutusOfBorg> doko, my wild, quick, and dirty gcc patch, fixed meson build
[14:46] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
[14:46] <LocutusOfBorg> -+GDCFLAGS_FOR_TARGET = -O2 -g
[14:46] <LocutusOfBorg> ++GDCFLAGS_FOR_TARGET = -O2 -g -fPIC
[14:47] <LocutusOfBorg> so, really please add fPIC when building shared libraries, in a more sane than my patch hacking
[14:48] <cjwatson> it's not even clear to me what happened here, which is moderately impressive
[14:50] <LocutusOfBorg> wow, 4 years of hard tries, and at the end I found something challenging even for you :D I'm happy and sad at the same time!
[14:51] <cjwatson> heh
[14:51] <cjwatson> I agree the timings are consistent with change-override, just don't see how
[14:52] <cjwatson> I guess maybe msgpack-python still being around had some effect on what would ordinarily have been an error case
[14:52] <LocutusOfBorg> cjwatson, can the fact that binaries were "owned" by another source package be somewhat a cause?
[14:53] <cjwatson> I wouldn't have thought that would have an effect on the *source* still being published in -proposed, but it seems like the only plausible explanation
[14:54] <cjwatson> and yeah, if you manage to get into SPPH.changeOverride then it just does an IPublishingSet.newSourcePublication
[14:54] <cjwatson> oh well
[14:57] <apw> oh lovely :)
[15:11] <xnox> slangasek, re:dropping dh_python dependency https://lintian.debian.org/tags/missing-build-dependency-for-dh_-command.html
[15:11] <xnox> also posted by p1otr
[15:22] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (xenial-proposed) [14.04+16.04.20180326-0ubuntu1]
[15:28] -queuebot:#ubuntu-release- New: accepted grub-legacy-ec2 [source] (bionic-proposed) [1:1]
[15:34] -queuebot:#ubuntu-release- New sync: python-gitlab (bionic-proposed/primary) [1:1.3.0-1]
[16:45] <cascardo> doko: gcc-7-cross now fails to build the kernel on bionic/arm64
[16:45] <cascardo> http://kernel.ubuntu.com/~kernel-ppa/test-build/bionic/linux/LP%231754584--bc0adba16e0600a898435fa22c803f15e3caa866/arm64.log
[16:46] <cascardo> /usr/lib/gcc-cross/aarch64-linux-gnu/7/include/arm_neon.h:31605:10: error: incompatible types when returning type 'int' but 'uint32x4_t' was
[16:46] <cascardo>  expected
[16:47] <slangasek> xnox: aha, thanks for the corrected lintian tag
[17:48] <Odd_Bloke> slangasek: I've verified https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1757223; would you mind migrating livecd-rootfs in xenial?
[17:48] <ubot5> Ubuntu bug 1757223 in livecd-rootfs (Ubuntu Xenial) "ubuntu-cpc: Don't build minimized artifacts that won't boot with linux-kvm" [Undecided,Fix committed]
[18:02] <slangasek> Odd_Bloke: done
[18:03] <Odd_Bloke> Thanks!
[18:35] <tsimonq2> slangasek: peruse> I'll probably ship libacbf.so in its own binary as a library instead of making it private.
[18:36] <slangasek> Laney: as an aside, I believe it's a mistake that we don't provide a continuous "devel" track of everything cloud+autopkgtest; the discontinuity at release time is a major source of hassle for archive opening.  And if we start using 'devel' instead of 'bionic' in the sources, well...
[18:36] <slangasek> tsimonq2: is that supported by upstream?  libacbf.so doesn't have a proper SONAME
[18:37] <slangasek> tsimonq2: so I don't think it's really intended to be public?
[18:41] <tsimonq2> slangasek: Hm. I might reconsider that then.
[18:42] <tsimonq2> To be fair, I've asked several people and have gotten different answers.
[18:42] <slangasek> oh?
[18:45] <tsimonq2> So far, the three solutions I've heard are to carve it out, to make it private, or to ship it publicly.
[18:45] <slangasek> I'm wondering if the multiple answers you've gotten have come from Ubuntu uploaders, and if so what their rationale was
[18:46] <tsimonq2> All are core developers
[18:49] <tsimonq2> slangasek: I might try to figure out rpath with the arch-specific library directories (...) to ship it privately.
[18:50] <tsimonq2> But as I said before, this is new territory for me, so I'd like a review from someone when I get a candidate solution.
[18:50] <infinity> tsimonq2: Why would you need that?
[18:52] <infinity> tsimonq2: The package isn't multi-arch:same and, indeed, if it were a good candidate for such, it probably wouldn't need this talk about why it shouldn't be a public library.  Thus, it also doesn't need to use multiarch directories.
[18:53] <tsimonq2> infinity: OK; I'm not entirely clear on what that entails.
[18:56] -queuebot:#ubuntu-release- Unapproved: update-manager (artful-proposed/main) [1:17.10.13 => 1:17.10.14] (core)
[18:56] <tsimonq2> infinity: What sort of thing would you do if you were in this situation with a package you maintain?
[18:57] <infinity> tsimonq2: Short term, mangle the build to link it statically, or ship it in a private location, long term, engage upstream to either do the former or stabilise an API/ABI and make it a proper public library with an SONAME.
[18:58] <tsimonq2> infinity: Linking it statically would be OK?
[18:59] <tsimonq2> I mean, if it works.
[18:59] <infinity> tsimonq2: To that one non-library, sure.  Why wouldn't it be?
[18:59] <tsimonq2> *insert mantra about dynamically linking everything here*
[18:59] <tsimonq2> So, I don't know. :)
[19:00] <tsimonq2> Anyway, thanks.
[19:00] <infinity> tsimonq2: Dynamically linking to your *external* deps, sure.  THis isn't an external dep.
[19:01] <infinity> tsimonq2: Literally everything that isn't a single C file is statically linked. :P
[19:02] <tsimonq2> infinity: TIL.
[19:05]  * tsimonq2 tries to find something to RTFM on so I can handle this better next time.
[19:16] <Laney> slangasek: uh, ok, that feels like it came a bit out of nowhere, but if you want to map out the work, be my guest
[19:53] <slangasek> Laney: it's nothing urgent or high priority, it's just timely to mention because we're filing bugs about trying to fix autopkgtest's handling of pins and it might be better to be forward-looking
[19:56] -queuebot:#ubuntu-release- New binary: atril [ppc64el] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:08] -queuebot:#ubuntu-release- New binary: atril [armhf] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:11] <tsimonq2> Laney: Speaking of autopkgtests, I plan on finishing the duplicate queue stuff tomorrow night.
[20:12] <tsimonq2> I mean, if my code looks sane, you're welcome to cherry-pick the two commits I have done so far, because standalone that does fix part of the problem.
[20:12] <tsimonq2> It just doesn't look at the queue quite yet.
[20:23] -queuebot:#ubuntu-release- New binary: libnatpmp [i386] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
[20:23] -queuebot:#ubuntu-release- New binary: libnatpmp [s390x] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
[20:25] -queuebot:#ubuntu-release- New binary: libnatpmp [amd64] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
[20:26] -queuebot:#ubuntu-release- New binary: atril [s390x] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:27] -queuebot:#ubuntu-release- New binary: libnatpmp [armhf] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
[20:27] -queuebot:#ubuntu-release- New binary: libnatpmp [ppc64el] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
[20:28] -queuebot:#ubuntu-release- New binary: atril [amd64] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:28] -queuebot:#ubuntu-release- New binary: libnatpmp [arm64] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
[20:28] -queuebot:#ubuntu-release- New binary: atril [i386] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:39] -queuebot:#ubuntu-release- New binary: atril [arm64] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:50] -queuebot:#ubuntu-release- New binary: mate-desktop [ppc64el] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:50] -queuebot:#ubuntu-release- New binary: mate-desktop [s390x] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:51] -queuebot:#ubuntu-release- New binary: mate-desktop [amd64] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:51] -queuebot:#ubuntu-release- New binary: mate-desktop [i386] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:52] -queuebot:#ubuntu-release- New binary: mate-desktop [armhf] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[20:54] -queuebot:#ubuntu-release- New binary: mate-desktop [arm64] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
[21:13] <xnox> doko, infinity - do you have history as to why we need a delta to have a python-subversion-dbg package? it seems to fail on arm64/s390x and blocking ruby2.3 removal =/ it ends up with
[21:13] <xnox> <xnox> arm64: Test inherited props ... Fatal Python error: subversion/bindings/swig/python/svn_client.c:24101 object at 0xffff773dec18 has negative ref count -2604246222170760230
[21:13] <xnox> <xnox> s390x: Test inherited props ... Fatal Python error: subversion/bindings/swig/python/svn_client.c:24101 object at 0x3ffa7140528 has negative ref count -2604246222170760230
[21:14] <xnox> retried, to see if it works now.... but otherwise, i'd be inclined to either drop python-subversion-dbg alltogether, or at least on those two arches, to get subversion to migrate with ruby2.5 bindings, remove ruby2.3 from release, re-introduce the delta to build python-subversion-dbg on all arches to sort it out later.
[21:15] <xnox> does above smell like a python and/or swig bug?
[21:18] <slangasek> xnox: python-subversion-dbg has been a delta since 2007; I don't think that's an interesting thing for us to continue to carry today
[21:18] <slangasek> if killing that delta unblocks, I think we should
[21:20] <tsimonq2> slangasek (cc jbicha): I'd be curious to get your opinion on bug 1758702 from both an AA standpoint (irt the blacklist, dunno if that's AA or Release Team but that feels like AA) and a Release Team standpoint.
[21:20] <ubot5> bug 1758702 in gitlab (Ubuntu) "Please consider adding gitlab to sync blacklist" [Undecided,Confirmed] https://launchpad.net/bugs/1758702
[21:21] <slangasek> tsimonq2: lp:~ubuntu-archive/+junk/sync-blacklist/ is AA, yes
[21:22] <tsimonq2> slangasek: Ah ok.
[21:23] <slangasek> tsimonq2: between that bug report and the removal reason in bionic, I agree that blacklist makes sense; doing
[21:24] <tsimonq2> slangasek: ack, thanks
[21:37] -queuebot:#ubuntu-release- Unapproved: systemd (artful-proposed/main) [234-2ubuntu12.3 => 234-2ubuntu12.4] (core)
[21:38] <tsimonq2> slangasek: Since you had the related discussion, could I get an ACK/NACK on the debdiff attached to bug 1758798?
[21:38] <ubot5> bug 1758798 in tlp (Ubuntu) "tlp recommends smartmontools which then pulls in Postfix mailserver" [Medium,In progress] https://launchpad.net/bugs/1758798
[21:38] <tsimonq2> (Just covering my bases here, I guess.)
[21:45] <slangasek> tsimonq2: ack
[21:48] <tsimonq2> slangasek: Thanks.
[21:50] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (artful-proposed) [234-2ubuntu12.4]
[22:20] <jbicha> slangasek: is this a valid autopkgtest control file? https://salsa.debian.org/cinnamon-team/cinnamon-desktop/blob/master/debian/tests/control
[22:20] <jbicha> http://autopkgtest.ubuntu.com/packages/c/cinnamon-desktop/bionic/amd64
[22:20] <slangasek> jbicha: one with no non-comment, non-blank lines?  don't know
[22:21] <slangasek> I am unsurprised if it confuses things
[22:21] <jbicha> my question is should we set force-badtest or should we tell Debian to just remove debian/tests/ if it's not supposed to be run?
[22:22] <slangasek> jbicha: ah. I'm perfectly willing to force-badtest it, and also it seems like it should be dropped upstream
[22:22] <jbicha> let's split it, you do the first part, I do the second part :)
[22:22] <slangasek> (commenting out code instead of removing it, when maintained in a vcs, is an antipattern)
[22:23] <jbicha> right
[22:23] <slangasek> hint added
[23:13] -queuebot:#ubuntu-release- New binary: deal.ii [s390x] (bionic-proposed/universe) [8.5.1-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: deal.ii [ppc64el] (bionic-proposed/universe) [8.5.1-1] (no packageset)