[00:36] <Unit193> nacc!
[00:37] <nacc> Unit193: what's up? :)
[00:37] <Unit193> nacc: I saw you alive!  Do you think you could take care of https://bugs.launchpad.net/bugs/1694864 and Bug 1692074?
[00:39] <nacc> Unit193: i can look -- although EOD for me already (might be tmrw). Is there a reason we want to sync from experimental specifically for these two?
[00:40] <Unit193> I figured it was getting close, yeah.  variety is only in experimental due to the freeze, changelog lists a LP bug, and Debian maintainer is very good with the sync.  Latter because it gives a py3 module.
[00:40] <nacc> Unit193: got it, i'll review it tmrw first thing
[00:41] <Unit193> nacc: Thanks very much!  (And the py3 module is useful because gcalcli had a beta release that goes python3, and recommends that.)
[00:41] <nacc> Unit193: np
[06:12] <Skuggen> nacc: /etc/mysql/debian.cnf is generated, yes
[06:13] <Skuggen> Though I actually have a change in review that will stop using it
[06:22] <Skuggen> Looks like it's using /etc/init.d/mysql to try to shutdown any existing server, which is a bit odd https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/tree/debian/mysql-server-5.7.preinst?h=mysql-5.7/ubuntu/zesty#n41
[06:36] <juliank> xnox: OK, so apparently the apt systemd jobs are wrong, I accidentally passed -d to unattended-upgrades for download, but that enables debug mode - and nobody noticed it. Seems this needs more work.
[06:38] <juliank> I wanted --dry-run according to --help, but in reality that also has some debugging output, so we really need to patch unattended-upgrade to have a download-only mode :(
[08:36] <jamespage> xnox: around? I have a boost query to which I can't google the answer
[08:36] <jamespage> xnox: specifically I need boost_container for the latest ceph release, but afaict boost in Debian and Ubuntu does not build this component?
[08:37] <jamespage> but my knowledge in this pkg is limited so I may be missing something
[08:44] <jamespage> xnox: raised some bugs to track - https://bugs.launchpad.net/ubuntu/+source/boost/+bugs?field.tag=ceph
[08:44] <jamespage> have a second problem with no s390x packages for context or coroutine as well
[08:45] <jamespage> any help mucho appreciated
[09:27] <infinity> juliank: +1 for a --download-only that does what it says on the tin.
[09:27] <infinity> juliank: Amazed that none of the people involved in said changes noticed that -d doesn't really do a thing. :P
[09:27] <juliank> infinity: Yeah
[09:28] <juliank> I was wondering if we want to play with phased updates in apt? That would be fun
[09:29] <infinity> juliank: Let phasing percentage affect priority, or...?
[09:30] <juliank> Holding back updates that are not currently rolled out for the current machine in the current phase.
[09:30] <infinity> juliank: The problem is that, so far, "apt-get dist-upgrade" has been the published way to get updates *now*, if you don't want to deal with update-manager's phasing.
[09:30] <infinity> juliank: So, we'd have to re-teach that as "use some pinning", or "apt-get --ignore-phasing".
[09:30] <juliank> Well, we can make it optional.
[09:30] <juliank> and non-default.
[09:30] <infinity> Or that.
[09:31] <juliank> I think it might be useful to people who manage their systems with ansible or stuff
[09:31] <infinity> Having the logic in apt so that frontends like update-manager can be dumber certainly seems like a win.
[09:32] <juliank> infinity: and as a bonus point, this (can) also makes phased upgrades work with PackageKit.
[09:33] <infinity> I kinda wish PackageKit would just go away, but I realize I'm fighting a losing battle there.
[09:33] <juliank> And of course unattended-upgrades if configured to install SRUs too
[09:33] <infinity> It's all fine and dandy for people to tell me PK is the new hotness and aptdaemon is unmaintained crap, but aptd does what we want and PK (so far) doesn't.
[09:34] <juliank> aptd is still unmaintained, though :)
[09:34] <infinity> And, from my POV, still is PK if it doesn't have feature parity.
[09:34] <infinity> "Maintained, but isn't useful" is pretty much "unmaintained".
[09:35] <infinity> s/still/so/
[09:35] <infinity> But I guess we need to reinvent every wheel every few years or we might accidentally make progress at some point.
[09:35] <infinity> And then the machines would take over.
[09:36] <juliank> infinity: Yeah, but we'll eventually reach the point where enough stuff is there, so the "unmaintainedness" reached parity.
[09:36] <infinity> And then Terminator and/or The Matrix happens.
[09:36] <infinity> And no one wants that.
[09:36] <juliank> And once both options are basically equally bad, dropping the one that needs more attention will be the smart move :)
[09:37] <infinity> juliank: Sure.  And, conceptually, a single API into all package managers is a noble goal.  But until it can replace the things we've historically done with aptd, I just don't see the motivation to care.
[09:38] <juliank> Need to track the list of missing things somewhere
[09:38] <juliank> Currently I only have "phased updates" and "not reboot for upgrades"
[09:38] <infinity> "I'm sorry your fully-functional Honda sedan is out of warranty and might need occasional service, please switch to this trout-drawn red wagon."
[09:39] <juliank> infinity: re phased updates in apt, maybe it makes sense to compromise on apt (the friendly frontend) doing phased updates, and apt-get doing unphased.
[09:39] <infinity> juliank: Maybe it's come a long way since the last time I looked.  Historically, it was pretty much useless at doing anything remotely complex.  Whereas aptd was literally just a way to escalate "apt-get <command> <arguments>" to a priveleged backend, so could literally do anything apt could do.
[09:40] <infinity> juliank: Maaaaybe?  I kinda hate the place where apt and apt-get commands produce different results.
[09:40] <infinity> juliank: This is why, for instance, people whine when 'apt-get upgrade' doesn't install new deps, because 'apt upgrade' does.
[09:41] <infinity> (Though, in that case, I think apt-get just needs upgrade redefined)
[09:42] <juliank> I think the differences are not really a good thing, but it's sometimes the best we can get without breaking existing scripts.
[09:42] <Unit193> Amusingly, I was surprised the other way round, where `apt upgrade` wanted to.  I had to fall back.
[09:43] <juliank> I think some stuff should eventually migrate over to apt-get after 2 years
[09:43] <infinity> I think it's a mistake (and has been since day 1), that "apt-get upgrade" doesn't install new deps.  Refusing removals is good, refusing new installation is obtuse.  But that's going to be a long debate.
[09:45] <infinity> Mostly I believe this due to the way we abuse new installs for kernel packages, but it's equally true that you wouldn't want a security upgrade held back because it needs to pull in a new benign dep, etc.
[09:46] <infinity> And after some longwinded bug reports that proved we have many users who think that "apt-get upgrade" is keeping them up to date, I'm now terrified that we have thousands of machines out there that have never had a kernel upgrade since GA. :P
[09:47] <infinity> Don't know if this is because of "apt upgrade", or yum/dnf semantics being different, or bad advice on forums/stackexchange, or just because "upgrade" should probably upgrade your machine, but the damage is done, and I don't think we can reeducate.
[09:50] <infinity> juliank: So, yeah, I think changing behaviour of "apt-get upgrade" for 18.04 and stretch+1 (cause that's definitely not somewhere where Ubuntu should gratuitously differentiate) would be a very worthwhile thing to debate for about 10 minutes and then JFDI regardless of dissent. :P
[09:51] <infinity> juliank: As for phased versus not.  Maybe apt could behave differently.  It would need to be very well called out in the docs how to turn it on for apt-get and off for apt and what the defaults are.
[09:53] <infinity> juliank: Though, if the supposed intent is that "noobs" use apt and long-bearded fuddy-duddies use apt-get, I'm not sure that'll ever really come to pass, because when someone like me tells people how to do a thing, I do it in my language (apt-get), and that gets cargo-culted all over until someone copies and pastes it blindly. :P
[09:53] <infinity> juliank: So, at the end of the day, I'm not sure behaviour difference between identical invocations should ever exist, as the "noob" won't even really know they're different commands or why, except that one is prettier.
[09:54] <infinity> juliank: I mean, inconsequential behaviour differences like automatically cleaning up and whatnot are fine, but different outcomes are probably unwise.
[09:54] <infinity> juliank: Cause I say "run apt-get install foo bar-" and they run "apt install foo bar-" and wonder why it's different (if it is, but you get my point).
[09:58] <infinity> juliank: This isn't without precedent.  We had the same issue when people socialised the incorrect meme that "aptitude install <foo>" == "apt-get install <foo>", and it really wasn't.  It was sometimes a debugging nightmare.
[09:59]  * infinity decides to try to nap.
[10:03] <kyrofa> Hey apw, I need some SRU advice. Got a sec?
[10:04] <apw> kyrofa, ask i may (or may not) have a clue
[10:04] <kyrofa> apw, you're familiar with the snapcraft click SRU blockage
[10:05] <apw> kyrofa, i am aware of the "fun" you are going to be having yes
[10:05] <kyrofa> apw, well, the world just got bit by setuptools v36
[10:05] <kyrofa> bug #1694945
[10:05] <kyrofa> apw, everyone building python snaps is now blocked until we can ship the fix for that
[10:05] <apw> kyrofa, lovely ...
[10:06] <apw> kyrofa, do we even have an upload fixing click ?
[10:06] <kyrofa> apw, in the fairy tale in my head, we just boot the pending SRU that uses click to get it out of the way
[10:06] <kyrofa> apw, no, click change is still in review
[10:07] <apw> kyrofa, so you want to rip the current snapcraft and replace it with a 2.29.1+* sort of thing ?
[10:07] <kyrofa> Yes
[10:08] <kyrofa> Thoughts?
[10:08] <apw> kyrofa, give me a sec to check ...
[10:08] <kyrofa> apw, 2.29.2 I suppose
[10:10] <apw> kyrofa, ok ... so yes, if i rip 2.30* you can then upload a 2.29.x with the python3 fix to unblock people
[10:10] <sashok> hello
[10:10] <apw> kyrofa, that _does_ kill 2.30* so you would need to go to 2.30.1 or something when it comes back
[10:10] <kyrofa> apw, excellent. But what about artful?
[10:11] <kyrofa> Ah, we can apply the patch in two places
[10:11] <kyrofa> And just release 2.30.1 in a
[10:11] <apw> kyrofa, well there is nearly noone up there right?  and the two people who have click installed will have already been in the poo (such as me)
[10:12] <apw> kyrofa, so as long as you 2.30.1 that fix say then i think we are copestetic
[10:12] <kyrofa> apw, okay good deal. Can you please pull 2.30, then?
[10:12] <apw> kyrofa, so is that an official request for snapcraft/2.30* sru to die
[10:12] <kyrofa> apw, indeed it is
[10:13] <kyrofa> We'll re-propose once the click fix is in
[10:15] <kyrofa> apw, this will be the only change between 2.29 and 2.29.1: https://github.com/snapcore/snapcraft/pull/1339/files
[10:16] <kyrofa> apw, think we can turn that around pretty quickly?
[10:16] <apw> kyrofa, ok removed (modulo publisher)
[10:16] <apw> kyrofa, yes, that is a serious regression aiui right, as in nothing snaps right now if it has python3
[10:16] <kyrofa> Or python2
[10:17] <kyrofa> Indeed, thank you for your help :)
[10:17] <apw> kyrofa, heh, that is likely 99% of snappers ...
[10:17] <apw> kyrofa, so you have an SRU exception which lets the release hold
[10:17] <apw> kyrofa, be shortened if you test it, and i assume you will do that quickly
[10:18] <apw> kyrofa, so ... if you could get those into the queue asap and ping me on #ubuntu-release as soon as they hit please
[10:18] <kyrofa> apw, you got it, thanks again!
[11:48] <cpaelzer> rbasak: (and others) I still wonder about one thing on conffile handling - when looking e.g. at the following what is the reason/beneift of having line 5&6 ? https://anonscm.debian.org/cgit/pkg-libvirt/libvirt.git/tree/debian/libvirt-daemon-system.maintscript
[11:49] <cpaelzer> I want to complete my understanding of that, but that piece of the puzzle didn't reveal itself yet
[11:49] <cpaelzer> sorry line 6 & 7
[12:03] <infinity> cpaelzer: As opposed to any of the other similar lines?
[12:03] <infinity> cpaelzer: (Not sure I know what you're asking)
[12:04] <infinity> cpaelzer: But, in a nutshell, when a conffile is no longer shipped by a package, it's not removed until the package is purged.  So, on upgrade, you accumulate cruft if you keep removing conffiles from the package without doing something about it.
[12:05] <infinity> cpaelzer: In the bad old days, that "something" would just be an rm -f ... rm_conffile makes some attempts to preserve the file if it was modified by the end user, so they can preserve their changes elsewhere, or translate them to the new world order.
[12:06] <infinity> cpaelzer: Though, in the case of a "shipped by accident" file, like 6&7, I could see an argument for just unconditionally whacking it, it also doesn't hurt to use the rm_conffile facility on the off chance someone *thought* it was a useful file and made changes to it, so they can consult those changes and put them in the right file(s).
[12:30] <rbasak> nacc: git ubuntu merge sync> ack
[12:31] <rbasak> nacc: LP: #1693954> I marked Incomplete. Seems likely that the user deleted that file locally, or has otherwise hacked things up. Or if not, then we need a proper bug report really, rather than a "I have an error message" report.
[12:33] <cpaelzer> thanks infinity, I think I got the general need for conffile removal - what I asked in particular on line 6 & 7 is that it is the SAME line but with different package names
[12:33] <cpaelzer> what does that achieve in addition to listing it once
[12:34] <cpaelzer> In that case the file "ownership" moved in the past, I assume it might be about removing it "from both packages" - but the file goes away on either invocation, so why listing both lines
[12:34] <rbasak> cpaelzer: IIRC, dpkg-maintscript-helper will only act on a conffile if it is owned (as seen by dpkg) by the package listed.
[12:34] <rbasak> So the two lines mean that the conffile with that name will be removed if owned by either package.
[12:35] <rbasak> Perhaps both packages dropped in that conffile in the past?
[12:35] <infinity> cpaelzer: Yeah, what rbasak said.
[12:35] <infinity> cpaelzer: If it's owned by one package and you call if for another, it should blissfully ignore your request to remove it.
[12:36] <cpaelzer> so the double line is a safety like "whoever owns it atm" in the mind of dpkg
[12:37] <rbasak> That's the effect it has, yes.
[12:37] <cpaelzer> hrm, ok so in my case I know who owns it so I can list only one
[12:37] <cpaelzer> thank you both rbasak and infinity
[12:38] <cpaelzer> this issue I'm on was just messy enough that I wanted to make sure I understand that bit as well
[12:39] <infinity> cpaelzer: You shouldn't need to list <package> at all, if you're doing the rm_conffile bits in the right package's maintainer scripts.
[12:39] <infinity> cpaelzer: And, in fact, it's better if you don't, cause then you also don't have to think about if you should or shouldn't have an arch qualifier, etc.
[12:40] <cpaelzer> yeah that is what dpkg-maintscript-helper told me as well
[12:40] <infinity> cpaelzer: The libvirt case above was super special because he was using one package's maint scripts to remove a conffile that was potentially in a different (and no longer existent) package previously.
[12:44] <cpaelzer> which is just where I am in now, but that solves it
[12:45] <cpaelzer> the maintscript function ensure_package_owns_file e.g. on a mv_conffile will check source and target
[12:45] <cpaelzer> so if at the same time it renamed + moved between packages
[12:45] <cpaelzer> then I need the double lines
[12:46] <cpaelzer> which is slightly different to the examples rm_conffile example, but still makes sense now
[12:46] <cpaelzer> thanks
[14:59] <nacc> rbalint: thanks on the sql bug
[14:59] <nacc> rbasak: --^ rather!
[15:00] <nacc> Skuggen: ah thanks for the context, I was trying to figure that out without installing mysql myself in a test env :)
[22:50] <slangasek> Laney: fwiw debhelper 10.4 appears to cause cdbs to FTBFS
[22:51] <slangasek> (and possibly misbehave at runtime?)(