[00:02] <bdmurray> slangasek: "I think it's better" so bdmurray should do it?
[00:05] <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:06] <slangasek> bdmurray: ok, done
[00:06] <slangasek> (modulo the delay of updating 22 bugs)
[00:07] <jbicha> slangasek: do you have time to review libreoffice & gnome-desktop3 in the bionic NEW queue?
[00:08] <slangasek> jbicha: no, because I'm currently reviewing older stuff in said queue
[00:08] <jbicha> cool, thanks
[00:10] -queuebot:#ubuntu-release- New: accepted nm-tray [source] (bionic-proposed) [0.3.0-0ubuntu1]
[00:10] <tsimonq2> \o/
[00:12] -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:13] -queuebot:#ubuntu-release- New binary: nm-tray [i386] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset)
[00:14] -queuebot:#ubuntu-release- New binary: nm-tray [armhf] (bionic-proposed/none) [0.3.0-0ubuntu1] (no packageset)
[00:15] -queuebot:#ubuntu-release- New binary: nm-tray [arm64] (bionic-proposed/universe) [0.3.0-0ubuntu1] (no packageset)
[00:17] <sarnold> for the unity / compiz thing I've duped a few bugs to 1749840
[00:17] <tsimonq2> thanks
[00:28] -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:29] -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:30] -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:33] <doko> who's accepting binaries before they are built on all archs?
[00:34] <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:38] <slangasek> possibly me
[00:40] <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:47] <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:51] <slangasek> you could also run new-binary-debian-universe ;)
[01:25] <tsimonq2> up to seven dups: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1749840
[01:54] <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...)
[02:23] -queuebot:#ubuntu-release- New source: calamares-settings-ubuntu (bionic-proposed/primary) [1]
[08:21] -queuebot:#ubuntu-release- New: rejected calamares-settings-ubuntu [source] (bionic-proposed) [1]
[08:21] <apw> tsimonq2, ^
[08:37] -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]
[10:39] <doko> who is working on Kylin these days?
[10:40] <doko> asking for https://launchpadlibrarian.net/357258908/buildlog_ubuntu-bionic-amd64.ubuntu-kylin-sso-client_0.1.2.4_BUILDING.txt.gz
[10:45] <doko> https://bugs.launchpad.net/ubuntu/+source/ubuntu-kylin-sso-client/+bug/1749924
[11:24] <rbasak> Could an AA review libzstd in Xenial binNEW please? It's related to maintaining the upgrade path in an SRU.
[11:27] <sil2100> rbasak: you ACKed the SRU, right?
[11:27] <rbasak> sil2100: yes
[11:28] <sil2100> rbasak: in that case I can do that, one moment
[11:35] <rbasak> ahasenack: ^
[11:36] <ahasenack> thx
[11:38] <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:39] <ahasenack> both come from the same source package which is sssd
[11:45] <rbasak> sil2100: thanks!
[12:09] <jbicha> doko: there is a #ubuntukylin-devel channel
[14:05] <tsimonq2> apw: Thanks :)
[14:16] <apw> ahasenack, have you found the MIR for that, that let the py2 in ?
[14:17] <ahasenack> apw: I didn't check, since it was in main already (as is sssd itself)
[14:35] <apw> ahasenack, ok found it
[14:37] <apw> ahasenack, ok poked
[16: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:38] <tsimonq2> Does anto
[16:39] <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:40] <slangasek> tsimonq2: what are you seeing?
[16:40] <tsimonq2> slangasek: Curious about juliank's question on bug 1714451
[16:40] <tsimonq2> er
[16:40] <tsimonq2> wrong one
[16:41] <tsimonq2> bug 1746807
[16:41] <tsimonq2> that :)
[16:41]  * juliank too
[16:41] <juliank> probably there are different version, but I don't remember
[16:42] <juliank> I think we jumped from alpha5 to alpha7
[16:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <juliank> and disc://
[16:53] <slangasek> twitch
[16:53] <juliank> I don't know
[16:54] <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:55] <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:56] <juliank> If only to annoy BBC folks
[16:57]  * 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
[17:11] -queuebot:#ubuntu-release- New binary: python-skytools [s390x] (bionic-proposed/none) [3.3-2] (no packageset)
[17:12] -queuebot:#ubuntu-release- New binary: eo-spell [amd64] (bionic-proposed/main) [2.1.2000.02.25-55] (ubuntu-desktop)
[17:13] -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:15] -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:16] -queuebot:#ubuntu-release- New binary: lua-ljsyscall [amd64] (bionic-proposed/universe) [0.12-1] (no packageset)
[17:18] -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:19] -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:22] -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:23] -queuebot:#ubuntu-release- New binary: python-skytools [ppc64el] (bionic-proposed/universe) [3.3-2] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: quaternion [arm64] (bionic-proposed/universe) [0.0.5-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: quaternion [ppc64el] (bionic-proposed/universe) [0.0.5-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: quaternion [armhf] (bionic-proposed/universe) [0.0.5-1] (no packageset)
[18:41] -queuebot:#ubuntu-release- Unapproved: supermin (xenial-proposed/universe) [5.1.14-2ubuntu1 => 5.1.14-2ubuntu1.1] (no packageset)
[18:58] <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:59] <nacc> i'm assuming the artful package should be copied forward?
[19:05] <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:06] <nacc> they can manually workaround with libc6= libc6-dev= libc6-i386= to downgrade to the bionic version, but that's not great UX :)
[19:28] <nacc> slangasek: --^ maybe you can help as i think it will take a AA
[19:30] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-116.140~14.04.1] (kernel)
[19:43] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-116.140~14.04.1]
[20:18] -queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (xenial-proposed/main) [3.18.0-2ubuntu1 => 3.18.0-2ubuntu2] (ubuntu-desktop)
[20:24] -queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (artful-proposed/main) [3.22.3-1ubuntu1 => 3.22.3-1ubuntu2] (ubuntu-desktop)
[20:27] <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:33] <bdmurray> slangasek: Now that ddebs is fixed - https://code.launchpad.net/~brian-murray/apport/lp-retracer-bionic-updates/+merge/337676
[20:39] <slangasek> bdmurray: merged, thanks!
[20:39] <tsimonq2> Out of curiosity, I wonder why ddebs.ubuntu.com doesn't have anything for *-security.
[20:42] <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:44] <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:45] <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:46] <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:47] <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:48] <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:50] <slangasek> bdmurray: do you think this is important enough to put on our backlog?
[20:51] <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:52] <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:53] <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:54] <tsimonq2> ¯\_(ツ)_/¯
[21:09] <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:10] <bdmurray> tsimonq2: I'm pretty sure the debug symbols are available on LP if someone really needed them.
[21:14] <tsimonq2> bdmurray: You can say the same for all other packages ;)
[21:14] <tsimonq2> slangasek: right, ok
[21:37] <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:38] <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:39] <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:41] <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
[22:09] <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:10] <juliank> oh no
[22:10] <juliank> one more
[22:10] <juliank> http://paste.ubuntu.com/p/JVTHsZv63Z/
[22:11] <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:12] <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:13] <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:14] <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:15] <infinity> Otherwise, you risk flushing the a-f caches between each run.
[22:15] <juliank> We might be able too
[22:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <juliank> ddeb-retriever is very interesting because the code is easy to follow.
[22:29] <juliank> but it's next to impossible to test
[22:30] <juliank> archive_tools in it has unit tests, but a lot of them fail
[22:30] <juliank> ah just some import messup
[22:32]  * juliank sends MP
[22:33] <nacc> slangasek: could use some AA love to new packages in LP: #1749783
[22:38] <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:39] <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:40] <juliank> this week I think
[22:40] <juliank> Not by using the option of course, but with a coding bug :D
[22:41] <juliank> I specifically requested cjwatson to review the security one, I think the other one is more harmless :)
[22:42] <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:43] <juliank> ugh
[22:43] <juliank> it should have been instead
[22:43] <juliank> but it does not matter
[22:44] <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:45] <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:46] <tsimonq2> *cough* https://github.com/mnauw/git-remote-bzr
[22:46] <tsimonq2> I never touch Bazaar now thanks to that.
[22:47] <juliank> tsimonq2: how do you build bzr-buildpackage packages then? :D
[22:48] <tsimonq2> Who does that anymore?!? >_<
[22:48] <juliank> infinity: I overwrote the MP misc-fixes now with a nice history
[22:49] <juliank> tsimonq2: some packages are still in bzr and nobody has time to convert all of them to git

[22:50] <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:51] <nacc> :)
[23:02]  * juliank out.