| bdmurray | slangasek: "I think it's better" so bdmurray should do it? | 00:02 |
|---|---|---|
| slangasek | bdmurray: I'm willing to push the button if you prefer :) | 00:05 |
| bdmurray | slangasek: I have no preference lets just get it doen | 00:05 |
| slangasek | bdmurray: ok, done | 00:06 |
| slangasek | (modulo the delay of updating 22 bugs) | 00:06 |
| jbicha | slangasek: do you have time to review libreoffice & gnome-desktop3 in the bionic NEW queue? | 00:07 |
| slangasek | jbicha: no, because I'm currently reviewing older stuff in said queue | 00:08 |
| jbicha | cool, thanks | 00:08 |
| -queuebot:#ubuntu-release- New: accepted nm-tray [source] (bionic-proposed) [0.3.0-0ubuntu1] | 00:10 | |
| tsimonq2 | \o/ | 00:10 |
| -queuebot:#ubuntu-release- New binary: nm-tray [amd64] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset) | 00:12 | |
| -queuebot:#ubuntu-release- New binary: nm-tray [s390x] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset) | 00:12 | |
| -queuebot:#ubuntu-release- New binary: nm-tray [ppc64el] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset) | 00:12 | |
| -queuebot:#ubuntu-release- New binary: nm-tray [i386] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset) | 00:13 | |
| -queuebot:#ubuntu-release- New binary: nm-tray [armhf] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset) | 00:14 | |
| -queuebot:#ubuntu-release- New binary: nm-tray [arm64] (bionic-proposed/universe) [0.3.0-0ubuntu1] (no packageset) | 00:15 | |
| sarnold | for the unity / compiz thing I've duped a few bugs to 1749840 | 00:17 |
| tsimonq2 | thanks | 00:17 |
| -queuebot:#ubuntu-release- New: accepted nm-tray [amd64] (bionic-proposed) [0.3.0-0ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted nm-tray [armhf] (bionic-proposed) [0.3.0-0ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted nm-tray [ppc64el] (bionic-proposed) [0.3.0-0ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted nm-tray [arm64] (bionic-proposed) [0.3.0-0ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted nm-tray [s390x] (bionic-proposed) [0.3.0-0ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted nm-tray [i386] (bionic-proposed) [0.3.0-0ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted gnome-desktop3 [amd64] (bionic-proposed) [3.27.90-1ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted gnome-desktop3 [armhf] (bionic-proposed) [3.27.90-1ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted gnome-desktop3 [ppc64el] (bionic-proposed) [3.27.90-1ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted gnome-desktop3 [arm64] (bionic-proposed) [3.27.90-1ubuntu1] | 00:28 | |
| -queuebot:#ubuntu-release- New: accepted gnome-desktop3 [s390x] (bionic-proposed) [3.27.90-1ubuntu1] | 00:29 | |
| -queuebot:#ubuntu-release- New: accepted gnome-desktop3 [i386] (bionic-proposed) [3.27.90-1ubuntu1] | 00:29 | |
| -queuebot:#ubuntu-release- New: accepted php-horde-passwd [sync] (bionic-release) [5.0.7-1] | 00:29 | |
| -queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (bionic-proposed) [1:6.0.1-0ubuntu1] | 00:29 | |
| -queuebot:#ubuntu-release- New: accepted libreoffice [armhf] (bionic-proposed) [1:6.0.1-0ubuntu1] | 00:29 | |
| -queuebot:#ubuntu-release- New: accepted libreoffice [ppc64el] (bionic-proposed) [1:6.0.1-0ubuntu1] | 00:30 | |
| -queuebot:#ubuntu-release- New: accepted libreoffice [arm64] (bionic-proposed) [1:6.0.1-0ubuntu1] | 00:30 | |
| -queuebot:#ubuntu-release- New: accepted libreoffice [s390x] (bionic-proposed) [1:6.0.1-0ubuntu1] | 00:30 | |
| -queuebot:#ubuntu-release- New: accepted libreoffice [i386] (bionic-proposed) [1:6.0.1-0ubuntu1] | 00:30 | |
| doko | who's accepting binaries before they are built on all archs? | 00:33 |
| nacc | doko: which one? | 00:34 |
| -queuebot:#ubuntu-release- New: accepted mbedtls [armhf] (bionic-proposed) [2.7.0-2] | 00:34 | |
| doko | that one | 00:34 |
| slangasek | possibly me | 00:38 |
| slangasek | because I don't see that it matters to not do so, or warrants spending the attention instead of just running new-binary-debian-universe | 00:40 |
| doko | well, the next one looking at the NEW queue spends that attention why there is only a binary on one arch. not that efficient | 00:47 |
| slangasek | you could also run new-binary-debian-universe ;) | 00:51 |
| tsimonq2 | up to seven dups: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1749840 | 01:25 |
| ubot5 | Ubuntu bug 1749840 in compiz (Ubuntu) "apt-get install ubuntu-desktop doesn't work" [Undecided,Confirmed] | 01:25 |
| tsimonq2 | argh, I accidentally uploaded calamares-settings-ubuntu without running dch -r so it looks like it's from November... | 01:54 |
| -queuebot:#ubuntu-release- New source: calamares-settings-ubuntu (bionic-proposed/primary) [1] | 01:54 | |
| tsimonq2 | Can someone reject please? | 01:54 |
| tsimonq2 | (There's an associated lintian warning with using a Standards-version newer than the changelog entry...) | 01:54 |
| -queuebot:#ubuntu-release- New source: calamares-settings-ubuntu (bionic-proposed/primary) [1] | 02:23 | |
| -queuebot:#ubuntu-release- New: rejected calamares-settings-ubuntu [source] (bionic-proposed) [1] | 08:21 | |
| apw | tsimonq2, ^ | 08:21 |
| -queuebot:#ubuntu-release- Unapproved: rejected fwupdate [amd64] (bionic-proposed) [10-2build1] | 08:37 | |
| -queuebot:#ubuntu-release- Unapproved: rejected fwupdate [armhf] (bionic-proposed) [10-2build1] | 08:37 | |
| -queuebot:#ubuntu-release- Unapproved: rejected fwupdate [arm64] (bionic-proposed) [10-2build1] | 08:37 | |
| -queuebot:#ubuntu-release- Unapproved: rejected fwupdate [i386] (bionic-proposed) [10-2build1] | 08:37 | |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (bionic-proposed) [10-3] | 08:37 | |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (bionic-proposed) [10-3] | 08:37 | |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (bionic-proposed) [10-3] | 08:37 | |
| -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (bionic-proposed) [10-3] | 08:37 | |
| doko | who is working on Kylin these days? | 10:39 |
| doko | asking for https://launchpadlibrarian.net/357258908/buildlog_ubuntu-bionic-amd64.ubuntu-kylin-sso-client_0.1.2.4_BUILDING.txt.gz | 10:40 |
| doko | https://bugs.launchpad.net/ubuntu/+source/ubuntu-kylin-sso-client/+bug/1749924 | 10:45 |
| ubot5 | Ubuntu bug 1749924 in ubuntu-kylin-sso-client (Ubuntu) "ubuntu-kylin-sso-client ftbfs in bionic" [High,Confirmed] | 10:45 |
| rbasak | Could an AA review libzstd in Xenial binNEW please? It's related to maintaining the upgrade path in an SRU. | 11:24 |
| sil2100 | rbasak: you ACKed the SRU, right? | 11:27 |
| rbasak | sil2100: yes | 11:27 |
| sil2100 | rbasak: in that case I can do that, one moment | 11:28 |
| rbasak | ahasenack: ^ | 11:35 |
| ahasenack | thx | 11:36 |
| sil2100 | rbasak, ahasenack: done | 11:38 |
| -queuebot:#ubuntu-release- New: accepted libzstd [amd64] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1] | 11:38 | |
| -queuebot:#ubuntu-release- New: accepted libzstd [armhf] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1] | 11:38 | |
| -queuebot:#ubuntu-release- New: accepted libzstd [powerpc] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1] | 11:38 | |
| -queuebot:#ubuntu-release- New: accepted libzstd [s390x] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1] | 11:38 | |
| -queuebot:#ubuntu-release- New: accepted libzstd [arm64] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1] | 11:38 | |
| -queuebot:#ubuntu-release- New: accepted libzstd [ppc64el] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1] | 11:38 | |
| -queuebot:#ubuntu-release- New: accepted libzstd [i386] (xenial-proposed) [1.3.1+dfsg-1~ubuntu0.16.04.1] | 11:38 | |
| ahasenack | thanks sil2100 | 11:38 |
| ahasenack | hi, I need a component-mismatch fix for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd | 11:38 |
| ahasenack | python-sss is in main, that's the py2 version | 11:38 |
| ahasenack | python3-sss is in universe | 11:38 |
| ahasenack | both come from the same source package which is sssd | 11:39 |
| rbasak | sil2100: thanks! | 11:45 |
| jbicha | doko: there is a #ubuntukylin-devel channel | 12:09 |
| tsimonq2 | apw: Thanks :) | 14:05 |
| apw | ahasenack, have you found the MIR for that, that let the py2 in ? | 14:16 |
| ahasenack | apw: I didn't check, since it was in main already (as is sssd itself) | 14:17 |
| apw | ahasenack, ok found it | 14:35 |
| apw | ahasenack, ok poked | 14:37 |
| bdmurray | slangasek: FYI the unity phasing got stopped by the phased updater. | 16:37 |
| bdmurray | slangasek: Its right - just thought it was worth noting. | 16:37 |
| tsimonq2 | Does anto | 16:38 |
| tsimonq2 | gerr | 16:39 |
| tsimonq2 | Does anyone happen to know what version of apt runs on Nusakan? | 16:39 |
| slangasek | bdmurray: ah? | 16:39 |
| slangasek | tsimonq2: I'm not sure apt is run at any point on nusakan as part of the builds | 16:39 |
| slangasek | tsimonq2: what are you seeing? | 16:40 |
| tsimonq2 | slangasek: Curious about juliank's question on bug 1714451 | 16:40 |
| ubot5 | bug 1714451 in libglvnd (Ubuntu) "please remove libglvnd from the archive" [Undecided,Invalid] https://launchpad.net/bugs/1714451 | 16:40 |
| tsimonq2 | er | 16:40 |
| tsimonq2 | wrong one | 16:40 |
| tsimonq2 | bug 1746807 | 16:41 |
| ubot5 | bug 1746807 in apt (Ubuntu) "18.04 daily installer fails missing kernel" [Critical,Confirmed] https://launchpad.net/bugs/1746807 | 16:41 |
| tsimonq2 | that :) | 16:41 |
| * juliank too | 16:41 | |
| juliank | probably there are different version, but I don't remember | 16:41 |
| juliank | I think we jumped from alpha5 to alpha7 | 16:42 |
| slangasek | tsimonq2: the version that's relevant there is the version run from inside the install target | 16:43 |
| juliank | alpha6 introduced retrying for acquire items and the new mirror method, so it's possibles something got broken. | 16:43 |
| slangasek | which is the version on the image | 16:43 |
| slangasek | not on nusakan | 16:43 |
| juliank | alpha5 was superseded on 2018-01-31 19:37:29 CET | 16:43 |
| tsimonq2 | slangasek: Ohhh and the timing matches up too, apt in Bionic got updated on 20180131 as well | 16:44 |
| tsimonq2 | juliank: It's likely that then I think | 16:44 |
| juliank | Well, cdrom support is basically unmaintained and does not have much tests, so it breaks a lot | 16:45 |
| xnox | most no longer have cdroms.... | 16:45 |
| juliank | But well, something must have broken. | 16:46 |
| tsimonq2 | OK | 16:46 |
| juliank | Best next would be to get the image, and bisect apt-cdrom | 16:46 |
| tsimonq2 | I can do that if we know it's apt-cdrom. | 16:47 |
| tsimonq2 | (That would make sense.) | 16:47 |
| juliank | Well, it's somewhere in the apt-pkg library probably | 16:47 |
| juliank | but anyway, bisecting should be relatively easy I guess. | 16:48 |
| slangasek | xnox: we use apt-cdrom also for USB sticks at install time | 16:48 |
| juliank | yes, we do. | 16:48 |
| juliank | unfortunately installs are not a common thing :D | 16:48 |
| * tsimonq2 volunteers to do the bisecting | 16:48 | |
| juliank | at least for developers - so it's good to have testing for it :D | 16:48 |
| tsimonq2 | :D | 16:49 |
| xnox | slangasek, because file:// would not do? | 16:49 |
| juliank | correct | 16:49 |
| slangasek | xnox: file:// semantics are wrong for removable media | 16:49 |
| juliank | xnox: file:// has a fixed path, that does not really work | 16:49 |
| juliank | cdrom:// looks up based on some media id label thingy | 16:49 |
| xnox | ..... which systemd .mount unit could do too.... | 16:50 |
| juliank | We should probably symlink it to usb :D | 16:50 |
| xnox | %i too | 16:50 |
| juliank | it's a weird file in .disk-info or something, and then it hashes the files to make sure it's the correct disk | 16:50 |
| juliank | it's all fairly weird, but it makes sure you don't accidentally update/install something different just because it has the same name | 16:51 |
| xnox | start an http server to serve cdrom:// over http?! =) as a mirror?! =) | 16:51 |
| slangasek | last I knew, there were error code differences w/ absent cdrom sources as well | 16:52 |
| juliank | probably | 16:52 |
| juliank | anyhow, it's the right thing to do | 16:52 |
| juliank | maybe we should allow usb:// as an alias? :D | 16:52 |
| juliank | or disk:// | 16:52 |
| juliank | and disc:// | 16:53 |
| slangasek | twitch | 16:53 |
| juliank | I don't know | 16:53 |
| juliank | tsimonq2: I'll ask DonKult if he has an idea, he made all those big changes :/ | 16:54 |
| bdmurray | I think its .media-info | 16:54 |
| juliank | ah | 16:54 |
| xnox | juliank, hokey-rink:// too then! | 16:55 |
| xnox | https://en.wikipedia.org/wiki/Bootable_business_card | 16:55 |
| juliank | Nah | 16:55 |
| juliank | bbc:// sounds nice, though | 16:55 |
| juliank | Package it as apt-transport-bbc | 16:55 |
| juliank | If only to annoy BBC folks | 16:56 |
| * xnox suspects juliank is not trolling; and simply has no idea what bbc stands for on urban dictionary | 16:57 | |
| juliank | I meant the British one | 16:57 |
| juliank | :D | 16:57 |
| -queuebot:#ubuntu-release- New binary: python-skytools [s390x] (bionic-proposed/none) [3.3-2] (no packageset) | 17:11 | |
| -queuebot:#ubuntu-release- New binary: eo-spell [amd64] (bionic-proposed/main) [2.1.2000.02.25-55] (ubuntu-desktop) | 17:12 | |
| -queuebot:#ubuntu-release- New binary: quaternion [s390x] (bionic-proposed/none) [0.0.5-1] (no packageset) | 17:13 | |
| -queuebot:#ubuntu-release- New binary: radare2 [s390x] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset) | 17:13 | |
| -queuebot:#ubuntu-release- New binary: dxf2gcode [amd64] (bionic-proposed/universe) [20170925-1] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: golang-github-nvveen-gotty [amd64] (bionic-proposed/universe) [0.0~git20120604.cd52737-1] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: londiste [amd64] (bionic-proposed/universe) [3.3.0-1] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: python-coverage [amd64] (bionic-proposed/universe) [4.5+dfsg.1-2] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: radare2 [amd64] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: emacs-fossil [amd64] (bionic-proposed/universe) [2018.02.15-1] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: pytest-forked [amd64] (bionic-proposed/universe) [0.2-1] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: golang-github-opencontainers-go-digest [amd64] (bionic-proposed/universe) [1.0.0~rc1-1] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: python-skytools [amd64] (bionic-proposed/universe) [3.3-2] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: pokemmo-installer [amd64] (bionic-proposed/multiverse) [1.4.5-1] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: python-skytools [i386] (bionic-proposed/universe) [3.3-2] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: pokemmo [amd64] (bionic-proposed/multiverse) [1.4.3-1] (no packageset) | 17:15 | |
| -queuebot:#ubuntu-release- New binary: lua-ljsyscall [amd64] (bionic-proposed/universe) [0.12-1] (no packageset) | 17:16 | |
| -queuebot:#ubuntu-release- New binary: python-skytools [arm64] (bionic-proposed/universe) [3.3-2] (no packageset) | 17:18 | |
| -queuebot:#ubuntu-release- New binary: quaternion [amd64] (bionic-proposed/universe) [0.0.5-1] (no packageset) | 17:18 | |
| -queuebot:#ubuntu-release- New binary: python-skytools [armhf] (bionic-proposed/universe) [3.3-2] (no packageset) | 17:18 | |
| -queuebot:#ubuntu-release- New binary: radare2 [i386] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset) | 17:18 | |
| -queuebot:#ubuntu-release- New binary: quaternion [i386] (bionic-proposed/universe) [0.0.5-1] (no packageset) | 17:19 | |
| -queuebot:#ubuntu-release- New binary: radare2 [arm64] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset) | 17:19 | |
| -queuebot:#ubuntu-release- New binary: radare2 [armhf] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (bionic-proposed/universe) [2.3.0+dfsg-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: python-skytools [ppc64el] (bionic-proposed/universe) [3.3-2] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: quaternion [arm64] (bionic-proposed/universe) [0.0.5-1] (no packageset) | 17:25 | |
| -queuebot:#ubuntu-release- New binary: quaternion [ppc64el] (bionic-proposed/universe) [0.0.5-1] (no packageset) | 17:27 | |
| -queuebot:#ubuntu-release- New binary: quaternion [armhf] (bionic-proposed/universe) [0.0.5-1] (no packageset) | 17:29 | |
| -queuebot:#ubuntu-release- Unapproved: supermin (xenial-proposed/universe) [5.1.14-2ubuntu1 => 5.1.14-2ubuntu1.1] (no packageset) | 18:41 | |
| nacc | chrisccoulson: infinity: glibc in bionic is versioned less than artful | 18:58 |
| nacc | and i think is breaking some folks in #ubuntu+1 | 18:58 |
| nacc | i'm assuming the artful package should be copied forward? | 18:59 |
| nacc | i think if a user did artful with the security update -> bionic, many packages with libc dependencies will fail to install in bionic | 19:05 |
| nacc | they can manually workaround with libc6= libc6-dev= libc6-i386= to downgrade to the bionic version, but that's not great UX :) | 19:06 |
| nacc | slangasek: --^ maybe you can help as i think it will take a AA | 19:28 |
| -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-116.140~14.04.1] (kernel) | 19:30 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-116.140~14.04.1] | 19:43 | |
| -queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (xenial-proposed/main) [3.18.0-2ubuntu1 => 3.18.0-2ubuntu2] (ubuntu-desktop) | 20:18 | |
| -queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (artful-proposed/main) [3.22.3-1ubuntu1 => 3.22.3-1ubuntu2] (ubuntu-desktop) | 20:24 | |
| slangasek | nacc: it's a known temporary problem until glibc 2.27 is landed in bionic, which I don't have a current ETA on. We would not normally copy directly to bionic from artful, but would copy to bionic-proposed instead, and I'm not sure the artful version would actually clear autopkgtests so I don't want to do that unless strictly necessary | 20:27 |
| slangasek | infinity: ^^ what's the current status of 2.27? are you still in package merge hell? | 20:27 |
| bdmurray | slangasek: Now that ddebs is fixed - https://code.launchpad.net/~brian-murray/apport/lp-retracer-bionic-updates/+merge/337676 | 20:33 |
| slangasek | bdmurray: merged, thanks! | 20:39 |
| tsimonq2 | Out of curiosity, I wonder why ddebs.ubuntu.com doesn't have anything for *-security. | 20:39 |
| slangasek | tsimonq2: I don't know if this is the rationale, but it would be redundant since everything published to -security is also copied to -updates | 20:42 |
| tsimonq2 | slangasek: What about the case where something is released to -updates that updates patch or minor version and there's already something in -security? | 20:44 |
| slangasek | ah, the case where -security is non-empty and -updates is ahead | 20:44 |
| tsimonq2 | Yeah. | 20:45 |
| slangasek | that's a good point, indeed | 20:45 |
| infinity | slangasek: I'm fiddling with some theories, and was planning to upload today/tomorrow, but I also have no issues with copying artful-security -> bionic-release and skipping testing entirely. The security upload regresses autopkgtests on armhf (and the arm64 build is regressed due to binutils), but I know of no other issues that would be worth doing the proposed dance on it. | 20:45 |
| bdmurray | hunh, I wonder if we have any cases that fail to retrace because of that. | 20:46 |
| slangasek | tsimonq2: OTOH, if you're running a system with only -security enabled w/ no -updates, are debug symbols actually useful to you, since you are evidently not going to be deploying any SRUs that fix a crash | 20:46 |
| slangasek | infinity: I would be inclined to copy to bionic-proposed first, force-skiptest, and flush the autopkgtest requests, so I don't have to think about whether there's a risk of uninstallables | 20:47 |
| slangasek | infinity: oops, in the time it took me to write that sentence I proved to myself there is no risk of uninstallables | 20:47 |
| infinity | slangasek: If there are uninstallables with a non-version-bumped glibc, we've done something very, very wrong, but sure. | 20:48 |
| slangasek | infinity: k, copying. | 20:48 |
| slangasek | nacc: ^^ | 20:48 |
| slangasek | bdmurray: do you think this is important enough to put on our backlog? | 20:50 |
| tsimonq2 | slangasek: I can see a use case for it; I think even security updates have a nonzero potential to break. Even if it's rare, I don't (personally) see a reason why debug symbols shouldn't be available should someone need them. | 20:51 |
| tsimonq2 | slangasek: But also note that I don't have a very strong opinion either way, but rather I was wondering out of curiosity why -security ddebs aren't published with -updates et al | 20:52 |
| bdmurray | slangasek: I think having a backlog item to think about it is a good idea. | 20:52 |
| tsimonq2 | slangasek: I also don't think (please correct me if I'm wrong) that there's *many* packages that have non-empty -security with -updates ahead, so while I'm not sure on numbers, adding it there might not impact resources on the server much. | 20:53 |
| tsimonq2 | ¯\_(ツ)_/¯ | 20:54 |
| slangasek | bdmurray: k, please drop me a card :) | 21:09 |
| slangasek | tsimonq2: it absolutely isn't going to be a space issue for us - it's only the effort to implement and maintain | 21:09 |
| bdmurray | tsimonq2: I'm pretty sure the debug symbols are available on LP if someone really needed them. | 21:10 |
| tsimonq2 | bdmurray: You can say the same for all other packages ;) | 21:14 |
| tsimonq2 | slangasek: right, ok | 21:14 |
| nacc | slangasek: infinity: the user in question was on bionic and was unable to install nvidia-384 | 21:37 |
| nacc | slangasek: infinity: with forced apt versioning, it installed fine | 21:37 |
| nacc | possibly because only libc6 was already installed and then libc-i386 was going to be installed? but only the bionic version was available and conflicted with the artful-security version? | 21:38 |
| slangasek | yes | 21:38 |
| slangasek | forced apt versioning> speewwwww | 21:38 |
| nacc | slangasek: yeah, i mean apt install nvidia-384 libc=... libc-i386=... etc | 21:39 |
| nacc | just to get them to the bionic packages | 21:39 |
| slangasek | oh ok | 21:39 |
| nacc | so it's not uninstallable in the traditional sense, but the effect to users is the same :) | 21:39 |
| nacc | slangasek: and thanks for your feedback here, I have seen other users in the past few days hit it too, I just remembered to dig into it more today | 21:41 |
| juliank | tsimonq2, slangasek: only -updates and -proposed are whitelisted in ddeb-retriever, I think all that's needed to enable security again (it's there for trusty) is http://paste.ubuntu.com/p/C4Dr8GmPw5/ | 22:09 |
| juliank | oh no | 22:10 |
| juliank | one more | 22:10 |
| juliank | http://paste.ubuntu.com/p/JVTHsZv63Z/ | 22:10 |
| juliank | this might cause quite some havoc if enabled since it would suddenly start fetching and scanning all debug symbols for all security releases | 22:11 |
| slangasek | juliank: are there any assumptions about urls for indices of the base pockets? | 22:11 |
| juliank | I think the reason it's not done is that there's a huge overlap with updates. | 22:11 |
| slangasek | well, I guess http://archive.ubuntu.com/ubuntu/dists/foo-security/ exists anyway | 22:11 |
| slangasek | juliank: raise an MP? maybe ask cjwatson to review it :) | 22:12 |
| juliank | right there's some mirroring | 22:12 |
| juliank | Um, yeah. | 22:12 |
| infinity | juliank: Overlap shouldn't matter if they share a pool (which they do), surely. | 22:12 |
| juliank | infinity: It's only a matter of indexing runtime | 22:13 |
| juliank | it's currently about 2 mins per architecture x pocket pair | 22:13 |
| juliank | AFAICT | 22:13 |
| infinity | post-release pockets should be faster, I'd think. | 22:13 |
| juliank | we are adding about 33% more | 22:13 |
| juliank | _should_ not matter if apt-ftparchive is using a cache database, but hmm, I'm not sure it does. | 22:14 |
| infinity | juliank: Is it done in one big apt.conf, or one run per pocket? | 22:14 |
| juliank | infinity: one run per pocket | 22:14 |
| infinity | Pretty sure a-f caching was enabled for that. It's much faster if you do all pockets in one big apt.conf, though. | 22:14 |
| infinity | Otherwise, you risk flushing the a-f caches between each run. | 22:15 |
| juliank | We might be able too | 22:15 |
| juliank | It'd be good to setup a second test instance I guess with a copy view of the current state to play with or something | 22:16 |
| infinity | For reference, post-release pockets on ftpmaster are seconds per arch/component in the a-f stage. They're basically free. | 22:16 |
| juliank | infinity: In any case, this requires some refactoring I've planned to make dists updates more atomic | 22:17 |
| infinity | But that's because the caches are hot already (the first one is always noticeably slower, while the rest are free). | 22:17 |
| juliank | Currently dists/<foo> is so slow people get hashsum mismatches a lot | 22:17 |
| juliank | like 2 or 3 times last week I got complaints | 22:17 |
| juliank | I wanted to make dists/<foo> (mostly) atomic, but if I want to do all in one apt-ftparchive run, I guess I'll just create dists.new and then swap it | 22:18 |
| infinity | juliank: Following the publisher model of "update pool", "rsync dists dists.new", "update dists.new in a single apt.conf pass", "rm dists && mv dists.new dists" probably works best. But then you also need a stay-of-execution concept to avoid cleaning things from pool too early. | 22:18 |
| juliank | well, not rm dists && mv dists.new dists, but rather mv dists dists.old && mv dists.new dists && rm dists.old; but that's the goal. | 22:19 |
| infinity | Well, "rm dists && mv dists.new dists" is not actually the model. We "mv dists dists.old && mv dists.new dists" to narrow the window, plus it gives us a quicker rsync when we mv dists.old to dists.new and resync for the next pass. | 22:19 |
| infinity | juliank: Jinx. | 22:20 |
| infinity | juliank: ie: we never 'rm dists.old', we just always have two copies around, and freshen up old to new before the next run. | 22:20 |
| infinity | juliank: Slight waste of disk space, but huge win on time. | 22:21 |
| juliank | That's best | 22:21 |
| slangasek | fs juggling | 22:21 |
| infinity | (.old and .new also don't exist in the published tree, obviously) | 22:21 |
| juliank | It also allows you to do some roll back I guess. | 22:21 |
| juliank | although, not with ddeb-retrievers cleanup model | 22:21 |
| juliank | It currently builds the new dists/ tree, and then goes through pool and removes unreferenced files | 22:21 |
| infinity | juliank: Right, I alluded to that earlier, that you'd need a stay-of-execution concept to avoid windows where files disappear. | 22:22 |
| infinity | juliank: But that's not too hard. You make the cleanup pass mark files for deletion instead of actually deleting, and a second cronjob cleans things with deletion timestamps >> 24h. | 22:22 |
| juliank | We don't _need_ it. | 22:23 |
| juliank | It would just behave as it does now | 22:23 |
| infinity | Also fair. | 22:23 |
| juliank | the dists.new becomes the dists, and then we do the removal based on the new state. | 22:23 |
| infinity | It's not a high traffic enough apt archive to worry too much about perfect internal consistency. | 22:23 |
| juliank | but yes, it would be nice to keep stuff around a bit | 22:23 |
| infinity | Oh. If the removal pass is separate from the update pass, yes, that works. | 22:24 |
| juliank | It is | 22:24 |
| infinity | add-to-pool, update-dists, remove-from-pool | 22:24 |
| juliank | exactly | 22:24 |
| infinity | Yeah, I'm fine with that. | 22:24 |
| infinity | And way simpler than the tricks we have to pull on high traffic mirrors. | 22:24 |
| juliank | Though we can make the pass also just write all files to delete to a list, and then read the list and delete the files at the start of the next ddeb-retriever run | 22:25 |
| juliank | this avoids some minor issues | 22:25 |
| infinity | Nah. Lists are complicated for other reasons. | 22:25 |
| infinity | Notably the reappearance of versions, so you need to actually compare new published binaries against the list and remove matching lines. | 22:25 |
| juliank | infinity: Oh, we actually have a keep_days option | 22:25 |
| juliank | so it actually only deletes files older than a few days | 22:25 |
| juliank | currently set to 30 days | 22:26 |
| infinity | Gross. | 22:26 |
| infinity | That seems hugely like overkill. | 22:26 |
| juliank | it might make sense to reduce it to like 4 days or something | 22:26 |
| infinity | Probably was due to lagging errors retracers. | 22:26 |
| infinity | Which now will fetch from the librarian directly. | 22:26 |
| juliank | maybe two days | 22:26 |
| juliank | since clients do update automatically daily, they should never be more out of sync than that | 22:27 |
| juliank | I'll send some pretty merge proposals in the next days :) | 22:27 |
| juliank | ddeb-retriever is very interesting because the code is easy to follow. | 22:28 |
| juliank | but it's next to impossible to test | 22:29 |
| juliank | archive_tools in it has unit tests, but a lot of them fail | 22:30 |
| juliank | ah just some import messup | 22:30 |
| * juliank sends MP | 22:32 | |
| nacc | slangasek: could use some AA love to new packages in LP: #1749783 | 22:33 |
| ubot5 | Launchpad bug 1749783 in php-sabre-xml (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,Confirmed] https://launchpad.net/bugs/1749783 | 22:33 |
| infinity | juliank: Also, is ddeb-retriever smart enough to only run a-f for suites that changed? | 22:38 |
| juliank | slangasek, infinity: Fixes for test suite & retention: https://code.launchpad.net/~juliank/ddeb-retriever/misc-fixes/+merge/337899 ; add -security: https://code.launchpad.net/~juliank/ddeb-retriever/add-security/+merge/337900 | 22:38 |
| juliank | infinity: yes | 22:38 |
| juliank | infinity: and since recently for empty ones that do not exist yet :D | 22:38 |
| slangasek | nacc: you were not using 'new' as a verb there, were you | 22:38 |
| infinity | juliank: Okay, good. So, yeah, that's the point behind having two copies and the rsync refresh, so we have a complete dists and just refresh the ones that need changing, then switcheroo. | 22:39 |
| juliank | you can tell it to regenerate all, I accidentally did that earlier | 22:39 |
| juliank | this week I think | 22:40 |
| juliank | Not by using the option of course, but with a coding bug :D | 22:40 |
| juliank | I specifically requested cjwatson to review the security one, I think the other one is more harmless :) | 22:41 |
| juliank | We probably want to get rid of vivid, yakkety, and zesty on ddebs too | 22:42 |
| infinity | juliank: Commit message says "Import urllib.request instead of urllib", code imports both. Which is it? :P | 22:42 |
| juliank | ugh | 22:43 |
| juliank | it should have been instead | 22:43 |
| juliank | but it does not matter | 22:43 |
| infinity | Spoken like a professional software engineer. | 22:44 |
| infinity | How quickly you lose your student ideals. | 22:44 |
| juliank | infinity: I'd care if it was git | 22:44 |
| juliank | I'd rebase there | 22:44 |
| juliank | but in bzr? | 22:44 |
| infinity | In bzr, you'd just re-branch and try harder. | 22:45 |
| infinity | Since it's not in trunk yet. | 22:45 |
| infinity | Or stack an oops commit on top, whatever. :P | 22:45 |
| juliank | I just uncommit, shelve, and commit and push overwrite | 22:45 |
| tsimonq2 | *cough* https://github.com/mnauw/git-remote-bzr | 22:46 |
| tsimonq2 | I never touch Bazaar now thanks to that. | 22:46 |
| juliank | tsimonq2: how do you build bzr-buildpackage packages then? :D | 22:47 |
| tsimonq2 | Who does that anymore?!? >_< | 22:48 |
| juliank | infinity: I overwrote the MP misc-fixes now with a nice history | 22:48 |
| juliank | tsimonq2: some packages are still in bzr and nobody has time to convert all of them to git | 22:49 |
| nacc | <cough> | 22:49 |
| tsimonq2 | juliank: "nobody has time to convert all of them to git" try me :D | 22:50 |
| juliank | yes there's git-ubuntu, but that's a different topic | 22:50 |
| tsimonq2 | :D | 22:50 |
| nacc | :) | 22:51 |
| * juliank out. | 23:02 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!