[02:57] <Logan> hyperair: FYI, arm64 needs to be added to the architecture list for libgpod-cil(-dev) as well to fully make it a mono arch :)
[02:57] <Logan> (I was looking at syncing, but 0.8.3-7 doesn't include that change we have in Ubuntu)
[05:55] <hyperair> oops
[05:55] <hyperair> wait a sec, does mono work on arm64 in debian?
[05:55] <hyperair> Logan: ^
[05:57] <Logan> hyperair: it's in the architecture list, so I guess so :P
[05:58] <hyperair> hm
[06:01] <sarnold> add an autopkgtest and find out if it fails on http://autopkgtest.ubuntu.com/packages/m/mono/  later? :)
[06:02] <sarnold> oh :/ no arm64 there either
[06:03] <hyperair> https://packages.debian.org/sid/mono-runtime-sgen does have arm64 though
[06:21] <sarnold> pitti: hey, sys-kernel-debug.mount feels like a mistake. I don't think debugfs is robust enough to justify auto-mounting everywhere..
[07:16] <pitti> bdrung_work: as I wrote in the bug, my opinion is that this should be fixed in the kernel and working around it in userspace is silly :)
[07:18] <pitti> bdrung_work: followed up
[07:23] <pitti> rbasak: followed up
[07:32] <pitti> smoser: do you know why http://cloud-images.ubuntu.com/yakkety/current/ points to 0529 while there are thee newer images from June?
[08:13] <seb128> bdmurray, hey, is there possible to have a recent bt of a report from https://errors.ubuntu.com/problem/590ab412d186298ada0ae288838a0256fe6e76e4 ?
[08:34] <seb128> mdeslaur, hey, unsure if you saw but bug #1580597 started with the 1.8.16 sudo update, unsure if it's an important issue but it has some thousands report and sudo is kind of an important component, so I'm just pointing it out
[08:41] <Odd_Bloke> pitti: The current symlink doesn't get updated until the end of the publication process; I believe that we were having issues with MAAS image stream generation, and now the ProdStack outage is blocking us. :)
[08:41] <pitti> Odd_Bloke: oh, is PS still out? my part of it seems to work
[08:41] <pitti> Odd_Bloke: thanks for the heads-up, so this is "known"
[08:42] <pitti> Odd_Bloke: but the PS outage was yesterday, first non-current image was already a week ago
[08:43] <Odd_Bloke> pitti: Yeah, the MAAS issue got fixed just before the outage, so there hasn't been a successful build since then due to the outage.
[08:43] <Odd_Bloke> pitti: (I've just kicked one off :)
[08:43] <pitti> smoser: ^ unping
[08:43] <pitti> Odd_Bloke: hah, go timing :)
[09:13] <Odd_Bloke> Anyone around who installed a desktop from a xenial ISO who could pastebin their sources.list for me?
[09:20] <pitti> infinity: any idea how I find out what still keeps "initscripts" as "priority: required"? none of its rdepends are required, and it's not in the "required" seed
[09:21]  * pitti wants it gone from a default install
[09:22] <pitti> and I can purge it without any complaints
[09:24] <cjwatson> pitti: nothing
[09:24] <cjwatson> <cjwatson@niejwein ~>$ ssh -t snakefruit sudo -iu ubuntu-archive chdist apt-cache yakkety-amd64 show initscripts | grep ^Priority:
[09:24] <cjwatson> Priority: optional
[09:24] <pitti> cjwatson: hmm, shouldn't it be in http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt then?
[09:24] <cjwatson> pitti: no, because it's already optional
[09:25] <pitti> whee, why does it say "Priority: required" here
[09:25] <pitti> aah, old cloud image, I suppose
[09:25] <pitti> cjwatson: *brown paperbag*, thanks
[09:25] <cjwatson> :)
[09:58] <pitti> cjwatson: I'm considering dropping Vcs-Bzr: from cdebconf when merging; the overhead of merging from git into bzr is not justified IMHO, and there hasn't been any Ubuntu development on this package for years; just applying the MoM debdiff is so much easier; WDYT?
[09:59] <cjwatson> pitti: don't care :)
[09:59] <pitti> what I thought, thanks
[10:18] <pitti> kirkland, tyhicks: who is looking into ecryptfs these days? bug 1447282 has a new case (fails for NVME partitions), but I keep not having enough time for this
[10:18] <pitti> I might get to it eventually, but it keeps getting pushed down the list
[10:18] <pitti> i. e. any chance someone might get to this earlier than me?
[11:56] <seb128> mdeslaur, hey, sorry I screwed my session and was out of IRC while at lunch ... I saw you commented on one of the sudo segfault bugs, thanks ;-)
[11:58] <mdeslaur> seb128: yeah, not sure what the fix is though, needs an upstream bug
[11:59] <seb128> mdeslaur, I looked a bit at the cmd used in the different report, nothing special
[12:01] <mdeslaur> yeah, not exactly sure what's going on, I think sudo tries to kill itself, hangs, then gets an abort....or something.
[12:57] <sil2100> pitti: hey! Since I don't have the knowledge/power to help here, could you take a look on why https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html i386 test seems to be in progress but not visible on http://autopkgtest.ubuntu.com/running.shtml ?
[12:58] <pitti> sil2100: supposedly fallout from the PS outage, re-queued
[13:00] <sil2100> pitti: thank you!
[13:22] <ChrisTownsend> pitti: Hey, did the i386 test for https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html run?
[13:23] <pitti> ChrisTownsend: yes it did, see sil2100's ping from half an houru ago
[13:23] <pitti> ChrisTownsend: you can check at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-051?format=plain&prefix=xenial/i386/c/content-hub
[13:23] <pitti> ChrisTownsend: (totally obvious URL, isn't it? :-)
[13:24] <pitti> next britney run will pick this up
[13:24] <ChrisTownsend> pitti: Oh, ok, thanks.  Nice URL, btw:)
[13:24] <pitti> and it passed: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-051/xenial/i386/c/content-hub/20160608_130942@/log.gz
[13:24] <ChrisTownsend> pitti: Awesome\o/
[13:47] <rharper> rbasak: bug 1491406 , I nominated for trusty; who would be able to add that task ?
[13:48] <rbasak> rharper: added. It needs an uploader or someone on the bug control team AIUI. The community process is to ask in the #ubuntu-bugs IRC channel. I watch that too so will happily do it.
[13:49] <rharper> rbasak: awesome, thanks
[14:17] <pitti> rharper: good morning, how are you?
[14:20] <rharper> pitti: good, and you ?
[14:21] <pitti> rharper: quite okay, cold is getting better, thanks
[16:34] <nacc> rbasak: did my logic in the MR make sense (for what the 'uploader' would do?)
[16:53] <mvo> arges: hi, do you think you could check #1589534 ? we need a snapd  2.0.8 with a store refresh fix over the current 2.0.7 into xenial-proposed. sorry for the trouble, let me know if anything is missing in that bugreport (iirc you are today on sru call, if not my appolgizes)
[16:53] <arges> mvo: ok looking
[16:54] <arges> mvo: assuming this is fixed in yakkety?
[16:54] <mvo> arges: yeah, yakkety has 2.0.8+16.10 which is identical to the sru except for version in the changelog
[16:55] <arges> mvo: ok i'll mark the development task as fixed
[16:55] <mvo> arges: please let me know if there is anything I can do to make your life easier, I know we are a bit of a burden with the amount of srus right now
[16:56] <arges> mvo: reviewing it now
[16:58] <rbasak> nacc: yes, that makes sense.
[16:58] <rbasak> nacc: it would be magic if the uploader could itself create the merge commit, but I'm not sure that's possible.
[16:59] <rbasak> nacc: also, although proposing the MP against debian/sid seems to work, it "feels wrong" as the result is not that debian/sid will end up with the branch as an ancestor. I might experiment and see what happens if I submit an MP against ubuntu/devel (or ubuntu/yakkety for now).
[17:00] <arges> mvo: ok accepted
[17:01] <mvo> arges:  \o/
[17:01]  * mvo hugs arges
[17:02] <arges> heh
[17:13] <pitti> smb, arges: grep xenial-updates was a little premature
[17:13] <pitti> verification instructions said "wait on the archive rebuild on x or y" which didn't happen yet (doko has planned to do it RSN, though)
[17:13] <arges> pitti: it was 7 wasnt it?
[17:14] <pitti> not much immediate harm, it could at most be that we now rendered some packages in xenial FTBFS
[17:14] <pitti> but we'll still find them during the test rebuild and fix in y if needed
[17:14] <infinity> pitti: We probably fixed more than we broke. ;)
[17:14] <pitti> (and backport those along)
[17:14] <pitti> yeah, I agree, just saying that this was originally agreed on waiting for the test rebuild
[17:15] <infinity> Yep.
[17:15] <pitti> not an alarm bell at all
[17:15] <pitti> anyway, time for dinner :)
[17:17] <arges> pitti: thanks for letting me know sorry about that
[17:21] <rbasak> nacc: I just uploaded your SRU debdiffs for bug 997172 while I was there. Did you actually want them uploaded now? It just occurred to me that you hadn't subscribed ~ubuntu-sponsors again and did upload to a PPA.
[17:48] <nacc> rbasak: should be fine, was about to subscribe sponsors and request the sru officially anyways
[17:48] <nacc> rbasak: thanks
[19:08] <teward> if a package in Ubuntu is version 1.0.2+dfsg-2, and needs fixed in both Yakkety and Xenial (via SRU), would the versions become 1.0.2+dfsg-2ubuntu1 (Yakkety) and 1.0.2+dfsg-2ubuntu0.16.04.1 (Xenial)?
[19:10] <cjwatson> that sounds right
[19:10] <nacc> seems to agree with the wiki page
[19:10] <teward> cjwatson: nacc: that's what I thought, wasn't sure if the dfsg was going to throw anything off :P
[19:10]  * teward is mass-preparing debdiffs for a High bug he's gunning to fix right now.
[19:10] <teward> (though, not in anything major :P)
[19:11] <cjwatson> the +dfsg isn't relevant here, no
[19:11] <teward> cool :)
[19:12] <teward> cjwatson: nacc: thank you both for the sanity check on my brain :)
[19:12] <teward> definitely appreciated :)
[22:16] <nacc> slangasek: question re:dh-php for you. Debian has introduced another dep for dh-php (xml2). Rather than MIR dh-php, would it make sense to make dh-php a Suggests in php7.0-dev and thus demote dh-php to universe?
[22:16] <nacc> (right now dh-php is a recommends)
[23:05] <nacc> slangasek: another question re: php-imagick. Debian decided to go with the MAGICK_THREAD_LIMIT=1 in debian/tests/control rather than setting the resource limit via a patch to the source. Would you prefer we keep the latter delta and not set the environment variable? Or drop the delta and use the same workaround that Debian does?
[23:15] <infinity> nacc: If it's required to make the tests pass, does that not imply that it's also required to make it work right at runtime?
[23:15] <infinity> nacc: If so, Debian's solution is incorrect, and you should tell them as much.
[23:15] <infinity> The goal of testsuites isn't to make the testsuite pass at all costs, it's to test the runtime functionality. :P
[23:23] <nacc> infinity: yep, I get that
[23:23] <nacc> infinity: the issue is, it's not somethign that's 100% repeatable
[23:23] <nacc> afaict
[23:23] <nacc> there is a raciness somewhere
[23:23] <nacc> but it doesn't necessarily happen on everyone's system
[23:24] <mwhudson> infinity: purist
[23:24] <nacc> infinity: i agree with your sentiment, i'll keep the delta for safety's sake and send it to debian
[23:24] <nacc> infinity: they should take the rest of our delta too and we should be able to sync after that
[23:24] <infinity> nacc: Upstreaming the patch wouldn't be a terrible idea.
[23:25] <nacc> infinity: upstream consider it a workaround, have it documented on their page, but won't take a patch to chagne the source
[23:25] <nacc> infinity: as it's distro-specific (apparently) where it's necessary
[23:26] <nacc> Logan: fyi, i have my merge for phpunit-mock-object done, but it's going to fail due to needing phpunit to update (and phpunit is currently failing to build) -- i'm investigating that now
[23:35] <nacc> Logan: phpunit fails to build because php-codecoverage fails to build ...
[23:38] <nacc> Logan: hrm, the php-codecoverage may just need to be a manual rebuild, as it does build now for me in a sbuild (although it fails the tests), investigating that
[23:43] <nacc> and the tests fail becasue they need the newer phpunit...
[23:46] <nacc> slangasek: --^ sound familiar :/ ... reviewing my notes now
[23:54] <slangasek> nacc: hmm does not sound familiar
[23:54] <nacc> slangasek: was mostly joking, we went through this w/ 16.04
[23:55] <nacc> it's the same bootstrap stuff
[23:55] <slangasek> ah
[23:55] <slangasek> but we didn't actually have to bootstrap anything! :)
[23:55] <nacc> will just use my old algorithm, hopefully it still applies
[23:55] <nacc> yeah, we got lucky :)
[23:56] <nacc> slangasek: would appreciate your feedback on the two merge queries from a few hours ago, but no urgency. I think the imagick one is clear to me now after infinity's feedback, just wanted to verify.
[23:56] <slangasek> nacc: oops, missed them - looking now
[23:56] <nacc> slangasek: np, thanks!
[23:57] <slangasek> nacc: dh-php> yes, that seems ok to drop from Recommends to Suggests
[23:58] <slangasek> nacc: the php-imagick one, I agree with infinity :)
[23:58] <nacc> slangasek: perfect, thanks on both counts!