[08:51] <schopin> Are the various buildX versions overwritten when autosyncing from Debian or are they considered a new delta same as ubuntuX versions? So far I thought it was the former but I was unable to find doc on that.
[08:52] <RikMills> schopin: the former
[08:55] <schopin> Thanks!
[09:43] <seb128> schopin, I don't think it's properly documented but it probably should, that questions comes every now and then
[09:44] <seb128> schopin, it's basically coded in the sync script, https://git.launchpad.net/ubuntu-archive-tools/tree/auto-sync#n587
[10:43] <xypron> I am looking for a sponsor for https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958148
[10:43] <ubottu> Launchpad bug 1958148 in initramfs-tools (Ubuntu) "mkinitramfs is too slow" [Medium, Confirmed]
[11:24] <seb128> xypron, it feels like a default compression change for initramfs now would need a feature freeze exception since that's something that has an impact on the release
[11:28] <seb128> tseliot, hey, did you see that the recent ubuntu-drivers upload fails to build?
[11:29] <tseliot> seb128, it looks like a failure in umockdev: RROR **: 10:53:20.790: umockdev.vala:210: Cannot write attribute file: Failed to create file “/tmp/umockdev.6KDTI1/sys/devices/white/uevent.EUDTI1”: Too many open files
[11:30] <tseliot> Nothing that could really be caused by the upload
[11:41] <seb128> tseliot, I wonder if that's another side effect of the launchpad buildd update to focal?
[11:57] <tseliot> seb128, yes, it could be. The default max number of file descriptors must've been changed
[12:01] <ahasenack> morning
=== waveform_ is now known as waveform
[12:57] <ddstreet> sil2100 i'
[12:57] <ddstreet> ugh fat fingers, sorry
[12:58] <ddstreet> sil2100 i'd like to upload the debian version of knockd to jammy, it is a new version (0.8 instead of 0.7 in jammy) but all the changes are bug fixes, except for new support for ipv6; should i open a FFE?
[13:08] <ddstreet> actually looking at the 'new ipv6' support it's simply a bug fix for ipv6-only systems, no 'new' support for ipv6, so it's 100% bug fixes in the new version, i think i'm safe to upload
[13:09] <sil2100> ddstreet: hey! If you confirmed that this release only has bugfixes indeed, I'd say no FFe is needed - please proceed o/
[13:09] <ddstreet> thanks!
[13:18] <xypron> sil2100: Do you know who is responsible for creating the minimal Ubuntu images for Dockerhub? buildkit received RISC-V support last year.
[13:19] <sil2100> xypron: I think that would be the CPC team, most likely
[13:24] <xypron> philroche: ^ is your team responsible?
[13:54] <xypron> sil2100: There actually is a docker RISC-V upstream. I just needed to enable the RISC-V architechture in our docker.io package and I could run Ubuntu in a docker container. Great :)
[14:22] <rbasak> Is there a good example somewhere of packaging for ensuring a specific daemon user/group exists and is removed on purge correctly?
[14:22] <rbasak> I'm reviewing something for someone else and am a bit dubious because of all the edge cases around eg. LDAP and so on.
=== mfo_ is now known as mfo
[15:18] <xnox> rbasak:  piuparts does a check that ensures all of that is done correctly.
[15:24] <rbasak> Thanks!
[15:25] <rbasak> I found a few examples - openssh-server is a good one (in terms of presumed popcon and therefore likely correctness)
[15:49] <xypron> I am looking for a sponsor for LP #1963920 As this change is only adding a new package for the riscv64 architecture it should not require a feature freeze exception.
[15:49] <ubottu> Launchpad bug 1963920 in docker.io (Ubuntu) "riscv64 support missing" [Undecided, Confirmed] https://launchpad.net/bugs/1963920
[15:52] <rbasak> Maybe kanashiro or sergiodj could take a look please? ^
[15:52] <kanashiro> xypron, I can sponsor this upload for you, also update the github repo where we maintain the docker.io package. FWIW this package is maintained here: https://github.com/tianon/debian-docker/tree/ubuntu
[15:52] <rbasak> FWIW I'm not sure about that version number. But I'd want to check with others anyway as there might be more significant implicaitions
[15:52] <xypron> kanashiro: thanks. So I should create a pull-request on Github?
[15:53] <kanashiro> yes, the version number is wrong, it should be 20.10.12-0ubuntu3
[15:53] <kanashiro> xypron, that'd be helpful
[15:55] <kanashiro> xypron, I see the confusion about the version number, this is happening because of an upload with the wrong version number
[15:55] <xypron> kanashiro: is ubuntu or master the relevant branch? There seems to be no branch for jammy.
[15:56] <kanashiro> xypron, ubuntu branch is the target for the current development release
[15:59] <kanashiro> regarding the version number we can use 20.10.12-0ubuntu4 since ubuntu3 was already used
[16:06] <xypron> kanashiro: https://github.com/tianon/debian-docker/pull/17
[16:06] <ubottu> Pull 17 in tianon/debian-docker "Enable riscv64 architecture (LP: #1963920)" [Open]
[16:08] <kanashiro> xypron, thanks. I am in a meeting right now, I'll take a look at it later
[16:36] <kanashiro> xypron, I think we will need a FFe bug, I'd consider this new package as a new feature in riscv64
[16:36] <kanashiro> and we will also need to bother the release team to accept the package from the NEW queue once we upload it
[16:36] <xypron> kanashiro: isn't this simply a new package for RISC-V?
[16:37] <kanashiro> xypron, yes, but a new package brings new features IMO, get an ack from the release team would be better I think
[16:37] <kanashiro> and not too complex in this case
[16:37] <xypron> kanashiro: see https://wiki.ubuntu.com/FreezeExceptionProcess
[16:38] <xypron> kanashiro: "New source packages in the archive do not require feature freeze exceptions, as they must be explicitly opted into by users"
[16:41] <kanashiro> xypron, this sentence does not fully match with our case, because we are adding a new binary package and not source package. I agree the AAs will need to accept it anyway, let's try to at least talk to them first
[16:42] <xypron> kanashiro: I asked that exact question at 14:02 UTC on #ubuntu-release
[16:49] <kanashiro> xypron, I just read the backlog there, I'd expect an AA saying to go ahead with that
[16:49] <kanashiro> to comply with this: "For NEW uploads which are not syncs from Debian, please make sure you have the agreement of a member of ~ubuntu-archive to perform the necessary queue reviews before you upload."
[17:03] <xnox> binNEW != NEW
[17:03] <xnox> and binNEW on a new arch, i thought is autoaccepted.
[17:05] <kanashiro> xnox, thanks for the clarification
[17:11] <kanashiro> xypron, docker.io uploaded
[17:32] <rbasak> kanashiro: even if it turned out not to be needed, thank you for taking the cautious approach and asking :)
[19:17] <mwhudson> RikMills: i see you've been triggering glibc test failures as well, do you have any idea what is going on with libassuan and libgpg-error? other than it looks like the same problem
[19:19] <RikMills> mwhudson: not really. when I saw they were in main, so I couldn't retry only on the glibc trigger, I mentally shrugged and moved on
[19:20] <mwhudson> i guess i can retry locally
[19:20] <mwhudson> wine: for some mysterious reason, the wine server failed to run.
[19:20] <mwhudson> at least it's admitting this is a useless error messages
[19:20] <ahasenack> that was the actual message?
[19:20] <ahasenack> for a while I thought you were talking to a "wine" nick
[19:20] <mwhudson> ahasenack: yes https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/liba/libassuan/20220307_092740_d88c5@/log.gz
[19:20] <ahasenack> then I upgraded my understanding to you talking about wine
[19:21] <ahasenack> and finally that it's the actual message
[19:28] <mwhudson> heh