[03:25] <doko> nacc: libsodium promoted again
[03:30] <jbicha> doko: could you try demoting the list from my latest comment at LP: #1745634 and xterm LP: #1720482 ?
[03:30] <jbicha> xterm at least shows up on component-mismatches-proposed now
[06:08] <nacc_> doko: yep
[06:08] <nacc_> doko: slangasek: i don't recall filing a MIR for php7.1 in artful. We went through the transition via php-defaults then. Does php7.2 need an explicit MIR?
[06:23] <doko> nacc_: no, just make sure that 7.1 gets demoted
[07:07] <doko> jbicha: xterm is still recommended in the release pocket
[07:36] <doko> xnox, jbicha: https://launchpadlibrarian.net/354753363/buildlog_ubuntu-bionic-s390x.babl_0.1.42-1_BUILDING.txt.gz
[07:36] <sforshee> doko: I tried building an arm64 kernel with 2.30-1ubuntu1 and still get the link error - https://launchpadlibrarian.net/355195922/buildlog_ubuntu-bionic-arm64.linux_4.15.0-6.7_BUILDING.txt.gz
[07:39] <doko> sforshee: where is the source for this build?
[07:42] <doko> sforshee: the kernel build log is notorious for not printing command line options
[07:42] <doko> could you extract these from the link line, and provide this together with all the object files?
[07:42] <sforshee> doko: you can get the source package from the ppa https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap, or lp:~ubuntu-kernel/ubuntu/+source/linux/+git/unstable
[07:44] <sforshee> doko: I'll also get your the link line and the object files, will take a bit
[08:06] <cpaelzer> rbasak: I don't really know what to do about https://lists.ubuntu.com/archives/ubuntu-release/2017-December/004255.html
[08:06] <cpaelzer> it is up 6 weeks now, my ping in early january still waits for moderator approval
[08:06] <cpaelzer> according to the doc it just needs one (1) SRU member to ack
[08:07] <cpaelzer> since I seem to be unable to get hold of one, could I ask to get you to consider parsing through the MRE wiki page and acking it if ok?
[08:08] <doko> dpdk: is that the python3 version?
[08:10] <sil2100> cpaelzer: oh, I think I wanted to take a look at that but then it fell between the cracks somehow
[08:11] <cpaelzer> I don't mind who takes a look
[08:12] <cpaelzer> I just want it to be not staying down in those cracks :-)
[08:21] <doko> nacc_: php7.2 -> net-snmp -> perl ... that looks like fun
[08:22] <doko> for migration
[08:27] <doko> infinity: fyi, dropping the libgcc-compat patches as done in debian doesn't help the glibc cross build
[08:49] <jjohansen> stgraber: hey do we have a bug for the apparmor ns_name issue that is causing profile loads to fail in artful/bionic
[08:53] <stgraber> jjohansen: hmm, that's a good question, I don't think so
[08:53] <jjohansen> okay, I'll create one
[09:02] <cpaelzer> what is the obvious extension to get perms/ownership controllable in d/package.dirs?
[09:03] <cpaelzer> is there some dh-exec magic or similar to this as well, or goging for d/rules (or postinst) to do so?
[09:03]  * cpaelzer is reading through dh_* man pages for now
[09:04] <doko> juliank: fyi, apt's own autopkg tests fail
[09:06] <cpaelzer> ah user id is not static anyway, so I'll need postinst I guess
[09:12] <juliank> doko: I know. Seems to be a umask issue or something. Gotta investigate the changes
[09:27] <sforshee> doko: looks like you have an account on kathleen, ~sforshee/binutils-arm64
[09:27] <sforshee> build.log has the verbose build output including the ld command
[09:27] <doko> sforshee: which one is kathleen? a porter box?
[09:29] <doko> tdaitx: https://launchpad.net/ubuntu/+source/maven-archiver/3.2.0-1/+build/14224913
[09:33] <tdaitx> doko: looking into that
[10:05] <doko> juliank: "The libfastjson library is a fork from json-c with a focus on performance"  such forks tend to be dead after a year or two ... is json-c not maintained anymore upstream?
[10:07] <juliank> doko: Well, I don't know, but rsyslog switched to it. I'm not sure if they're compatible.
[10:09] <juliank> doko: Seems it's maintained by the rsyslog people, so they'll know what they need
[10:09] <juliank> doko: I think modifying rsyslog to use json-c again would be more work, but I have not tried.
[10:09] <doko> juliank: yes, but it would add just another json implementation into main, what we are trying to avoid. I'm fine with it if we can switch the other packages to this implementation
[10:10] <juliank> doko: Apparently it does not really have a very stable API yet
[10:10] <xnox> infinity, has Tokyo timezone changed somehow? or maybe the tests in ruby2.3 are dead wrong? getting ADT failures in test_time_tz.rb in ruby2.3 with "off by one hour" for tokyo in 1951.
[10:11] <xnox>   1) Failure:
[10:11] <xnox> TestTimeTZ#test_asia_tokyo [/tmp/autopkgtest.lP30YH/autopkgtest_tmp/test/ruby/test_time_tz.rb:129]:
[10:11] <xnox> TZ=Asia/Tokyo Time.local(1951, 5, 6, 2, 0, 0).
[10:11] <xnox> <"1951-05-06 03:00:00 +1000"> expected but was
[10:11] <xnox> <"1951-05-06 02:00:00 +1000">
[10:11] <xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/r/ruby2.3/20180131_082235_fe969@/log.gz
[10:11]  * xnox reruns...
[10:11] <juliank> xnox: does not help, see #-release
[10:12] <xnox> ah
[11:22] <juliank> doko: uploaded an attempt to fix that apt thing (set umask 022 at start of script), let's hope it works.
[13:00] <sil2100> cpaelzer: I'm looking at the SRU exception for dpdk right now
[13:02] <sil2100> cpaelzer: looks good, but I'd like to formalize it a bit more - you mention more or less how testing of dpdk is carried over, but I'd like to have a step-by-step list of what is being tested before verification-done is marked in the SRU section of the page
[13:02] <rbasak> sil2100: thank you for looking at that
[13:03] <sil2100> cpaelzer: as an easy to see summary of the testing procedures
[13:03] <sil2100> cpaelzer: something that will make it easy for an SRU member to look at and see if such testing was performed during verification
[13:07] <cpaelzer> sil2100: ok, let me add something
[13:08] <cpaelzer> sil2100: you mean in section https://wiki.ubuntu.com/StableReleaseUpdates/DPDK#Testing_and_verification right?
[13:09] <sil2100> cpaelzer: yes, exactly ;) Maybe some short bullet-point summary of what was written in the sections above, for SRU purposes
[13:10] <sil2100> cpaelzer: additionally to what is already there
[13:12] <cpaelzer> sil2100: added
[13:13] <cpaelzer> sil2100: the MRE temaplate as well as the section linked above got some new text
[13:13] <cpaelzer> essentially the uploader is supposed to run the test suite and attach the log
[13:13] <cpaelzer> everythin in there shall be passed or explained-why-not
[13:13] <cpaelzer> https://wiki.ubuntu.com/StableReleaseUpdates/DPDK?action=diff&rev1=1&rev2=2
[13:13] <cpaelzer> sil2100: ^^ for the diff
[13:14] <cpaelzer> would that cover what you wanted to see?
[13:14] <sil2100> Oh, that's also fine then
[13:38] <doko> ginggs: should pocl's testsuite errors be ignored on armhf or arm64, or should we remove the binaries?
[13:40] <ginggs> doko: i think remove the binaries
[13:46] <doko> ginggs: ok, need to figure out the rdeps ...
[13:48] <doko> ginggs: could you have a look what needs to be done for the qgis transition?
[13:50] <ginggs> doko: sure
[13:50] <doko> ta
[13:56] <ackk> cjwatson, hi, around?
[13:57] <cjwatson> slightly.  if it's py-macaroon-bakery, still on my list :-/
[13:57] <cjwatson> I have to run in a moment to pick up the kids though
[14:00] <ackk> cjwatson, it's related to that :) do you foresee any issue with an MIR for macaroon/bakery libraries? AFAICS that requires a few dependencies to be promoted too
[14:01] <cjwatson> ackk: no, I think I even replied to the MIR to ack it?
[14:01] <ackk> cjwatson, oh, is there one already?
[14:01] <cjwatson> oh, maybe I'm thinking of the SRU bug
[14:02] <cjwatson> anyway, I wouldn't anticipate a problem (libsodium at least is already in main), though I'm sure the security team will want to give it a review
[14:03] <ackk> ah nice, thanks
[14:55] <ginggs> doko: it looks like qgis is blocked on qscintilla2, which is blocked on some octave autopkgtests - looking at those now
[15:46] <jbicha> doko: xnox: babl/s390x is a pain and I don't know how to fix it. See also GNOME bug 790745 and Debian bug 888769
[15:54] <slangasek> nacc_: no, php7.2 just needs a team subscriber and a swap in the archive
[16:19] <nacc_> slangasek: ack, that's all ready to go as well then
[16:20] <nacc_> slangasek: (well ready as far as components, the migration is still under way in dependent packages)
[16:20] <nacc_> doko: ack, thanks
[16:20] <nacc_> doko: yeah :/
[16:20] <nacc_> (re: the dependency chain)
[16:29] <doko> nacc, slangasek: we might want to pre-promote argon2, ok from a MIR standpoint, but still waiting for security review (asked to priotize it). currently everything fails in the autopkg tests
[16:31] <nacc_> doko: i thought argon was for cryptsetup?
[16:36] <slangasek> doko: pre-promotion is no problem from my side
[16:51] <doko> ok, done
[16:51] <doko> nacc_: you will have to give back a lot of php-defaults autopkg tests
[16:54] <nacc_> doko: yep, that's on my plate nonw
[20:56] <nacc_> doko: fwiw, i think many of these will go away once ig et phpunit migrated
[20:56] <nacc_> and it's own dependencies, that is
[21:30] <jbicha> rbalint: can you push your latest libnfs changes to the Debian VCS? also can you cherry-pick the upstream fix for Debian bug 882540?
[21:31] <jbicha> btw,I filed #1746598
[21:58] <nacc_> doko: and fyi, the latest php7.2 should fix the remaining c-m, sorry about that
[22:12] <rbalint> jbicha: i fixed the repo, need a bit more time to get new upstream packaged
[22:13] <jbicha> rbalint: I understand. Could you cherry-pick the ftbfs commit though?
[22:14] <rbalint> jbicha: if it takes too much time i'll cherry-pick
[22:14] <jbicha> cool, thanks
[22:15] <rbalint> jbicha: popcon for libnfs skyrocketed last year :-)
[22:15] <jbicha> blame gvfs :)
[23:58] <jbicha> infinity: could you forward this upstream? https://launchpad.net/ubuntu/+source/gvfs/1.34.1-1ubuntu3