=== genii is now known as genii-meeting
=== genii-meeting is now known as genii-core
=== alan_g_ is now known as alan_g
[10:59] <bluca> juliank: qq, are the non-x86 cloud autopkgtest running on baremetal of the respective architecture?
[10:59] <bluca> or are they all virtualized?
[10:59] <bluca> on top of x86 I mean
[11:00] <juliank> bluca: they run on vms of their respective architecture; except armhf which runs in lxd in arm64 vms
[11:00] <juliank> bluca: it's all openstack
[11:00] <bluca> got it, thank you
[11:00] <cjwatson> specifically VMs running on compute nodes of the corresponding architecture
[11:00] <cjwatson> not emulated by x86
[11:01] <juliank> yes that's what I thought I'd wrote
[11:01] <juliank> ugh grammar
[11:01] <bluca> thank you both
[11:01] <cjwatson> yeah, I could just have read "vms of their respective architecture" as talking about either the host or the guest :)
[11:02] <juliank> hmm I gotta investigate arm64
[11:03] <juliank> it's error rate is a bit high
[11:04] <juliank> ah yes
[11:04] <juliank> they die after a reboot after EFI stub: Exiting boot services and installing virtual address map...
[11:04] <juliank> I think it could be that this is the grub bug with random memory even
[11:06] <juliank> We are currently allocating just enough memory for the file size,
[11:07] <juliank> +which means that the kernel BSS is in limbo (and not even zeroed).
[11:57] <ahasenack> good morning
[13:46] <ahasenack> rbasak: hi, could you please check the git-ubuntu importer wrt sssd? 2.6.3 was published on the 15th, but ubuntu/devel still points at 2.6.1
[13:46] <ahasenack> https://launchpad.net/ubuntu/+source/sssd/2.6.3-1ubuntu1
[13:46] <ahasenack> https://code.launchpad.net/~git-ubuntu-import/ubuntu/+source/sssd/+git/sssd/+ref/ubuntu/devel
[13:49] <rbasak> ahasenack: it's in the queue. I can bump the priority for you
[13:50] <rbasak> Looks like git-ubuntu was swamped by language-pack-* uploads
[13:50] <rbasak> I've deprioritized those
[13:50] <rbasak> And I've bumped sssd so that'll be next when a worker slot becomes free
[13:52] <ahasenack> thanks rbasak
[14:01]  * ahasenack wonders why nfs-ganesha is in main
[14:01] <ahasenack> two nfs servers in main
[14:05] <rbasak> ahasenack: https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=8f973f0ded862784639d4567791832a5640fa402
[14:05] <ubottu> Commit 8f973f0 in ~ubuntu-core-dev/ubuntu-seeds/+git/platform "Seed nfs-ganesha-ceph for general storage and openstack usage"
[14:05] <ahasenack> oh
[14:07] <ahasenack> jumped into main during focal
[14:08] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/nfs-ganesha/+bug/1843403
[14:08] <ubottu> Launchpad bug 1843403 in ntirpc (Ubuntu) "[MIR] nfs-ganesha, ntirpc" [High, Fix Released]
[14:40] <rbasak> Is the change to OpenSSL 3.0 also making changes to acceptable/available ciphersuites?
[14:42] <schopin> rbasak: it does.
[14:42] <schopin> Many algorithms were moved to a "legacy" provider that must be explicitly enabled
[14:47] <schopin> rbasak: although... given our default security level, that last part might not have an impact on the actual suites available?
[14:54] <rbasak> schopin: I'd like to understand what's changed from a user's perspective, including what must now be explicitly enabled and what is no longer available. Is there a summary available anywhere, please?
[14:55] <GunnarHj> Hi cjwatson, did you see jbicha's question yesterday?
[14:55] <GunnarHj> https://irclogs.ubuntu.com/2022/02/16/%23ubuntu-devel.html#t13:26
[14:55] <schopin> rbasak: I'm only aware of https://www.openssl.org/docs/manmaster/man7/migration_guide.html
[14:56] <rbasak> schopin: thanks. Does that mean we're following the upstream default? I was under the impression we customised the default config.
[14:58] <schopin> I haven't checked this in a while, but I think we "just" raise the default security level, and now that I'm saying this I'm not even sure we're differing from upstream now. I'll go check
[15:02] <schopin> rbasak: OK, so Ubuntu default to security level 2, while upstream is at level 1. In addition, we patched OpenSSL to disallow TLS < 1.2 at level 2 (which is a restriction normally for sec level 4).
[15:03] <schopin> THat's the extent of our customization.
[15:04] <rbasak> schopin: that's exactly what I needed. Thanks!
[15:04] <rbasak> schopin: on, and when did the disallow TLS < 1.2 at level 2 appear in Ubuntu please?
[15:04] <rbasak> Is that new in Jammy / OpenSSL 3.0?
[15:05] <schopin> No, it's from 1.1.1d-2ubuntu2 uploaded in 20.04
[15:06] <rbasak> OK thanks!
[15:09] <rbasak> schopin: can I request that this info goes into the release notes please? I wrote https://bugs.launchpad.net/ubuntu-release-notes/+bug/1961268 for now
[15:09] <ubottu> Launchpad bug 1961268 in Release Notes for Ubuntu "OpenSSL changes" [Undecided, New]
[15:11] <schopin> rbasak: noted. Are the release notes subject to a freeze?
[15:12] <rbasak> schopin: no not at all. Edit at any time.
[15:13] <bdmurray> schopin: sometimes they get edited after release! ;-)
[15:20] <ogayot> hello, I'm looking for a sponsor for the merge of python-testtools (main) LP #1960297). Thanks!
[15:20] <ubottu> Launchpad bug 1960297 in python-testtools (Ubuntu) "Please merge python-testtools 2.5.0-3 (main) from Debian unstable (main)" [Undecided, Confirmed] https://launchpad.net/bugs/1960297
[15:36] <jawn-smith> ogayot: looking
[15:36] <ogayot> Thanks jawn-smith!
=== seb129 is now known as seb128
=== genii-core is now known as genii
[15:47] <jawn-smith> ogayot: This looks good to upload, but it would probably be good practice to submit a patch to Debian declaring the packages as 3.10 compatible so we can sync more quickly. As long as it's not super complicated.
[15:50] <ogayot> jawn-smith: that sounds good to me, thanks!
[18:19] <rbasak> doko: does openstructure need a rebuild? libost-info2.3 depends on libboost-regex1.74.0-icu67 and that's the latest build on amd64. But I'm a bit puzzled as it looks like you did all the others, so why did that one get missed? Thought I'd check with you first.
[19:17] <Laibsch> why is python3-httpx package no longer synced from unstable or even testing?
[19:19] <Laibsch> https://launchpad.net/ubuntu/+source/httpx/0.21.1-1/+build/22469845: missing build-dependency
[19:20] <ahasenack> correct
[19:20] <ahasenack> which leads to this build failure on the missing dep: https://launchpad.net/ubuntu/+source/httpcore/0.14.3-1
[19:21] <ahasenack> related to python 3.10 and/or openssl 3
[19:22] <ahasenack> (my guess)
[19:31] <Laibsch> Thanks.  So, what keeps python3-click stuck in proposed, then?  It's another build-time dependency that would not be fulfilled even if python3-httpcore was.
[19:34] <Laibsch> https://launchpad.net/ubuntu/+source/python-click/8.0.3-1 vs. https://launchpad.net/ubuntu/+source/python-click/7.1.2-1
[19:37] <dbungert> python-click was related to problems with mailman3 - LP: #1960547, not sure about current state
[19:37] <ubottu> Launchpad bug 1960547 in mailman3 (Ubuntu) "please remove mailman3, mailman-hyperkitty" [Undecided, Fix Released] https://launchpad.net/bugs/1960547
[19:44] <Laibsch> Thanks, dbungert.  Looks like simply someone needs to frob the knob to get python3-click to migrate now.
[19:47] <Laibsch> as is httpx is completely broken jammy, due to newer release not migrating: bug 1961340
[19:47] <ubottu> Bug 1961340 in httpx (Ubuntu) "httpx in jammy is broken" [Undecided, New] https://launchpad.net/bugs/1961340
[19:50] <ahasenack> I triggered a retest on python-canmatrix, seems the only red under python-click (s390x)
[19:50] <ahasenack> the failure seems to be dependency related, and is old
[19:51] <ahasenack> result will show up at the top row here: https://autopkgtest.ubuntu.com/packages/python-canmatrix/jammy/s390x
[20:02] <Laibsch> Thx.  So, a rebuild attempt will usually be triggered automatically, without manual intervention?  I previously saw nothing holding python-click back.
[20:04] <Laibsch> Thus, I assumed the need for some explicit frobbing
[20:08] <ahasenack> I'm not sure, I've seen rebuilds happening without me touching them, but someone else might have
[20:18] <ahasenack> python-click should migrate now in the next run
[20:19] <ahasenack> but this is unrelated to httpx, right?
[20:20] <ahasenack> or is httpcore failing because of the old python-click?
[20:20] <ahasenack> the build used the new one:
[20:20] <ahasenack> Get:30 http://ftpmaster.internal/ubuntu jammy-proposed/main amd64 python3-click all 8.0.3-1 [78.3 kB]
[20:53] <cjwatson> GunnarHj: I thought I said I wasn't going to have time to look into it, sorry
[20:54] <cjwatson> Oh I guess the fonts section question is a bit different.  I don't know how you could avoid that hack though
[21:21] <GunnarHj> cjwatson: I think we wonder if there is a way to make LP accept the hack.
[21:21] <cjwatson> GunnarHj: Is it even really about LP though?  The discrepancy seems to be entirely contained within stuff that sbuild runs - it's just that LP notices it and complains
[21:21] <cjwatson> GunnarHj: i.e. the .changes says non-free/fonts
[21:22] <cjwatson> Need to persuade that to come out right somehow, and then LP will be happy
[21:23] <GunnarHj> cjwatson: On Debian the problem does not show up, since the hack isn't run there.
[21:23] <cjwatson> I forget which bit of the packaging toolchain it is that populates debian/files
[21:23] <cjwatson> But it's likely that
[21:24] <cjwatson> I mean, you should be able to completely reproduce this outside Launchpad by doing a normal build in sbuild or whatever and then checking the generated .changes afterwards
[21:24] <GunnarHj> cjwatson: Maybe let the hack change d/control directly instead. I'll try that.
[21:24] <cjwatson> That's probbaly worse
[21:24] <cjwatson> I will have a look, but not right now, need to do bedtime
[21:26] <GunnarHj> cjwatson: Ok, sweet dreams, and thanks.
[22:04] <jbicha> it's not really possible to have the .dsc be different between Debian & Ubuntu if the point is to autosync
[22:06] <jbicha> I think this is a rare enough case that we might as well just have an Ubuntu diff. fonts-ubuntu doesn't get frequent updates
[22:26] <cjwatson> jbicha: Yeah, I've tried a few things like substvars (which don't work here) and sedding debian/files (which causes dpkg-genchanges to complain about the mismatch).  sedding debian/control might work to some extent, but it's really gross and Package-List in the .dsc would unavoidably still be wrong (Launchpad doesn't care about that, but some other tools might).  I think accepting the delta is ...
[22:26] <cjwatson> ... probably the only thing for it.
=== genii is now known as genii-core