[09:54] <LocutusOfBorg> xnox, can you please consider merging gnupg2?
[10:23] <ackk> juliank, hi, around?
[10:28] <AsciiWolf> Wimpress, thanks for releasing the new steam package build! here is an appstream-generator page for the package in proposed repo: https://appstream.ubuntu.com/focal-proposed/multiverse/issues/steam-installer.html (it looks like the page wasn't generated yet, hopefully will be after some time)
[10:35] <LocutusOfBorg> xnox, gpgme1.0 is broken by it
[10:36] <LocutusOfBorg> I have it ready to upload
[10:38] <AsciiWolf> Wimpress, or maybe this page will be generated instead if there are no issues: https://appstream.ubuntu.com/focal-proposed/multiverse/metainfo/steam-installer.html
[11:21] <ackk> hi, could anyone please sponsor this upload for the maas package to focal https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/380426 ?
[11:28] <rbasak> xnox: I think bug 1861304 has emerged as a valid regression-update caused by the move to openssl 1.1. Am I right that there's nothing we can do in this case either?
[11:35] <xnox> rbasak:  i'm failing to parse your comment there.
[11:35] <xnox> rbasak:  libssl1.0-dev always existed in bionic. Both release pocket, and in the -updates pocket, as that's what src:openssh uses in bionic
[11:35] <rbasak> xnox: AIUI, this user used libmysqlclient-dev and libssl1.0-dev from the release pocket originally
[11:36] <rbasak> In a build that requires 1.0 and doesn't work with 1.1
[11:36] <xnox> rbasak:  let me look at libmysqlclient-dev
[11:36] <rbasak> And then we broke them by moving libmysqlclient-dev to 1.1
[11:36] <rbasak> There's no easy way out for this user without patching our packages.
[11:36] <xnox> rbasak:  libmysqlclient-dev in bionic-release pocket always required libssl-dev https://packages.ubuntu.com/bionic/libmysqlclient-dev
[11:36] <rbasak> Therefore I think it's a regression we introduced
[11:37] <rbasak> Oh, right.
[11:37] <rbasak> And libssl1.0-dev has always conflicted with libssl-dev?
[11:37] <xnox> rbasak:  but let me be sure with version numbers
[11:37] <juliank> ackk: looking
[11:37] <xnox> rbasak:  that is security version, not release.
[11:38] <rbasak> Oh
[11:38] <rbasak> At some point MySQL moved from embedded yassl to system openssl
[11:38] <rbasak> That's perhaps an additional interaction here
[11:38] <xnox> rbasak:  so i do see that bionic-release version 5.7.21 did not declare any libssl-dev deps
[11:38] <rbasak> I think that hit stable releases too
[11:39] <rbasak> xnox: thanks. That explains it
[11:39] <mdeslaur> libssl got introduced as a security update because upstream removed yassl
[11:39] <rbasak> I'll update the bug
[11:39] <xnox> rbasak:  but 5.7.20 uses system libssl-dev
[11:39] <xnox> rbasak:  now, the question i have if one can build and link things against mysqlclient-dev _without_ libssl-dev installed.
[11:40] <xnox> and i think for shared-library builds the answer is that one doesn't have to
[11:40] <juliank> ackk: Could you please fix your lintian warnings beforep ushing changes?
[11:40] <juliank> W: maas source: newer-debconf-templates
[11:40] <mdeslaur> xnox: I added libssl-dev to mysqlclient-dev because a bunch of things in the archive started FTBFS
[11:40] <xnox> rbasak:  https://paste.ubuntu.com/p/Dh8fYtQtcT/ this is pkg-config file for mysqlclient. It does declare Requires.private: openssl => but that's for static linking
[11:41] <xnox> mdeslaur:  hm, that is odd. Given that pkg-config file does not declare it =(
[11:41] <xnox> mdeslaur:  well i care about bionic
[11:42] <xnox> rbasak:  mdeslaur: it would be interesting to see if we can drop libssl-dev dep from libmysqlclient-dev _or_ if linking against ssl should be added in both Libs and Libs.private in the pkgconfig. It seems odd that pkg-config requires openssl, yet doesn't link against it..... as if libmysqlclient-dev includes openssl headers for like constants definitions.
[11:46] <ackk> juliank, thanks, done
[11:46] <xnox> rbasak:  it does seem like a regression. libmysqlclient-dev gained libssl-dev dependency, and we know that libssl-dev has conflicts in the archive.
[11:48] <rbasak> xnox: thank you for confirming
[11:48] <juliank> ackk: Uploaded
[11:49] <ackk> juliank, thanks!
[11:49] <xnox> rbasak:  but it is triggered by libmysqlclient-dev gaining that dep, I do wonder if libmysqlclient-dev is usable for example with libssl-dev | libss1.0-dev => that might be our escape hatch, if that doesn't affect api/abi of things that build against libmysqlclient-dev.
[11:52] <rbasak> Yeah maybe
[11:52] <rbasak> I'm not sure how to reliably test that for all cases, rather than just getting success with a lucy case
[11:52] <rbasak> lucky
[12:42] <AsciiWolf> Wimpress, it seems that the metadata are now correct: https://appstream.ubuntu.com/focal-proposed/multiverse/metainfo/steam-installer.html :-)
[12:42] <AsciiWolf> thanks!
[12:44] <AsciiWolf> it still does not show in gnome-software though (on a system with focal-proposed repo enabled), but I think that it just needs some time to sync the metadata
[13:15] <ahasenack> what's going on with libcrypt1? I'm getting dep8 errors because it cannot be installed
[13:15] <ahasenack>  slapd : Depends: libcrypt1 (>= 1:4.1.0) but it is not going to be installed
[13:15] <ahasenack> I know there was something around this being fixed yesterday
[13:15] <ahasenack> this test ran in the middle of the night
[13:15]  * ahasenack retries s390x, whch is faster
[13:18] <juliank> doko: ^
[13:19] <juliank> ahasenack: I'm afraid stuff might go wrong until libcrypt1 and libc6 have migrated
[13:22] <juliank> doko: I wonder if we should hack around libcrypt1 shlibs so linking to it continues to produce libc6 dependencies
[13:22] <juliank> then stuff in proposed would not get drawn into this mess
[13:25] <doko> juliank: won't work, libxcrypt is compatible with glibc's crypt, but not the other way around
[13:25] <doko> ahasenack: where dod you see that?
[13:26] <juliank> doko: yikes
[13:26] <ahasenack> doko: in my  openldap dep8 results, check the recent two fails: http://autopkgtest.ubuntu.com/packages/o/openldap/focal/amd64
[13:27] <juliank> ahasenack: you can retry with glibc trigger, it should work - aka produce neutral
[13:27] <ahasenack> I just retried s390x, no results yet: http://autopkgtest.ubuntu.com/packages/o/openldap/focal/s390x
[13:27] <doko> ahasenack: please add glibc/2.31-0ubuntu3 to the trigger
[13:27] <ahasenack> I see
[13:28] <ahasenack> ok, new s390x run triggered with that trigger
[13:28] <juliank> hmm
[13:29] <juliank> libxcrypt does not even use symbol versioing
[13:29] <xnox> doko:  ahasenack:  libcrypt1 dep, imho should also generate libc6 (>= 2.31) too
[13:29] <xnox> doko:  in libcrypt1.shlibs
[13:30] <juliank> AFAICT libxcrypt has a superset of libc6's libcrypt symbols
[13:30] <doko> xnox: how would that help?
[13:30] <juliank> so if code does not use the new symbols, shouldn't it be possible to use it against old libcrypt?
[13:30] <doko> ohh, I see, it would help for the autopkg tests
[13:31] <juliank> ah I guess it requires the XCRYPT_* symbol(s)
[14:03] <ahasenack> rbasak: hi, git master, I'm troubleshooting git signed tags and as far as I can see, it's a problem with pinentry, do you have any suggestions? https://pastebin.ubuntu.com/p/y7cZpr4QDg/
[14:03] <ahasenack> this is in a container
[14:07] <ahasenack> doko: the glibc trigger made it neutral indeed: http://autopkgtest.ubuntu.com/packages/o/openldap/focal/s390x
[14:07] <ahasenack> or rather, made it run
[14:07] <ahasenack> it was neutral already (the good case)
[14:08] <ahasenack> I'll do it for the rest
[14:08] <doko> mvo: could you have a look at https://bugs.launchpad.net/ubuntu/+source/piston-mini-client/+bug/1865960 ?
[14:09] <mvo> doko: yes, in a meeting right now but will have a look
[14:12] <ahasenack> rbasak: n/m, plain gpg isn't working
[14:12] <ahasenack> and I found an odd workaround: export GPG_TTY=$(tty)
[14:14] <AsciiWolf> https://bugs.launchpad.net/hundredpapercuts/+bug/1866841 - I think Ubuntu devs should consider adding this dependency to the ubuntu-desktop meta package
[15:06] <Eickmeyer[m]> Can I get a quick merge on an update to the Ubiquity Slideshow for Ubuntu Studo? https://code.launchpad.net/~eeickmeyer/ubiquity-slideshow-ubuntu/ubuntustudio/+merge/380461
[15:35] <seb128> LocutusOfBorg, hey, your snowball upload is buggy, it doesn't fail to build but
[15:35] <seb128> Checking output of danish stemmer with ISO_8859_1
[15:35] <seb128> /bin/sh: 1: python: not found
[15:35] <seb128> /bin/sh: 1: python: not found
[15:35] <seb128> etc etc etc
[15:35] <seb128> unsure if that impacts any of the generated file/the package or just fail tests which fail to fail the build :)
[16:27] <ricotz> mwhudson, hi, please copy the packages from ubuntu-mozilla-security/rust-updates to rust-next
[17:00] <xnox> LocutusOfBorg:  so my gnupg2 upload is now rejected
[17:01] <xnox> LocutusOfBorg:  i'm slightly confused why you do duplicate work and ask me to do duplicate work too =)
[17:28] <LocutusOfBorg> xnox, I thought you were not interested sorry, I didn't get an answer, but I have no bnc, so meh
[17:28] <LocutusOfBorg> seb128, so, no regression lol
[17:28] <LocutusOfBorg> tumbleweed, ^^ will fix
[17:29] <tumbleweed> LocutusOfBorg: ta. I assumed you'd tested :)
[17:29] <LocutusOfBorg> tumbleweed, I just applied the Ubuntu delta
[17:34] <LocutusOfBorg> tumbleweed, I'm going to upload the current salsa.d.o master/debian branch
[17:34] <LocutusOfBorg> your changes are cosmetic but better take them, right?
[17:39] <LocutusOfBorg> seb128, can you please ack this? https://launchpad.net/ubuntu/+source/snowball/0+svn585-2~build1
[17:43] <LocutusOfBorg> in any case seb128 a package that fails tests and doesn't fail build is sad, always sad
[17:45] <xnox> LocutusOfBorg:  i was making d-i migrate without glibc, then had a gnupg2 upload staged
[17:47] <LocutusOfBorg> oh... I thought you didn't care about the package, I see a lot of uploaders that did the last merge, so looks like everybody does it but not caring enough to do it many times
[19:25] <seb128> LocutusOfBorg, the changes look fine to me, note that upstream fixed it by switching to call iconv instead of using python there, ideally Debian would get a non outdated version of that package
[20:31] <LocutusOfBorg> seb128, mitya57 is working already on the new release
[20:31] <mitya57> probably not for focal anyway
[20:37] <mwhudson> ricotz: olivier ususally does that i think...
[21:25] <ricotz> mwhudson, he isn't around, I asked him yesterday but I assume he missed it
[21:45] <mwhudson> ricotz: ok, i'm sure i can figure it out :)
[21:45] <mwhudson> ricotz: i presume it's usually copy with binaries?
[21:46] <ricotz> mwhudson, yes, no rebuild is needed
[22:24] <ricotz> mwhudson, ?
[22:24] <mwhudson> ricotz: sorry, calls
[22:27] <mwhudson> afk for 5 now but will try not to forget when i get back
[22:33] <ricotz> mwhudson, alright
[22:39] <mwhudson> the next step is remembering how copy-package works, of course
[22:40] <mwhudson> ricotz: ok done i think
[22:41] <mwhudson> (well publishing still needs to happen)
[22:43] <ricotz> mwhudson, thanks!