| -queuebot:#ubuntu-release- New binary: linux-signed-dell300x [amd64] (bionic-proposed/universe) [4.15.0-1014.18] (no packageset) | 00:02 | |
| -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (groovy-proposed) [1.0.0~rc93-0ubuntu1~20.10.1] | 00:05 | |
| -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (focal-proposed) [1.0.0~rc93-0ubuntu1~20.04.1] | 00:07 | |
| -queuebot:#ubuntu-release- Unapproved: accepted runc [source] (bionic-proposed) [1.0.0~rc93-0ubuntu1~18.04.1] | 00:10 | |
| === ahayzen_ is now known as ahayzen | ||
| -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1067.75~16.04.1] | 04:26 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-dell300x [amd64] (bionic-proposed) [4.15.0-1014.18] | 04:27 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1067.75] | 04:27 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-139.143~16.04.1] (kernel) | 05:00 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-139.143~16.04.1] (kernel) | 05:01 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-139.143~16.04.1] | 05:03 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-139.143~16.04.1] | 05:03 | |
| === juergh` is now known as juergh | ||
| amurray | tjaalton: hey, just wondering if you could sponsor my SRU for libseccomp to -proposed - https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810 | 07:17 |
|---|---|---|
| ubot5 | Ubuntu bug 1891810 in libseccomp (Ubuntu Groovy) "Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers" [Medium,Confirmed] | 07:17 |
| tjaalton | amurray: I can either sponsor the upload or review from the queue, not both | 07:19 |
| amurray | tjaalton: oh perhaps I am confused - so I have debdiffs attached in the bug, (or packages in the ubuntu-security-proposed PPA of the same) which I believe I first need to get into -proposed as part of the SRU process - I thought the process was to get these sponsored by someone from the SRU team - can you clarify? | 07:21 |
| tjaalton | they need to be uploaded to the sru queue for review | 07:22 |
| tjaalton | which they are not | 07:22 |
| amurray | oh ok, can you do that? | 07:22 |
| tjaalton | sure, but can't review them myself | 07:22 |
| tjaalton | needs another pair of eyes | 07:22 |
| amurray | fair enough - thanks - so is there anything different I should do next time? I saw on the wiki that it says 'if you can upload then do it' effectively - so would it be better next time to get someone who is core-dev or similar to upload them direct to -proposed next time? | 07:25 |
| tjaalton | they don't get uploaded to -proposed, but to the queue | 07:25 |
| tjaalton | but yes, needs someone to actually upload | 07:26 |
| amurray | oh ok. I think I need to go re-read the wiki page then, I've obvs got the wrong end of the stick - thanks again for your help | 07:26 |
| amurray | so once they're in the queue someone from the SRU team will review them and then (assuming they are happy with them) sponsor them to -proposed? | 07:27 |
| amurray | also when you say 'the queue' do you mean 'unapproved'? | 07:27 |
| tjaalton | yes | 07:27 |
| tjaalton | the tooling then moves the pkg to be built in proposed | 07:28 |
| amurray | ok I think I get it now. again, thanks for your help. | 07:28 |
| amurray | sorry I gotta go pick my daughter up but will check scrollback later | 07:28 |
| amurray | cheers | 07:28 |
| tjaalton | np | 07:31 |
| -queuebot:#ubuntu-release- Unapproved: bluez (focal-proposed/main) [5.53-0ubuntu3 => 5.53-0ubuntu3.1] (i386-whitelist, ubuntu-desktop) | 08:37 | |
| paravoid | I was asking #ubuntu-devel the other day - I maintain a package in Debian (and am not very knowledgeable in Ubuntu processes) | 11:23 |
| paravoid | the package is gdnsd, and has migrated from sid to bullseye a while ago | 11:24 |
| paravoid | it is not migrating to hirsute, because autopkgtests fail in Ubuntu (but not in Debian) | 11:24 |
| paravoid | the issue is that in two of the tests, marked with isolation-container, it sets up a DNS server on INADDR_ANY:53, but in Ubuntu containers systemd-resolved listens on localhost:53 | 11:25 |
| paravoid | this is related to (but not the same as) LP #1764327 - and upstream is trying to address this with https://github.com/gdnsd/gdnsd/commit/6958918936d528d3daa6366036fbf44a02cbb234 | 11:25 |
| ubot5 | Launchpad bug 1764327 in gdnsd (Ubuntu) "gdnsd fails to start, as it tries to listen to [::]:53" [High,Triaged] https://launchpad.net/bugs/1764327 | 11:25 |
| paravoid | but it's going to take a major release to fix as to not break existing configs | 11:25 |
| paravoid | anyway, long story short, I don't see an easy fix right now, and certainly not one that would pass through Debian's hard freeze | 11:26 |
| paravoid | at the same time it'd be a pity if Ubuntu released with 2.4.2 which is very old at this point (sid is at 3.5.2) | 11:26 |
| paravoid | I'd propose for Ubuntu RMs to either a) force-badtest gdnsd 3.5.2 into hirsute or b) remove gdnsd from hirsute entirely | 11:27 |
| tarzeau | skip the tests for ubuntu pkg only? | 11:27 |
| paravoid | an alternative (c) would be to fix this with an ubuntu1, but I don't know how to do that and I'm not motivated enough :P | 11:27 |
| tarzeau | #ifeq ($(DISTRIB),Ubuntu) | 11:27 |
| paravoid | yeah, that wouldn't be Debian hard freeze compliant I think :) | 11:28 |
| tarzeau | why not? | 11:28 |
| tarzeau | https://sources.debian.org/src/libnfsidmap-regex/1.2-1/debian/rules/ | 11:29 |
| tarzeau | my example in full. ah now it's freeze, i doubt you'd get that into debian, but it's possible to get stuff right into ubuntu | 11:29 |
| tarzeau | for "important" reasons | 11:29 |
| paravoid | that's what I meant yes | 11:29 |
| tarzeau | you just need to find the right ubuntu person | 11:29 |
| paravoid | and I don't know how to get stuff right into ubuntu, nor that interested to find out tbh :) | 11:30 |
| tarzeau | ubuntu doesn't autosync from debian experimental, or does it? | 11:30 |
| tarzeau | paravoid: same here. i had people tell me it's possible, and did it somehow, it's completely not transparent to me | 11:30 |
| tarzeau | my workplace had the idea to take debian and install that instead of ubuntu (with some theming tricks) as people want ubuntu, as it seems to be hip/popular | 11:31 |
| tarzeau | but since my workplace already pays redhat for satellite, managers would say: why should we pay for two companies for one linux? | 11:31 |
| paravoid | thanks for the insight. I'm really looking for ubuntu RM help/advice, though :) | 11:32 |
| cjwatson | Ubuntu does not autosync from experimental, but any Ubuntu developer who can upload the package in question can do a one-time sync from experimental easily | 11:57 |
| cjwatson | The last comment in the bug above seems to be an Ubuntu release team member nacking a force-badtest approach (as I read it) | 12:00 |
| cjwatson | An ubuntu1 upload is really no different in terms of source package layout from a Debian upload - it's effectively just a branch of the packaging with an appropriate version number | 12:02 |
| cjwatson | If a patch existed then any Ubuntu developer who's up to speed with the problem could deal with the mechanics of uploading it. I don't see something that somebody could upload today, though | 12:02 |
| cjwatson | Skipping the tests doesn't seem compliant with what Steve says in his comment on the bug above, so I wouldn't pursue that approach | 12:03 |
| ddstreet | paravoid can you include a default config file in the packaging with simple content like 'options => { listen = 127.0.0.1 }' | 12:08 |
| ddstreet | the package doesn't even successfully install on ubuntu due to the service failing | 12:08 |
| rbasak | paravoid: I've offered to sponsor an ubuntu1 for you. Just give me the fix and a changelog entry for the ubuntu1. Subject to review, of course. Surely that's preferable to a removal? | 12:10 |
| rbasak | You're quite entitled not to choose to take that approach, but seeking a removal in its place feels a bit like sabotage to me. | 12:11 |
| paravoid | ddstreet: including this would break all existing deployments right now | 12:16 |
| paravoid | rbasak: I'm sorry you feel like it's sabotage :/ I'm only trying to avoid Ubuntu shipping a very old release, and I lack to the time to figure out an Ubuntu-specific fix right now | 12:18 |
| paravoid | if badtesting is not an option, then the simplest fix here could just be to comment-out these autopkgtests in ubuntu1 | 12:18 |
| cjwatson | There are obviously many ways in which tests could be bypassed; don't they all share the flaw that, well, the resulting package doesn't actually work? | 12:21 |
| cjwatson | (Or so I gather) | 12:21 |
| paravoid | ddstreet: (hence why upstream added a big fat warning in 3.5.2 to prepare users that this could change in future releases - hirsute releasing with 2.4.2) | 12:21 |
| paravoid | hirsute releasing with 2.4.2 would be contrary to this goal* | 12:22 |
| cjwatson | Does the current 2.4.2 package in hirsute have the same problem? | 12:22 |
| paravoid | cjwatson: the package has 3 autopkgtests: one ("testsuite") runs the test suite with the package in place and should succeed; the other two run the daemon and start running queries against it, and fail in Ubuntu AIUI | 12:23 |
| cjwatson | Right, but that's slightly missing the point; I'm going from what ddstreet says above, "the package doesn't even successfully install" | 12:24 |
| paravoid | oh sorry, I misunderstood your question | 12:24 |
| paravoid | the package works, unless you have another daemon listening on port 53 (in any interface, including loopback) | 12:25 |
| cjwatson | But there is another daemon listening on port 53 on Ubuntu, so therefore the package doesn't work on Ubuntu, right? | 12:25 |
| cjwatson | The goal isn't really to bodge tests into artificially passing, it's to make the package work | 12:26 |
| paravoid | I don't know what the standard install in Ubuntu is. my suspicion is that this is the case, yes. | 12:26 |
| rbasak | including this would break all existing deployments right now> that's perhaps OK for a new release? | 12:26 |
| cjwatson | So the current 2.4.2 package in hirsute appears to have the same problem | 12:27 |
| cjwatson | Tested by "lxc launch ubuntu-daily:hirsute", then "apt update; apt install gdnsd" in that container | 12:27 |
| rbasak | Long term, the package will need to arrange listening on some specific IP instead by default anyway, won't it? | 12:27 |
| cjwatson | That seems like highly relevant information for any request to the release team | 12:27 |
| cjwatson | In fact the version in -proposed is arguably better (depending on your point of view), since the package installs successfully although the daemon doesn't start, so you have an opportunity to sort out the config I suppose | 12:29 |
| cjwatson | To me that says that the port 53 binding issue isn't itself a regression, which might make force-badtest or similar more reasonable | 12:29 |
| cjwatson | Though I'm no longer on the release team | 12:29 |
| paravoid | ...and warns about not having a listen address configured | 12:30 |
| paravoid | long-term... I question Ubuntu's choice to have a listener on 53 by default, but YMMV :) | 12:30 |
| cjwatson | If you go hunting in systemctl status, yes | 12:30 |
| cjwatson | So I think any requests you make to the release team should make it super-clear that the current version in hirsute basically has the same problem (though maybe how it shows up in autopkgtest is different, I haven't checked) | 12:32 |
| tarzeau | can pkgs still enter 21.04? | 12:32 |
| cjwatson | They're going to want to know that | 12:32 |
| cjwatson | tarzeau: in principle | 12:32 |
| tarzeau | i'd love to see this in 21.04: https://sid.ethz.ch/debian/fnt/fnt_1.2-1.dsc (and i'm sure many ubuntu users would like it too) | 12:32 |
| cjwatson | Not a release team question though | 12:32 |
| paravoid | cjwatson: question for you with a few different hats on :D | 12:33 |
| cjwatson | Needs an Ubuntu developer who's interested | 12:33 |
| tarzeau | ah, i'll create a snap maybe | 12:33 |
| paravoid | is openssh-server installed by default in Ubuntu server systems? where I'm going with this is that if I "apt install tinysshd" on a system with openssh-server installed, it would similarly fail (dropbear seems to have openssh-detection code to disable itself via /etc/default/dropbear) | 12:35 |
| paravoid | I hope this doesn't sound like whataboutism, but it's a bit similar | 12:35 |
| rbasak | openssh-server is installed by default on Ubuntu cloud images | 12:35 |
| rbasak | So the rough answer to your question is "yes". | 12:36 |
| paravoid | right | 12:36 |
| paravoid | is that a bug? | 12:36 |
| paravoid | (in tinysshd, I mean) | 12:36 |
| cjwatson | You could reasonably argue that if packages can't be coinstalled out of the box they should conflict, perhaps. But the analogy doesn't hold up here - if you tried to conflict with systemd I would expect your package to be flat-out unusable on Ubuntu | 12:38 |
| cjwatson | openssh-server is clearly a more optional part of the system (at the packaging level) even if it happens to be there by default | 12:38 |
| cjwatson | I really recommend that you pursue the "not a regression" argument rather than this sort of thing | 12:38 |
| juliank | Laney: I've got +1 maintenance Mon, Tue; figured I might do some work on autopkgtest-cloud multiple worker thingy then | 12:40 |
| paravoid | it's not systemd -- it's a particular configuration of one of the systemd daemons, and one that is not the default in Debian | 12:46 |
| paravoid | I appreciate the advice, and the "not a regression" makes sense and than you for testing that | 12:47 |
| ddstreet | paravoid what's the problem with simply adding a default config file that restricts it to listening to 127.0.0.1? systemd-resolved *explicitly* listens on 127.0.0.53 exactly so other dns servers can take 127.0.0.1 | 12:49 |
| ddstreet | users can trivially update the gdnsd config file with whatever other listen config they actually want after installing the package | 12:49 |
| ddstreet | the problem here is *only* the default | 12:49 |
| cjwatson | I appreciate it's not a mandatory configuration of systemd, but it's the configuration of systemd in Ubuntu, in the same way that sshd listening on port 22 isn't a mandatory configuration of openssh but is the default in Ubuntu (and in that case a much wider default, sure) | 12:52 |
| cjwatson | But anyway, I think this line of argument is unlikely to be productive | 12:52 |
| xnox | paravoid: it is supported to install dns servers on Ubuntu, in addition to the resolved. normally, when installing dns servers they are configured to provide dns on some interfaces, but not all. Sometimes people choose for said dns server to also provide local dns too. Or not. | 13:05 |
| xnox | paravoid: the best course of action is to check, how for example that dns server integrates with resolvconf in debian; and check if that can be replicated in the tests; and on Ubuntu by default. | 13:05 |
| Laney | juliank: neat | 13:06 |
| xnox | paravoid: it is an extra configuration step that is needed, because ubuntu by default provides a local caching dns resolution service with split dns support by interface out of the box. Whereas in debian anything goes by default. Both configurations are valid, and both return different results. With the choice made by Ubuntu is deemed by us to be more precisely scoped, with less queries | 13:07 |
| xnox | leaking. | 13:07 |
| Laney | juliank: the wip branch is getting ready to go, you can play with stg-proposed-migration if you want | 13:07 |
| paravoid | xnox: this is an auth-only server, so resolvconf is not relevant | 13:10 |
| paravoid | thanks everyone for the input though, but I think we can wrap this up as this is getting a bit out of scope (esp. for this channel) | 13:11 |
| paravoid | apologies for my part in derailing this | 13:11 |
| juliank | Laney: I'll be battling with setting up my development environment again I suppose; and maybe it needs a rebase on master, there's soem small conflicts | 13:27 |
| Laney | yeah | 13:28 |
| Laney | I'm only going to do that one more time though | 13:29 |
| paravoid | (fyi for everyone that followed the discussion above, I just updated 1764327 with a summary of where my thoughts are and after taking into account this discussion as well. HTH!) | 14:01 |
| -queuebot:#ubuntu-release- New sync: bootgen-xlnx (hirsute-proposed/primary) [2020.2] | 15:41 | |
| -queuebot:#ubuntu-release- New sync: fpga-manager-xlnx (hirsute-proposed/primary) [2020.2ubuntu1] | 15:43 | |
| -queuebot:#ubuntu-release- New sync: libegl-mali-xlnx (hirsute-proposed/primary) [9p0.01rel0-0ubuntu3] | 15:45 | |
| -queuebot:#ubuntu-release- New sync: linux-firmware-xilinx-vcu (hirsute-proposed/primary) [2020.2-0ubuntu0xlnx1] | 15:45 | |
| -queuebot:#ubuntu-release- New sync: u-boot-xlnx (hirsute-proposed/primary) [2020.2-0ubuntu3] | 15:45 | |
| -queuebot:#ubuntu-release- New sync: vitis-ai (hirsute-proposed/primary) [1.3-1ubuntu2] | 15:46 | |
| -queuebot:#ubuntu-release- New sync: vitis-ai-dnndk (hirsute-proposed/primary) [1.3] | 15:46 | |
| -queuebot:#ubuntu-release- New sync: xilinx-vcu-ctrl (hirsute-proposed/primary) [2020.2-0ubuntu1] | 15:46 | |
| -queuebot:#ubuntu-release- New sync: xilinx-vcu-omx (hirsute-proposed/primary) [2020.2-0ubuntu1] | 15:47 | |
| -queuebot:#ubuntu-release- New sync: xlnx-firmware (hirsute-proposed/primary) [0.1ubuntu13] | 15:47 | |
| -queuebot:#ubuntu-release- New sync: xrt (hirsute-proposed/primary) [202020.2.8.726-0ubuntu2] | 15:47 | |
| -queuebot:#ubuntu-release- New sync: xf86-video-armsoc-endlessm (hirsute-proposed/primary) [1.4.1-0ubuntu1] | 15:48 | |
| === juergh is now known as Guest9645 | ||
| === ijohnson is now known as ijohnson|lunch | ||
| === juergh is now known as Guest21961 | ||
| === Guest21961 is now known as Guest1 | ||
| === Guest1 is now known as juergh | ||
| === ijohnson|lunch is now known as ijohnson | ||
| bryce | tjaalton, vorlon if either of you are on SRU today: with runc accepted to -proposed (thanks sil2100) it would be keen to also get the containerd and docker.io SRU uploads approved. The set is needed for resolving LP: #1916485 + LP: #1919322, so ideally we will want to validate them together as a set. | 20:39 |
| ubot5 | Launchpad bug 1916485 in docker.io (Ubuntu Hirsute) "test -x fails inside shell scripts in containers" [Critical,New] https://launchpad.net/bugs/1916485 | 20:39 |
| ubot5 | Launchpad bug 1919322 in docker.io (Ubuntu Groovy) "Backport the container stack in Hirsute" [Undecided,In progress] https://launchpad.net/bugs/1919322 | 20:39 |
| -queuebot:#ubuntu-release- Unapproved: libapache2-mod-perl2 (focal-proposed/main) [2.0.11-2 => 2.0.11-2ubuntu0.20.04.1] (ubuntu-server) | 21:47 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!