/srv/irclogs.ubuntu.com/2017/06/01/#ubuntu-devel.txt

Unit193nacc!00:36
naccUnit193: what's up? :)00:37
Unit193nacc: I saw you alive!  Do you think you could take care of https://bugs.launchpad.net/bugs/1694864 and Bug 1692074?00:37
ubottuLaunchpad bug 1694864 in variety (Ubuntu) "Sync variety 0.6.4-1 (universe) from Debian experimental (main)" [Wishlist,New]00:38
ubottubug 1692074 in parsedatetime (Ubuntu) "Sync parsedatetime 2.3-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/169207400:38
naccUnit193: 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:39
Unit193I 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
naccUnit193: got it, i'll review it tmrw first thing00:40
Unit193nacc: Thanks very much!  (And the py3 module is useful because gcalcli had a beta release that goes python3, and recommends that.)00:41
naccUnit193: np00:41
Skuggennacc: /etc/mysql/debian.cnf is generated, yes06:12
SkuggenThough I actually have a change in review that will stop using it06:13
SkuggenLooks 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#n4106:22
juliankxnox: 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:36
juliankI 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 :(06:38
=== koza|away is now known as koza
jamespagexnox: around? I have a boost query to which I can't google the answer08:36
jamespagexnox: specifically I need boost_container for the latest ceph release, but afaict boost in Debian and Ubuntu does not build this component?08:36
jamespagebut my knowledge in this pkg is limited so I may be missing something08:37
jamespagexnox: raised some bugs to track - https://bugs.launchpad.net/ubuntu/+source/boost/+bugs?field.tag=ceph08:44
jamespagehave a second problem with no s390x packages for context or coroutine as well08:44
jamespageany help mucho appreciated08:45
infinityjuliank: +1 for a --download-only that does what it says on the tin.09:27
infinityjuliank: Amazed that none of the people involved in said changes noticed that -d doesn't really do a thing. :P09:27
juliankinfinity: Yeah09:27
juliankI was wondering if we want to play with phased updates in apt? That would be fun09:28
infinityjuliank: Let phasing percentage affect priority, or...?09:29
juliankHolding back updates that are not currently rolled out for the current machine in the current phase.09:30
infinityjuliank: 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
infinityjuliank: So, we'd have to re-teach that as "use some pinning", or "apt-get --ignore-phasing".09:30
juliankWell, we can make it optional.09:30
juliankand non-default.09:30
infinityOr that.09:30
juliankI think it might be useful to people who manage their systems with ansible or stuff09:31
infinityHaving the logic in apt so that frontends like update-manager can be dumber certainly seems like a win.09:31
juliankinfinity: and as a bonus point, this (can) also makes phased upgrades work with PackageKit.09:32
infinityI kinda wish PackageKit would just go away, but I realize I'm fighting a losing battle there.09:33
juliankAnd of course unattended-upgrades if configured to install SRUs too09:33
infinityIt'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:33
juliankaptd is still unmaintained, though :)09:34
infinityAnd, 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:34
infinitys/still/so/09:35
infinityBut I guess we need to reinvent every wheel every few years or we might accidentally make progress at some point.09:35
infinityAnd then the machines would take over.09:35
juliankinfinity: Yeah, but we'll eventually reach the point where enough stuff is there, so the "unmaintainedness" reached parity.09:36
infinityAnd then Terminator and/or The Matrix happens.09:36
infinityAnd no one wants that.09:36
juliankAnd once both options are basically equally bad, dropping the one that needs more attention will be the smart move :)09:36
infinityjuliank: 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:37
juliankNeed to track the list of missing things somewhere09:38
juliankCurrently 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:38
juliankinfinity: 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
infinityjuliank: 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:39
infinityjuliank: Maaaaybe?  I kinda hate the place where apt and apt-get commands produce different results.09:40
infinityjuliank: This is why, for instance, people whine when 'apt-get upgrade' doesn't install new deps, because 'apt upgrade' does.09:40
infinity(Though, in that case, I think apt-get just needs upgrade redefined)09:41
juliankI think the differences are not really a good thing, but it's sometimes the best we can get without breaking existing scripts.09:42
Unit193Amusingly, I was surprised the other way round, where `apt upgrade` wanted to.  I had to fall back.09:42
juliankI think some stuff should eventually migrate over to apt-get after 2 years09:43
infinityI 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:43
infinityMostly 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:45
infinityAnd 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. :P09:46
infinityDon'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:47
infinityjuliank: 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. :P09:50
infinityjuliank: 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:51
infinityjuliank: 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. :P09:53
infinityjuliank: 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:53
infinityjuliank: I mean, inconsequential behaviour differences like automatically cleaning up and whatnot are fine, but different outcomes are probably unwise.09:54
infinityjuliank: 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:54
infinityjuliank: 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:58
* infinity decides to try to nap.09:59
kyrofaHey apw, I need some SRU advice. Got a sec?10:03
apwkyrofa, ask i may (or may not) have a clue10:04
kyrofaapw, you're familiar with the snapcraft click SRU blockage10:04
apwkyrofa, i am aware of the "fun" you are going to be having yes10:05
kyrofaapw, well, the world just got bit by setuptools v3610:05
kyrofabug #169494510:05
ubottubug 1694945 in Snapcraft "setuptools v36.0.0 breaks the python plugin" [Undecided,New] https://launchpad.net/bugs/169494510:05
kyrofaapw, everyone building python snaps is now blocked until we can ship the fix for that10:05
apwkyrofa, lovely ...10:05
apwkyrofa, do we even have an upload fixing click ?10:06
kyrofaapw, in the fairy tale in my head, we just boot the pending SRU that uses click to get it out of the way10:06
kyrofaapw, no, click change is still in review10:06
apwkyrofa, so you want to rip the current snapcraft and replace it with a 2.29.1+* sort of thing ?10:07
kyrofaYes10:07
kyrofaThoughts?10:08
apwkyrofa, give me a sec to check ...10:08
kyrofaapw, 2.29.2 I suppose10:08
apwkyrofa, ok ... so yes, if i rip 2.30* you can then upload a 2.29.x with the python3 fix to unblock people10:10
sashokhello10:10
apwkyrofa, that _does_ kill 2.30* so you would need to go to 2.30.1 or something when it comes back10:10
kyrofaapw, excellent. But what about artful?10:10
kyrofaAh, we can apply the patch in two places10:11
kyrofaAnd just release 2.30.1 in a10:11
apwkyrofa, 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:11
apwkyrofa, so as long as you 2.30.1 that fix say then i think we are copestetic10:12
kyrofaapw, okay good deal. Can you please pull 2.30, then?10:12
apwkyrofa, so is that an official request for snapcraft/2.30* sru to die10:12
kyrofaapw, indeed it is10:12
kyrofaWe'll re-propose once the click fix is in10:13
kyrofaapw, this will be the only change between 2.29 and 2.29.1: https://github.com/snapcore/snapcraft/pull/1339/files10:15
kyrofaapw, think we can turn that around pretty quickly?10:16
apwkyrofa, ok removed (modulo publisher)10:16
apwkyrofa, yes, that is a serious regression aiui right, as in nothing snaps right now if it has python310:16
kyrofaOr python210:16
kyrofaIndeed, thank you for your help :)10:17
apwkyrofa, heh, that is likely 99% of snappers ...10:17
apwkyrofa, so you have an SRU exception which lets the release hold10:17
apwkyrofa, be shortened if you test it, and i assume you will do that quickly10:17
apwkyrofa, so ... if you could get those into the queue asap and ping me on #ubuntu-release as soon as they hit please10:18
kyrofaapw, you got it, thanks again!10:18
cpaelzerrbasak: (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.maintscript11:48
cpaelzerI want to complete my understanding of that, but that piece of the puzzle didn't reveal itself yet11:49
cpaelzersorry line 6 & 711:49
infinitycpaelzer: As opposed to any of the other similar lines?12:03
infinitycpaelzer: (Not sure I know what you're asking)12:03
infinitycpaelzer: 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:04
infinitycpaelzer: 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:05
infinitycpaelzer: 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:06
rbasaknacc: git ubuntu merge sync> ack12:30
rbasaknacc: 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:31
ubottuLaunchpad bug 1693954 in mysql-5.7 (Ubuntu) "package mysql-server-5.7 (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/169395412:31
cpaelzerthanks 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 names12:33
cpaelzerwhat does that achieve in addition to listing it once12:33
cpaelzerIn 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 lines12:34
rbasakcpaelzer: IIRC, dpkg-maintscript-helper will only act on a conffile if it is owned (as seen by dpkg) by the package listed.12:34
rbasakSo the two lines mean that the conffile with that name will be removed if owned by either package.12:34
rbasakPerhaps both packages dropped in that conffile in the past?12:35
infinitycpaelzer: Yeah, what rbasak said.12:35
infinitycpaelzer: If it's owned by one package and you call if for another, it should blissfully ignore your request to remove it.12:35
cpaelzerso the double line is a safety like "whoever owns it atm" in the mind of dpkg12:36
rbasakThat's the effect it has, yes.12:37
cpaelzerhrm, ok so in my case I know who owns it so I can list only one12:37
cpaelzerthank you both rbasak and infinity12:37
cpaelzerthis issue I'm on was just messy enough that I wanted to make sure I understand that bit as well12:38
infinitycpaelzer: 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
infinitycpaelzer: 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:39
cpaelzeryeah that is what dpkg-maintscript-helper told me as well12:40
infinitycpaelzer: 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:40
cpaelzerwhich is just where I am in now, but that solves it12:44
cpaelzerthe maintscript function ensure_package_owns_file e.g. on a mv_conffile will check source and target12:45
cpaelzerso if at the same time it renamed + moved between packages12:45
cpaelzerthen I need the double lines12:45
cpaelzerwhich is slightly different to the examples rm_conffile example, but still makes sense now12:46
cpaelzerthanks12:46
naccrbalint: thanks on the sql bug14:59
naccrbasak: --^ rather!14:59
naccSkuggen: ah thanks for the context, I was trying to figure that out without installing mysql myself in a test env :)15:00
slangasekLaney: fwiw debhelper 10.4 appears to cause cdbs to FTBFS22:50
slangasek(and possibly misbehave at runtime?)(22:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!