| 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:51 |
|---|---|---|
| RikMills | schopin: the former | 08:52 |
| schopin | Thanks! | 08:55 |
| seb128 | schopin, I don't think it's properly documented but it probably should, that questions comes every now and then | 09:43 |
| seb128 | schopin, it's basically coded in the sync script, https://git.launchpad.net/ubuntu-archive-tools/tree/auto-sync#n587 | 09:44 |
| 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] | 10:43 |
| 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:24 |
| seb128 | tseliot, hey, did you see that the recent ubuntu-drivers upload fails to build? | 11:28 |
| 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:29 |
| tseliot | Nothing that could really be caused by the upload | 11:30 |
| seb128 | tseliot, I wonder if that's another side effect of the launchpad buildd update to focal? | 11:41 |
| tseliot | seb128, yes, it could be. The default max number of file descriptors must've been changed | 11:57 |
| ahasenack | morning | 12:01 |
| === waveform_ is now known as waveform | ||
| ddstreet | sil2100 i' | 12:57 |
| ddstreet | ugh fat fingers, sorry | 12:57 |
| 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? | 12:58 |
| 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:08 |
| 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:09 |
| xypron | sil2100: Do you know who is responsible for creating the minimal Ubuntu images for Dockerhub? buildkit received RISC-V support last year. | 13:18 |
| sil2100 | xypron: I think that would be the CPC team, most likely | 13:19 |
| xypron | philroche: ^ is your team responsible? | 13:24 |
| 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 :) | 13:54 |
| 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. | 14:22 |
| === mfo_ is now known as mfo | ||
| xnox | rbasak: piuparts does a check that ensures all of that is done correctly. | 15:18 |
| rbasak | Thanks! | 15:24 |
| rbasak | I found a few examples - openssh-server is a good one (in terms of presumed popcon and therefore likely correctness) | 15:25 |
| 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:49 |
| 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:52 |
| kanashiro | yes, the version number is wrong, it should be 20.10.12-0ubuntu3 | 15:53 |
| kanashiro | xypron, that'd be helpful | 15:53 |
| 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:55 |
| kanashiro | xypron, ubuntu branch is the target for the current development release | 15:56 |
| kanashiro | regarding the version number we can use 20.10.12-0ubuntu4 since ubuntu3 was already used | 15:59 |
| 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:06 |
| kanashiro | xypron, thanks. I am in a meeting right now, I'll take a look at it later | 16:08 |
| 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:36 |
| 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:37 |
| xypron | kanashiro: "New source packages in the archive do not require feature freeze exceptions, as they must be explicitly opted into by users" | 16:38 |
| 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:41 |
| xypron | kanashiro: I asked that exact question at 14:02 UTC on #ubuntu-release | 16:42 |
| 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." | 16:49 |
| xnox | binNEW != NEW | 17:03 |
| xnox | and binNEW on a new arch, i thought is autoaccepted. | 17:03 |
| kanashiro | xnox, thanks for the clarification | 17:05 |
| kanashiro | xypron, docker.io uploaded | 17:11 |
| rbasak | kanashiro: even if it turned out not to be needed, thank you for taking the cautious approach and asking :) | 17:32 |
| 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:17 |
| 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:19 |
| 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:20 |
| ahasenack | and finally that it's the actual message | 19:21 |
| mwhudson | heh | 19:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!