[00:41] <rlaager> I've prepared an SRU. The procedure says that you need to make sure it's fixed in the development release (which it is) and that the bug status is Fix Released. So I changed it to that. But then later, it says to use In Progress. Apparently I could change it to Fix Released, but now can't change it back to In Progress.
[00:41] <rlaager> I also can't add distro-version-specific tasks. Can someone set this to In Progress and/or add a Bionic task that's In Progress: https://bugs.launchpad.net/ubuntu/+source/icingaweb2/+bug/1769890
[00:41] <ubottu> Launchpad bug 1769890 in icingaweb2 (Ubuntu) "Icingaweb2 does not work with PHP 7.2" [Undecided,Fix released]
[00:43] <cjwatson> rlaager: I've added a bionic task, which you should be able to manipulate
[00:43] <cjwatson> (I just did the minimal thing and left it with the default status of New)
[00:43] <rlaager> cjwatson: Thanks, done. I think we're in the desired state now... i.e. waiting for my debdiff to be reviewed by ubuntu-sponsors.
[00:44] <cjwatson> rlaager: You might want to assign that task to yourself too
[00:44] <cjwatson> and possibly note that the thing in your last comment is done :)
[00:45] <rlaager> I hid the comment.
[00:45] <cjwatson> ack
[05:12] <tjaalton> xnox: you filed RM on dogtag without any discussion?
[05:18] <tjaalton> xnox: the reason why it's not in testing or stable is because openjdk-8 will never migrate. and it works just fine with current nss, and supports tls 1.3 via jss
[07:03] <tarzeau> is there some ubuntu-devel people that are also dd who would be interested getting some interesting software into 20.04 LTS? (i've got breseq, cadabra2, coreboot(-utils), memtestcl, mimalloc, mlv-app, octopus, redasm, shotcut, speed-dreams, tiatracker, zytrax, hpx) waiting for review+sponsoring
[07:08] <JackFrost> That's more than a couple! :)
[07:09] <tarzeau> i got a few more like fricas and protrekkr, but i doubt anyone is interested in those, but yes, it's a bunch
[07:09] <tarzeau> pick one :)
[08:18] <tarzeau> i also have a working fontmatrix qt5 version, but the d/copyright sucks because of CC licenses and jquery embedded (lintian stuff)
[08:48] <seb128> pitti, hey Martin, happy new year! do you think you could backport https://github.com/martinpitt/python-dbusmock/commit/bd51d910 to Debian? I saw there is probably another problem but it sounds like that commit would be required in any case?
[09:07] <jamespage> doko: yep - RM radosgw-agent
[09:13] <pitti> seb128: bonjour, et bonne année !
[09:13] <pitti> seb128: yes, I was planning to just do a new upstream release and upload that
[09:13] <seb128> vorlon, hey, do you understand why half of the desktop world if failing on i386 due to installability issues today?
[09:13] <pitti> seb128: unfortunately my sid schroot has been broken since yesterday, the gnupg upload seems to have messed up something -- there's no gnupg in the archive right now
[09:18] <seb128> pitti, ah ok, good to read, I wanted to merge the n-m update for focal, I'm going to wait for that update, good luck with gnupg missing!
[09:18] <pitti> seb128: but mbiebl found more errors with unstable's NM, I don't think that commit is enough
[09:19] <seb128> pitti, I read that bug but you said that it work on fedora, maybe it does work also on Ubuntu :-)
[09:19]  * pitti grabs the test result dice and rolls it
[09:19] <seb128> but yeah, the other issue is going to need to be looked at/resolved eventually
[09:19] <seb128> the known one/git commit is needed for sure in any case
[09:20] <pitti> right
[10:06] <sunweaver> Hi all! Has anyone in the Ubuntu world seen the upstream developer(s) of the onboard on-screen keyboard, recently?
[10:06] <sunweaver> I am the Debian maintainer of onboard and I pinged them via mail some weeks ago and haven't received an answer, yet.
[10:07] <sunweaver> Is there anyone around that has a clue about the maintenance status of Onboard?
[10:15] <seb128> sunweaver, upstream or the Ubuntu package?
[10:18] <JackFrost> You missed:[05:06:32] < sunweaver> Hi all! Has anyone in the Ubuntu world seen the upstream developer(s) of the onboard on-screen keyboard, recently?
[10:18] <JackFrost> [05:06:58] < sunweaver> I am the Debian maintainer of onboard and I pinged them via mail some weeks ago and haven't received an answer, yet.
[10:28] <seb128> k, I don't then, sorry
[10:29] <sunweaver> seb128: thanks.
[10:29] <sunweaver> I just cherry-pick rbalint's fixes on onboard in Ubuntu over to Debian.
[10:30] <sunweaver> But we might become read to remove it from the archives.
[10:30] <sunweaver> unless someone else steps up as upstream maintainer.
[11:31] <enyc> sunweaver: i wonder in the bigger-picture of things about  importance of accesibility features in general
[11:32] <xnox> tjaalton:  merged new nss doesn't seem to work with it at all, as it requires tls v1.2 minimum. If it doesn't have a champion in Debian, it must have one in Ubuntu, as it is in universe. Is kernel-team going to subscribe to it and fix autopkgtests?
[11:32] <enyc> sunweaver: have noticed  dragon input system,  colour changing tools,  magnifiers,  screen readers,  and so-on ...  just not-so-available for gnu/linux/ubuntu/etc
[11:33] <xnox> tjaalton:  and are we keeping openjdk-8 in focal? i guess we are, in that case someone or me needs to check what's going on with current nss then.
[11:35] <xnox> cjwatson:  does openssh have any magic tests around 2020 date. Seems like it started to fail since new year http://autopkgtest.ubuntu.com/packages/openssh/focal/amd64 https://ci.debian.net/packages/o/openssh/unstable/amd64/ debian timings w.r.t. new year are a lot closer. I am not sure if i am reading regress errors right, but it fails tests to do with expiration of things.
[11:35] <tjaalton> xnox: dogtag-pki autopkgtests pass fine on debian, so it's not nss to blame then?
[11:35] <cjwatson> regress/cert-hostkey.sh:test_one "cert not yet valid"   failure "-h -V20200101:20300101"
[11:35] <cjwatson> regress/cert-userkey.sh:test_one "cert not yet valid"   failure "-n ${USER} -V20200101:20300101"
[11:37] <enyc> cjwatson: o dear =)  should this not use a hardcoded test 'date in future' at all, rather calculate something at time of build?
[11:37] <cjwatson> https://anongit.mindrot.org/openssh.git/commit/?id=ff31f15773ee173502eec4d7861ec56f26bba381
[11:37] <xnox> tjaalton:  debian doesn't set tlsv1.2 min in nss; but we do.
[11:37] <cjwatson> enyc: no doubt, but I'll just cherry-pick the upstream change.  Take it up with upstream
[11:38] <enyc> I wonder at what point trying to colcucate over 2038 etc. will fail ;p
[11:38] <enyc> unix time 32-bit and all that =)
[11:38] <xnox> cjwatson:  i like that they make it still 1st of Jan. I'll ask them to move it at least to Jan 14th because holidays.
[11:38] <tjaalton> xnox: so there were autopkgtests showing that it failed? have they been removed now as well?
[11:38] <cjwatson> Not on 64-bit systems it isn't, and people are working on the 32-bit case
[11:39] <xnox> tjaalton:  should be still there => one sec.
[11:39] <xnox> cjwatson:  thank you for pointing it out!
[11:41] <xnox> tjaalton:  fails to initialize https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/d/dogtag-pki/20200108_202654_c8684@/log.gz ?
[11:41] <tjaalton> so after ~5h it got removed, nice
[11:42] <tjaalton> CA worked, so ipa server still works too
[11:42] <tjaalton> /usr/lib/python3.7/getpass.py:91: GetPassWarning: Can not control echo on the terminal.
[11:43] <tjaalton> I don't think it's related to nss but maybe something else
[11:43] <xnox> tjaalton:  there are other errors about something else deprecated in the logs about passwords / pin.
[11:43] <xnox> tjaalton:  if the autopkgtest is fixed in debian, we can sync both of them back in, and readd them.
[11:43] <cjwatson> xnox: thanks for noticing, since I hadn't yet; fix uploaded to unstable
[11:44] <tjaalton> xnox: well I can drop the uninstall test..
[11:44] <tjaalton> it's pretty pointless anyway
[11:44] <xnox> tjaalton:  it's just there is nobody to gate it (no gating in debian, and no owner in ubuntu)
[11:44] <xnox> tjaalton:  true.
[11:44] <xnox> tjaalton:  propose it to debian, and sync from there?
[11:44] <tjaalton> I'm the maintainer there
[11:45] <xnox> cjwatson:  i wonder if we need to SRU it across all the releases & ESM now too =/
[11:45] <xnox> tjaalton:  oh, ok =)
[11:45] <xnox> did not realize / check that, sorry.
[11:46] <tjaalton> np, this did prompt me to ask the fedora jdk maintainer about their plans, and jdk11 might finally make it on their schedule..
[11:46] <cjwatson> xnox: Can ride along with any other fix that's required I imagine
[11:46] <tjaalton> which in turn means it's a priority to port everything over
[13:02] <ahasenack> cpaelzer: this is weird: https://pastebin.ubuntu.com/p/CKJYg6wqXs/
[13:03] <ahasenack> cpaelzer: line 3 creates the local/usr.sbin.slapd local override
[13:03] <ahasenack> then line 4 loads it, all is fine
[13:03] <ahasenack> test runs, succeeds
[13:03] <ahasenack> then at the end I remove the override 40
[13:03] <ahasenack> but apparmor_parser -r fails weirdly
[13:03] <ahasenack> -T and -W are to handle the cache, which I thought was the problem
[13:05] <ahasenack> ahhhh
[13:05] <ahasenack> found it
[13:05] <ahasenack> thanks :)
[13:08] <jamespage> cpaelzer: I'm ready to go on openvswitch and ovn updates post 19.11 dpdk upload
[13:09] <jamespage> will need some archive-admin time for the split out and new source package for ovn
[13:09] <cpaelzer> jamespage: I ahve a call about DPDK in 1.5h after that I intend to upload
[13:09] <cpaelzer> jamespage: will hit new queue as well
[13:09] <jamespage> great
[13:09] <cpaelzer> so you have some time to sort out AA needs :-)
[13:09] <cpaelzer> I'll keep you posted on it
[13:25] <seb128> LocutusOfBorg, hey there, what do you think about splitting the remmina-gnome-session entry in a different deb (which we would install by default)?
[13:25] <seb128> Laney, ^
[13:26] <Laney> I just asked mfv about that in #debian-gnome
[13:26] <Laney> :>
[13:26] <seb128> ah, for some reason I though locusofborg was also maintaining it in debian
[13:27] <Laney> maybe LocutusOfBorg will want to do the work anyway ;-)
[13:28] <Laney> also I think you mean "would *not* install by default"!
[13:29] <seb128> shrug, I need to stop doing those thinkos, indeed
[13:30] <seb128> LocutusOfBorg, bug #1851007 also I think is still not resolved which makes the session not working
[13:30] <ubottu> bug 1851007 in remmina (Ubuntu) "Login option 'GNOME + Remmina' not working" [Low,Confirmed] https://launchpad.net/bugs/1851007
[13:36] <LocutusOfBorg> I would like to avoid doing debian work for remmina :p
[13:37] <seb128> LocutusOfBorg, sorry, for some reason I though you were maintaining it there :)
[13:38] <LocutusOfBorg> no problem :)
[13:38] <LocutusOfBorg> I just do the merges, because both upstream and Debian are italian, and they ask directly to me!
=== ricab is now known as ricab|lunch
[13:40] <Laney> heh
[13:48] <ahasenack> xnox: hi, I have an MP up for krb5 to switch it to use py3
[13:48] <ahasenack> https://code.launchpad.net/~ahasenack/ubuntu/+source/krb5/+git/krb5/+merge/377326
[13:48] <ahasenack> I just missed to link it with the bug :/
[13:53] <RikMills> is anyone looking at merging pulseaudio? that has the equaliser ported with patches to python3 I think?
[13:53] <RikMills> doko ^ ?
[13:54] <seb128> RikMills, pulseaudio is maintained by the desktop team, don't bother doko with it :)
[13:54] <RikMills> seb128: right
[13:55] <seb128> RikMills, is there a concrete problem with it as of today?
[13:55] <seb128> we will merge that/get an update before ff for sure, but I do an upload sooner rather than later if there is need for the change to land in focal now
[13:57] <RikMills> seb128: new pyqt5 synced that autosynced from debian dropped the Python2 dbus.mainloop.pyqt5 packages that the equaliser currently depends on, so pyqt5 will not migrate until pulseaudio is merged
[13:58] <seb128> RikMills, k, sounds lIke a good reason, let me merge that change, and thanks for the ping!
[13:58] <RikMills> not urgent, but would be nice to fix
[13:58] <RikMills> thanks! :)
[13:58] <LocutusOfBorg> seb128, what about asking debian to bump epoch so MoM does some little job on it?
[13:59] <seb128> LocutusOfBorg, you can ask them if you feel like, I personally don't use that service for pulseaudio since we have git packaging
[14:00] <LocutusOfBorg> I did a debdiff between debian and ubuntu
[14:01] <LocutusOfBorg> there is something that should probably go away, like upstart stuff
[14:01] <LocutusOfBorg> MoM does a good job in that
[14:01] <LocutusOfBorg> but yeah, a git diff does it even better
[14:01] <seb128> thanks for pointing it out, I will have a look at the delta we can drop while I'm at it
[14:02] <LocutusOfBorg> while I asked you to do, I remembered that pidgin has the same issue, and it is collaborate maintenance in Debian
[14:02] <LocutusOfBorg> so I'll just commit the bump epoch there :p
[14:02] <seb128> :)
[14:03] <LocutusOfBorg> they acked it a while ago, but they forgot to commit
[14:06] <doko> RikMills: yep, just wanted to get that installable again. Could you do the merge?
[14:06] <doko> seb128: ^^^
[14:07] <seb128> doko, yes, I'm on it
[14:08] <seb128> doko, feel free to ping about any desktop owner source that needs merged/fixing, we are happy to help
[14:25] <xnox> ahasenack:  nice!
[14:25] <xnox> ahasenack:  does it work? =)
[14:33] <ahasenack> xnox: sure
[14:56] <xnox> tjaalton:  why would we keep openjdk-8 if like only three things are left that depend on it
[14:57] <xnox> tjaalton:  actually they all have alternatives
[14:57] <tjaalton> doko: ^
[15:01] <xnox> doko:  vorlon: please remove openjdk-8 from focal https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1859037
[15:01] <ubottu> Launchpad bug 1859037 in openjdk-8 (Ubuntu) "RM: openjdk-8 obsolete, unused in the archive" [Undecided,Triaged]
[15:02] <doko> xnox, vorlon: please no. we said will will keep it until the support for 16.04 LTS ends
[15:03] <doko> so maybe what we might want to do is to ship it only in -updates
=== ricab|lunch is now known as ricab
[15:19] <xnox> doko:  which support? until 2026 then?
[15:20] <xnox> doko:  in that case i'd love to drop alternative depends, such that nothing has alternative depends on openjdk8 in the archive.
[15:20] <doko> xnox: apparently, yes. as long as we need to update the package, that's ok
[15:20] <xnox> doko:  ack.
[15:20] <doko> xnox: could you have a look at the z3 ftbfs on s390x?
[15:50] <doko> seb128: we need to coordinate the pygtk2 removal with jbicha. I'd like to avoid rebuilding all that old stuff ...
[15:51] <seb128> doko, yes, do we have a bug report to track that atm?
[15:52] <seb128> doko, also feel free to give us a list of desktop things to fix, you don't have to fix everything yourself
[15:52] <xnox> doko:  urgh that is ugly
[15:56] <doko> seb128: I don't have such a list, but you could scan python-defaults in output_notest
[15:59] <seb128> doko, k, well in any case when you hit a desktop package that you want to see fixed feel free to ping
[16:13] <vorlon> seb128: half of the world> which half?  link to some log?
[16:15] <seb128> vorlon, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[16:15] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/c/clutter-1.0/20200108_155337_4f951@/log.gz
[16:15] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/f/firefox/20200108_211625_61bf5@/log.gz
[16:15] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/f/ffmpeg/20200108_172908_8962e@/log.gz
[16:15] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/libs/libssh/20200108_211244_b9663@/log.gz
[16:15] <vorlon> seb128: ok looking
[16:15] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/p/poppler/20200108_201209_55428@/log.gz
[16:16] <seb128> vorlon, it might be they are ending up to a common lib not installable or something but unsure how to properly figure that out...
[16:16] <seb128> vorlon, thx
[16:16] <vorlon> seb128: it's expected that firefox tests won't pass on i386 and it's a bug in britney that they're run
[16:16] <seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/g/gtk+2.0/20200108_230517_cbb33@/log.gz
[16:16] <vorlon> the others though, I've just noticed and will dig in now, thanks
[16:16] <seb128> thx
[16:17] <vorlon> https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt doesn't show uninstallabilities fwiw
[16:17] <seb128> also if you have hints on how to poke to those issues I might be able to figure things out myself instead of bothering you next time :)
[16:17] <seb128> oh, I didn't know about that report
[16:17] <seb128> nice
[16:17] <vorlon> oh it's probably hitting the autopkgtest bug where if a library in the amd64 base system is in -proposed, the pin doesn't get set to cover both archs
[16:18] <vorlon> but that doesn't explain why it's uninstallable on the second run with all of proposed
[16:19] <vorlon> so I'd guess it was: couldn't cherry-pick the specific package from -proposed because of wrong pin; couldn't install from -proposed because some build was behind
[16:19] <vorlon> I'll see if I can reproduce it now and maybe these'll just need to be retries
[16:31] <seb128> k, thanks
[17:01] <rafaeldtinoco> rbasak: SO, when you're packaging mysql-server-8, did u make sure for all the build tests to pass ? just checking cause I think there are 2 of those failing currently for focal, wanted to know if you faced failing tests during build time (nocheck doesn't change attempt of running the tests).
[17:02] <rbasak> rafaeldtinoco: it's quite common for us to see test failures. They fail the build.
[17:02] <rbasak> (though we don't run the _entire_ test suite, just a subset)
[17:02] <rbasak> Also more (different) tests are run during dep8
[17:02] <rbasak> So if it made proposed migration, I assume they were passing at the time
[17:06] <rafaeldtinoco> rbasak: awesome.
[17:06] <rafaeldtinoco> tks.. ill work in current failures then.
[17:06] <rafaeldtinoco> its for the mysql-router MIR (security team asking)
[18:13] <Skuggen> rafaeldtinoco:I think we only enforce all tests passing for i386 and amd64, for MySQL
[18:30] <rafaeldtinoco> Skuggen: hum
[18:35] <cpaelzer> jamespage: https://launchpad.net/ubuntu/+source/dpdk/19.11-2ubuntu1 is in focal-proposed - but it will have to pass new queue after build before you can use it I guess
[18:35] <cpaelzer> all but arm64 are built for now, we can check tomorrow in which state it is to upload dependent packages
[21:04] <rafaeldtinoco> rbasak: CREATE EVENT e1 ON SCHEDULE AT '2020-01-01 00:00:00' DO SET @a = 1;
[21:04] <rafaeldtinoco> lol
[21:04] <rafaeldtinoco> we are at 2020 and the test is broken now
[21:04] <rafaeldtinoco> omg
[21:04] <rafaeldtinoco> i'll do a fix for those tests and do a MP for mysql-server
[21:04] <rafaeldtinoco> fixing the FTBS
[21:14] <rbasak> rafaeldtinoco: coordinate with Skuggen please - we should have an upstream bug for that
[21:15] <rbasak> rafaeldtinoco: and thank you for sorting it :)
[21:15] <rafaeldtinoco> rbasak: I think there is one already
[21:15] <rafaeldtinoco> I'll sync with him
[21:15] <rbasak> rafaeldtinoco: MP against the salsa branch please
[21:15] <rafaeldtinoco> definitely!