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