[01:58] <mwhudson> uhh
[01:58] <mwhudson> (ubuntu/devel)mwhudson@anduril:~/src/pkg/py38/libguestfs$ pkg-config --libs python-3.8
[01:58] <mwhudson> (ubuntu/devel)mwhudson@anduril:~/src/pkg/py38/libguestfs$
[01:58] <mwhudson> that's not right?
[02:06] <mwhudson> oh i see maybe it is
[07:54] <dupondje> Hmmmm, just found something minor: https://launchpad.net/ubuntu/+source/openjpeg2 . The version in bionic is higher then version in disco/eoan
[07:54] <dupondje> Causes not to get upgraded on dist-upgrade
[07:55] <dupondje> ebarretto: ^
[08:00] <seb128> dupondje, the content is the same though so shouldn't be an issue right?
[08:06] <RikMills> I guess would only be if the -2 in disco was part of another library transition
[08:14] <Laney> ddstreet: :(((( is there a bug report for that issue?
[08:18] <dupondje> seb128: Don't think its really an issue indeed, just feels not clean. I always do a aptitude purge ~o after a dist-upgrade
[08:18] <dupondje> and popped up :)
[08:18] <seb128> right
[11:49] <seb128> doko, hey, do you have any post explaining why dh-exec hacks like the one from https://launchpad.net/ubuntu/+source/pygobject/3.34.0-1ubuntu1 are needed with python3.8? also do you plan to forward those patches to the Debian BTS?
[11:51] <ddstreet> Laney the patch to systemd's test references lp: #1748280, but that doesn't sound like what i see on canonistack in bos01; so maybe scalingstack doesn't have the same problem, but still takes 'too long' on some reboots, though i don't really know since i dont have access to scalingstack
[11:55] <seb128> mwhudson, hey, https://launchpad.net/ubuntu/+source/cracklib2/2.9.6-2ubuntu1 ... the changelog neither explain why  that diff is being added while the package was in sync/why it's needed, also it seems it could/should be forwarded to Debian. Can you please do that?
[11:57] <doko> seb128: because it's not yet clear of dh-python can handle that
[11:58] <doko> and all the mess, because 3.8 drops the m modifier
[11:58] <seb128> doko, shouldn't we figure that upfront? rather than adding ubuntu delta?
[12:04] <rbasak> ahasenack: good morning! I'm reviewing acme and certbot currently. Apart from my reviews, do you consider everything ready to upload now?
[12:05] <rbasak> Both acme and certbot I assume - for Xenial and Bionic at least?
[12:05]  * rbasak ponders Disco and Eoan
[12:05] <ahasenack> rbasak: certbot is xenial and bionic, acme is xenial, bionic, disco
[12:06] <ahasenack> rbasak: I don't have other planned changes, other than review comments
[12:07] <rbasak> ahasenack: OK, so for acme that's andreas-guest/ubuntu-{xenial,bionic,disco}-andreas-review right?
[12:07] <ahasenack> rbasak: yes, you should see ec0's branch ref in there too if you have it
[12:07] <ahasenack> and my changes on top of his
[12:07] <ahasenack> the hashes from ec0 match what you reviewed last from him
[12:09] <rbasak> ec0's branch tips don't seem to be ancestors
[12:10] <ahasenack> rbasak: this is what I see on my xenial review branch: https://pastebin.ubuntu.com/p/Zzz4BcxCTP/
[12:10] <ahasenack> salsa-andreas/ubuntu-xenial is ec0's
[12:11] <ahasenack> my fork of his branch
[12:11] <rbasak> ahasenack: this is what I see: https://pastebin.ubuntu.com/p/sYXq3WjdDn/
[12:12] <rbasak> (and more commits after that)
[12:12] <rbasak> That's the fork point.
[12:12] <rbasak> It's fine
[12:12] <ahasenack> rbasak: he force-pushed I think
[12:12] <ahasenack> his "Updated build dependencies to build on Ubuntu Xenial"
[12:12] <ahasenack> you have e8782808a49a5657067b96aed18124be6b76c170 from aug 20th
[12:13] <ahasenack> last one is at Sep 21 21:50:56 2019 +1000
[12:25] <LocutusOfBorg> hello mitya57, https://buildd.debian.org/status/package.php?p=qtbase-opensource-src&suite=unstable looks like we have a bootstrap issue on arch:all?
[12:25] <LocutusOfBorg> (sorry for using ubuntu channels, I didn't see you on oftc/#debian-devel)
[12:32] <ahasenack> rbasak: what is that openssl 1.1.1 tag for bionic again?
[12:32] <ahasenack> got another bug
[12:34] <rbasak> ahasenack: bionic-openssl-1.1 thanks
[12:39] <ebarretto> dupondje, sorry about that, I will get openjpeg2 rebuilt for disco/eoan
[12:47] <dupondje> ebarretto: np :) just a minor thing I noticed :)
[12:47] <dupondje> the tag should have been +build1 I suppose instead of build1 :)
[12:52] <ebarretto> dupondje, actually ~build1
[12:52] <ebarretto> ~ is lower than 2.3.0-2 and + is greater
[12:53] <dupondje> aha k :)
[13:33] <rbasak> ahasenack: +1 for both your acme and certbot branches, both for peer review and also for SRU accept
[13:33] <rbasak> ahasenack: would you like to upload them? If you're not around, I can "sponsor" them
[13:34] <ahasenack> rbasak: I'm here
[13:34] <ahasenack> rbasak: I'll do it in a bit, could you please just confirm the hashes you +1ed?
[13:35] <ahasenack> maybe in the ~canonical-server mps, for certbot?
[13:38] <rbasak> ahasenack: actually the MPs for certbot have the wrong target branches, so I was ignoring them.
[13:38] <rbasak> Let me put the hashes here
[13:39] <ahasenack> rbasak: I wasn't sure how to target correctly, since these are backports
[13:39] <ahasenack> I started from, say, cosmic-devel, and added changes for it to build on, say, xenial
[13:39] <ahasenack> but that won't merge with xenial, there will be conflicts
[13:40] <rbasak> acme: xenial 0907ce1; bionic 68149a9; disco a928edd
[13:40] <rbasak> certbot: xenial 2fbc42e; bionic 97de715
[13:41] <rbasak> I will check that the uploads match those before SRU accept
[13:41] <rbasak> ("git ubuntu queue sync" makes it easy)
[13:41] <rbasak> ahasenack: maybe best to avoid upload tags on these then?
[13:42] <rbasak> I would base on the unapplied import tags of the backport source versions to preserve history.
[13:42] <rbasak> I thought you did that for certbot at least
[13:43] <rbasak> IIRC the acme branches are based on Debian VCS which won't be in git-ubuntu
[13:43] <ahasenack> rbasak: right, acme I didn't start over
[13:43] <rbasak> I suggest upload tags for certbot then, but not acme
[13:43] <rbasak> (to be clear, you did exactly what I'd expect)
[13:43] <ahasenack> ok
[13:43] <ahasenack> I was wondering about upload tags
[13:43] <ahasenack> for certbot (the git-ubuntu based one)
[13:54] <ahasenack> rbasak: will you add something to the mps, or can I just paste this conversation there?
[13:55] <rbasak> ahasenack: sorry, I didn't realise you were waiting. Go ahead and paste this conversation there if you like?
[13:55] <rbasak> I see what you mean about the target branches now.
[13:56] <ahasenack> ok
[13:56] <ahasenack> thanks for the reviews
[13:56] <ahasenack> rbasak: about target branches, it's like a merge from debian. The targed branch is debian/sid, but we are not really merging into that
[13:56] <rbasak> Right, I follow now :)
[13:56] <rbasak> It's because we have been overloading the target branches to get the preview diff right
[13:57] <rbasak> Whereas this morning I tried to identify the MPs by target branch, which of course doesn't work with us doing that overloading.
[13:57] <ahasenack> yeah
[13:58] <ahasenack> rbasak: one more thing, for the changes file, should I use -v with the version in the target release?
[13:59] <ahasenack> for example, certbot in xenial is 0.23.0-1~ubuntu16.04.1
[13:59] <ahasenack> and we are backporting cosmic's 0.27.0-1
[14:01] <rbasak> Good question!
[14:02] <rbasak> I suppose that yes, that would be the most accurate.
[14:02] <rbasak> Although
[14:03] <rbasak> Actually, if there are any extra LP bug references, that might cause extra bugs to appear in the pending-sru report.
[14:03] <rbasak> So now I don't have a good answer. I don't think it'll be particularly bad either way though, so I'll accept both unless someone tells me otherwise.
[14:03] <rbasak> We can ignore any extra bugs in pending-sru easily enough.
[14:04] <rbasak> And it'd be right to autoclose them if any of those bugs have open series tasks anyway.
[14:10] <ahasenack> let me check the endresult of the changes file
[15:02] <doko> jamespage, coreycb: why does ceph b-d on python3-all-dev ?
[15:18] <jamespage> doko: I suspect that's a legacy thing - python3-dev should be sufficient as it only targets the default python3 version
[15:23] <vorlon> oSoMoN: hi, so after the chromium deb->snap transition, all of my data appears to have been cleanly migrated to ~/snap/chromium/current/.config/chromium, however none of my saved passwords are available to the browser despite the sqlite db being present in the config.  Any hints?
[15:24] <vorlon> oSoMoN: (this is with in-browser password store, not synced to google account)
[15:56] <ahasenack> rbasak: certbot and acme uploaded
[16:21] <mitya57> LocutusOfBorg: it will auto-solve itself
[16:22] <mitya57> Actually, already solved
[16:22] <mitya57> But please don't copy that to Ubuntu yet, I will do that myself
[16:59] <rbasak> cyphermox: the ubuntu-server packageset has never had upload right delegated; that's all. Nobody requested it and nobody felt the need I guess.
[16:59] <rbasak> rafaeldtinoco, marcustomlinson: congrats!
[17:00] <rafaeldtinoco> rbasak: Thx Robie!
[17:03] <Odd_Bloke> Given it's in universe and in sync with Debian, I don't know if anyone is paying attention to apt-file issues, but I just hit https://bugs.launchpad.net/ubuntu/+source/apt-file/+bug/1848768 in eoan and it has 3 other reporters too.
[17:08] <marcustomlinson> rbasak: thanks :)
[17:21] <rbasak> ahasenack: all accepted now, thanks! With build-deps correctly bumped, I expect the python-certbot builds to hit dep-wait until the python-acme builds are published
[17:22] <ahasenack> yep
[20:13] <infinity> vicamo, tseliot: The changelog on that backport-iwlwifi-dkms upload alters history to claim the previous upload was in focal, not eoan.  Please fix that and reupload.
[20:14] <tseliot> infinity, I'll have a look and fix it, thanks
[20:15] <infinity> tseliot: Ta.
[20:21] <andrewsh> reposting again since apparently the Matrix gate lost messages (?)
[20:21] <andrewsh> https://translations.launchpad.net/apport/trunk/+pots/apport/sk/+translate?field.alternative_language=cs&field.alternative_language-empty-marker=1&show=untranslated&memo=10&start=10
[20:21] <andrewsh> I just noticed there’s a lot of translations
[20:21] <andrewsh> some of them hang there unaccepted for many years
[20:21] <andrewsh> what can be done about that?
[21:07] <mwhudson> seb128: yes, that should probably go to debian
[21:07] <mwhudson> seb128: i'm a little bit uncertain about all this stuff
[21:10] <lvh> Hi! Given a JSON-formatted USN entry (from database-all.json.bz2), how do I figure out if a particular release was never affected by an USN in the first place vs if it still needs a patch but it's not available yet?
[21:18] <lvh> I think it's "the release is present as a key in the 'releases' object but no version is listed" but I'm not sure. That's certainly how the USN website appears to generate the HTML
[21:20] <sarnold> hey lvh
[21:21] <lvh> Hi :)
[21:21] <sarnold> lvh: so, I'm about to head off to lunch.. and just moments ago pushed an update for that file
[21:22] <sarnold> lvh: (a) probably #ubuntu-hardened will have more folks around who know that file (b) can you pastebin up what you're seeing that's causing trouble?
[21:23] <lvh> Oh, it's not so much having trouble with any particular part of the file as making sure that I am correctly interpreting what that file is actually saying
[21:23] <sarnold> aha :)
[21:24] <lvh> Enjoy your lunch! I'm going to ask #ubuntu-hardened :)
[21:24] <sarnold> thanks :)
[22:10] <hallyn> when will archive re-open?  just looking for someone (maybe me) to sync edbrowse from debian :)
[22:14] <mwhudson> hallyn: couple days
[22:16] <hallyn> thanks
[22:16] <jbicha> hallyn: it will auomatically sync to Focal soon since there aren't Ubuntu-specific changes
[22:17] <hallyn> ah, ok
[22:17] <hallyn> so i'm not needed :)  excellent
[22:17] <hallyn> \o
[22:21] <jbicha> I mean I appreciate you 😄 😃
[22:22] <hallyn> lol :)