[00:50] <slangasek> stgraber: wrt LP: #1750013: my understanding (having gotten this wrong before myself and been corrected) is that new dependencies are fine for safe-upgrade, it's only removals-by-conflict that are a problem
[00:50] <ubot5`> Launchpad bug 1750013 in systemd (Ubuntu Trusty) "systemd-logind: memory leaks on session's connections (trusty-only)" [Medium,Fix committed] https://launchpad.net/bugs/1750013
[02:22] <stgraber> slangasek: hmm, odd. mvo specifically mentioned that apt logic when pushing against making squashfuse a recommends of snapd through SRU
[02:24] <infinity> slangasek: I don't know what safe-upgrade is, or even if humans use it, but upgrade won't allow any changes to install/remove status.  Which means no new deps.
[02:24] <infinity> slangasek: This was exactly the thing that led to the mess of silly snap-confine-related SRUs.
[02:25] <infinity> And also why I've argued for changing the behaviour of upgrade.
[02:27] <infinity> slangasek: Unless you're confusing "apt" and "apt-get" (where "apt upgrade" allows new deps, while "apt-get upgrade" doesn't)
[02:27] <infinity> But also, I find that argument spurious for rejecting an SRU.
[02:27] <infinity> Since we're saying "we care deeply about you getting systemd updates, but the fact that you use apt incorrectly and never get a kernel upgrade doesn't bug me".
[02:27] <infinity> stgraber: ^
[02:29] <stgraber> infinity: so IIRC we special-case the kernel in update-manager, but anything else which introduces a new deps makes it skip or print a bad warning (then again, I've not used the thing in a long time, so not sure of exact current behavior)
[02:29] <infinity> stgraber: No, that's flat out wrong.
[02:29] <infinity> stgraber: update-manager always allows new deps.
[02:30] <infinity> stgraber: This paranoia about new deps came about because some user failed to upgrade snapd with "apt-get upgrade".  That user also wasn't getting kernel updates.
[02:30] <infinity> stgraber: That user should have been told they were wrong, and that's all.
[02:34] <stgraber> oh, okay, I remembered it being force than that for some reason. If the only concern is someone running "apt-get upgrade", then yeah, that's definitely not a valid one.
[02:35] <stgraber> how does unattended-upgrade behave?
[02:36] <rbasak> AFAIK it works for kernels, because every so often some of my server VMs and containers end up with a full disk and I have to clear out a gazillion kernels.
[02:36] <rbasak> I'm not aware of any special casing of kernels in apt except for the autoremove blocking stuff.
[02:38] <infinity> stgraber: unattended-upgrades is new-ok-removal-not.
[02:38] <infinity> stgraber: So, same as 'apt upgrade'
[02:38] <infinity> stgraber: Literally the only thing that won't allow new deps is "apt-get upgrade", and while I contend that behaviour is a bug, it's also literally been like that since 1998.
[02:39] <infinity> stgraber: (And again, like I said, saying "we care if you get random-app updates, but not if you get kernel updates" is lolz)
[02:39] <infinity> stgraber: The special-casing in update-manager you might be thinking of is for removals.
[02:40] <infinity> stgraber: Where it doesn't allow removals, EXCEPT in a one-way Conflict/Replace pair.
[02:40] <infinity> stgraber: Which, while policy agrees update-manager is correct, it seems no other dpkg frontends do, and that's a unique feature. :P
[05:23] <nacc> tjaalton: do you plan on picking up this for mesa? https://patchwork.freedesktop.org/patch/201547/, fixes https://bugs.freedesktop.org/show_bug.cgi?id=104777 which i am hitting with wine on bionic
[05:23] <ubot5`> Freedesktop bug 104777 in Mesa core "Attaching multiple shader objects for the same stage to a GLSL program triggers a linker error" [Normal,Resolved: fixed]
[05:25] <nacc> tjaalton: sorry, probably this is a better ref: https://cgit.freedesktop.org/mesa/mesa/commit/?id=4195eed961ccfe404ae81b9112189fc93a254ded
[05:37] <tjaalton> nacc: it's already marked for 18.0
[05:37] <tjaalton> upstream, meaning it should get in the next rc
[05:37] <tjaalton> whenever that happens
[07:52] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1022.24]
[08:07] <tjaalton> slangasek: I've got nss-pem built with src:nss merged in and built first.. dunno which is less ugly, getting changes in src:nss or this
[10:40] <smb> while trying to clear up the last dependency problems preventing iproute2 leaving proposed in bionic, I found tunneldigger which seems to be the same version since at least precise and does not (or no longer) exist in Debian. Event though the version number of 0.10 suggests its a package that was synced at some point. I wonder whether that should go away, I mean the tunneldigger package
[10:41] <cascardo> smb: is that a reverse dependency?
[10:42] <smb> cascardo, for iproute2, yes. tunneldigger-utils does a depend on iproute
[10:43] <smb> and iproute2 latest dropped the iproute transitional package
[10:43] <apw> for what it is worth tunneldigger was uploaded first in hoary and never uploaded again, so it is going to supprise me if it works
[10:50] <apw> smb, and it definatly sync'd from debian and is not longer there
[10:52] <smb> Yeah, that is what https://tracker.debian.org/search?package_name=tunneldigger tells me
[12:15] -queuebot:#ubuntu-release- New source: nss-pem (bionic-proposed/primary) [1.0.3-0ubuntu1]
[12:23] <tjaalton> slangasek: oh well, uploaded nss-pem ^
[15:41] <nacc> tjaalton: and that is planned for 18.04 still?
=== icey_ is now known as icey
=== apw_ is now known as apw
[16:17] <xnox> slangasek, i think if you remove ruby-filepath, and my uploads are retried, ruby-defaults will migrate
[16:17] <xnox> https://bugs.launchpad.net/ubuntu/+source/ruby-filepath/+bug/1754464
[16:17] <ubot5`> Ubuntu bug 1754464 in ruby-filepath (Ubuntu) "remove broken ruby srcpkgs due to ruby-defaults stuck in bionic-proposed" [Undecided,Confirmed]
=== ahayzen_ is now known as ahayzen
[16:18] <xnox> nacc, fixed up puppet, should fix ruby-puppet-syntax, rbpdf, http.
[16:18] <xnox> nacc, so we should be done with this now.
[16:29] <nacc> xnox: excellent, nice work!
[16:30] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-144.193] (core, kernel)
[16:35] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-144.193]
[16:54] <ahasenack> hi, can someone please click on the ppc64el retry button for the gvfs test failure in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#samba
[16:54] <ahasenack> I checked the history and that test is flaky, and when it fails it's about ftp access, not samba
[16:54] <ahasenack> (samba triggered that test)
[17:09] <ahasenack> there is a bug about that gvfs test also
[17:17] <ahasenack> nacc: hi, could you perhaps do that for me please? ^ :)
[17:36] -queuebot:#ubuntu-release- New binary: firefox [ppc64el] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
[17:51] <tjaalton> nacc: yes
[17:52] <nacc> tjaalton: thanks
[17:52] <nacc> ahasenack: one moment
[17:53] <nacc> ahasenack: done
[17:53] <ahasenack> nacc: thanks
[18:14] <xnox> infinity, if you are around, it would be really nice to remove ruby-filepath, the only thing outstanding to migrate ruby-defaults (sans a few outstanding autopkgtest triggers with things in proposed)
[18:14] -queuebot:#ubuntu-release- New sync: mailman3 (bionic-proposed/primary) [3.1.1-6]
[18:14] <xnox> https://bugs.launchpad.net/ubuntu/+source/ruby-filepath/+bug/1754464
[18:14] <ubot5`> Ubuntu bug 1754464 in ruby-filepath (Ubuntu) "remove broken ruby srcpkgs due to ruby-defaults stuck in bionic-proposed" [Undecided,Confirmed]
[18:19] <Odd_Bloke> dpb1: ^
[18:20] <dpb1> nacc: ^
[18:27] <nacc> dpb1: yes, i know? :)
[18:28] <dpb1> not sure why Odd_Bloke did that
[18:28] <dpb1> he's trolling me
[18:29] <chrisccoulson> hi, can someone please approve the flash uploads that have been sat in partner for a few days?
[18:29] <nacc> dpb1: :)
[18:33] <Odd_Bloke> nacc: I wasn't trolling him, he'd asked me what the status was earlier.
[18:33] <Odd_Bloke> dpb1: ^
[18:33] <nacc> Odd_Bloke: :) yeah, i've been keeping him up to date
[18:34] <dpb1> Odd_Bloke: I asked you if you have been involved, just to clear my good name.
[18:35] <nacc> lol
[18:52] -queuebot:#ubuntu-release- New binary: firefox [amd64] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
[18:59] -queuebot:#ubuntu-release- New binary: firefox [i386] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
[19:14] <tsimonq2> infinity: Mind if I take care of bug 1750203?
[19:14] <ubot5`> bug 1750203 in base-files (Ubuntu) "Please merge 10.1 from Debian" [Undecided,New] https://launchpad.net/bugs/1750203
[19:14] <tsimonq2> infinity: I'm happy to do it unless you would like to.
[19:19] <tsimonq2> infinity, slangasek: It would also be good to get an ACK/NACK on bug 1756195.
[19:19] <ubot5`> bug 1756195 in sbuild (Ubuntu) "[FFe] Please merge sbuild 0.74.0-1 from Debian Sid" [Medium,New] https://launchpad.net/bugs/1756195
[19:58] -queuebot:#ubuntu-release- New binary: firefox [armhf] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
[20:14]  * xnox thinks i can fake ruby-filepath results
[20:32] <nacc> xnox: it just got removed :)
[20:37] <xnox> hahahha
[20:38] <xnox> i'm sorry
[20:38] <xnox> slangasek, nuke it from bionic-proposed too....
[20:38] <xnox> https://launchpad.net/ubuntu/+source/ruby-filepath/0.6-3ubuntu1
[20:40] <nacc> xnox: lol
[20:41] <tsimonq2> jbicha: fyi I can take bug 1756372
[20:41] <ubot5`> bug 1756372 in gtk+2.0 (Ubuntu) "Merge 2.24.32-1 from Debian" [Undecided,In progress] https://launchpad.net/bugs/1756372
[20:42] <slangasek> xnox: :P done
[20:52] -queuebot:#ubuntu-release- New binary: firefox [arm64] (bionic-proposed/main) [59.0.1+build1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
=== bluesabre_ is now known as bluesabr
=== bluesabr is now known as bluesabre
[21:44] <nacc> xnox: slangasek: so i think we're just waiting for the ruby-filepath deletion to be noticed and ruby-defaults should switch to valid candidate?
[21:44] <xnox> si
[21:44] <nacc> slangasek: do you need to delete the NBS ruby-filepath?
[21:45] <nacc> slangasek: i see the source gone, but the binaries are still listed per rmadison
[21:45] <slangasek> nacc: race condition, grr.  Yes, deleting now, thanks
[21:45] <nacc> slangasek: thanks!
[21:45] <slangasek> (though it likely wouldn't have impacted anything wrt ruby-defaults, I think, since that was only in -proposed)
[21:46] <nacc> slangasek: yeah, agreed
[21:46] <infinity> tsimonq2: Leave base-files to me.
[21:49] <tsimonq2> infinity: Then please do. ;)
[22:35] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-117.141~14.04.1] (kernel)
[23:49] <slangasek> tsimonq2: your falkon upload is broken, it has a transitional qupzilla binary that depends on a package that conflicts with it
[23:52] <tsimonq2> slangasek: I'm aware, and I was going to get to that tonight...
[23:53] <slangasek> k
[23:54] <slangasek> LocutusOfBorg: what's the rationale for syncing a new git-annex post-FF without the new version of datalad that satisfies the changed Breaks: ?
[23:56] <slangasek> smb: iproute2 isn't going anywhere because the new Debian version drops the 'iproute' transitional package which still has revdeps in the archive, if you want to fix those up...