[00:29] <Unit193> 'Start in 12 hours'  Geez, who uploaded KDE again?  Thanks for the geoip-database sync.
[01:35] <valorie> Unit193: KDE is the community, LOL
[01:35] <valorie> what was re-uploaded?
[03:52] <cjwatson> Unit193: Not so much KDE, more that we're in the middle of redeploying one of the builder clouds.
[03:52] <cjwatson> I'm only noseyparkering it but it looks like it should be done soon.
[10:10] <doko> xnox: how much do you care about gcc-arm-linux-androideabi ?
[10:11] <doko> hmm, and we have u-boot-linaro depending on gcc-4.7
[10:13] <xnox> doko, i thought it should be removed, once all the reverse deps are gone... no? cause it is ubuntu only package?
[10:13] <doko> yes, I would like to see it removed
[10:18] <xnox> doko, filed RM bug for android and gcc-arm-linux-androideabi -> https://bugs.launchpad.net/ubuntu/+source/gcc-arm-linux-androideabi/+bug/1717229
[10:19] <doko> do we know about u-boot-linaro?
[10:23] <xnox> that one is from 2012, just u-boot is from 2016.03 in ubuntu, and it is 2017.09 in debian experimental
[10:23] <xnox> (2017.07 in unstable)
[10:24] <xnox> ppisati, would you at all know if we use u-boot-linaro anywhere in ubuntu still? or is our u-boot package good enough for everything / everything got upstreamed?
[10:29] <xnox> opened RM bug for u-boot-linaro
[10:29] <xnox> https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/1717232
[10:33] <xnox> doko, is reverse-depends failing to parse deps, or does gcc-5-cross and gcc-6-cross really do build-depend on binary packages from gcc-4.7-armel-cross and gcc-4.7-armhf-cross
[10:37] <doko> no, they should not
[10:37] <doko> I think I never rebuilt these cross packages after introducing newer versions, so maybe the control file still has them?
[10:42] <xnox> doko, i think that reverse-depends is simply confused.
[10:44] <xnox> hm
[10:44] <ppisati> xnox: uhm, as far as i know, we don't use u-boot-linaro anywhere
[10:45] <ogra_> i think that came from the linaro mx5 images that we used to build in 12.04
[10:45] <ogra_> long dead
[10:45] <xnox> doko, both src:gcc-4.7-armel-cross and src:gcc-7-cross build libhfgcc1-armel-cross however for some reason $ reverse-depends picked the one with lower version number, rather than higher version.
[10:54] <juliank>  rbalint: I believe unattended-upgrades.service should gain a Before=apt-daily.service, so that when shutting down, and apt-daily.service is already running, unattended-upgrades.service stops after it.
[10:55] <juliank> um, apt-daily-upgrade.service too
[10:56] <juliank> A Before=B essentially means that A is stopped after B
[10:58] <juliank> slangasek: I noticed that if we ever do an apt security update, we also have to move unattended-upgrades to security, especially if we add a versioned dep on a u-u with --download-only support; otherwise the security update would not install automatically (as u-u would not pull in the new u-u from updates)
[10:59] <juliank> for xenial / zesty
[11:01] <juliank> Or well, let's hope it does not come to that in the near future, and build in a work around in apt
[11:13] <rbalint> juliank: why do you believe that ordering is needed?
[11:14] <rbalint> juliank: AFAIK recent apt-s do only downloads in apt-daily.service thus it can be killed without any consequence
[11:14] <juliank> rbalint: See second line
[11:14] <juliank> I actually meant apt-daily-upgrade.service
[11:15] <juliank> It's unclear if it's needed, but it seems like a good idea. Locking is a bit racy in some parts still, and AFAIUI, apt-daily-upgrade does not run to completion, so if you have this set, you'd want u-u.service to run after it to complete the task?
[11:15] <juliank> Otherwise, u-u.service might run while apt-daily-upgrade is running, and fail trying to get the lock, and won't run any remaining upgrades.
[11:16] <juliank> It's relatively unlikely too happen, probably, but still seems like a good idea
[11:16] <rbalint> juliank: depending on InstallOnShutdown = true or not u-u.service or apt.*service will perform the upgrade
[11:17] <rbalint> juliank: there is no case when both can upgrade, thus there is no case for taking over
[11:18] <juliank> Let's say you have 64 updates to install.
[11:18] <juliank> apt-daily-upgrade.service is running, but you shut down. It exits after 16 updates.
[11:18] <juliank> What happens to the remaining 48 ones?
[11:19] <juliank> or do you say apt-daily-upgrade.service will not run at all when Unattended-Upgrade::InstallOnShutdown is set
[11:19] <juliank> ?
[11:19] <rbalint> u-u.service shuts down the upgrade and does not take over
[11:19] <rbalint> juliank: the service will run, but u-u stops when calling from apt's service
[11:20] <rbalint> juliank: https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade#L1535
[11:21] <juliank> aye, then it's fine
[11:21] <rbalint> juliank: https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade-shutdown#L134
[11:21] <juliank> sorry about the confusion
[11:21] <rbalint> juliank: no problem, this was not clear to me before diving into u-u code :-)
[11:22] <juliank> There's still some other maintenance cleanup crap done in apt-daily-upgrade.service if the options are enabled
[11:22] <rbalint> juliank: if you find something racy in u-u please report it, because i'd like to make it rock-solid
[11:23] <juliank> Well, the other stuff we do is running clean and autoclean after u-u if the options are set. But then, if you use install on shutdown, they simply are not compatible.
[11:24] <juliank> I should push guillem about the whole frontend lock to get any remaining lock race conditions fixed.
[11:26] <rbalint> juliank: from not breaking the system POV they are safe https://anonscm.debian.org/git/apt/apt.git/tree/debian/apt.systemd.daily#n507
[11:26] <juliank> indeed, that they are.
[11:26] <juliank> But don't enable them together or there will be no packages left to install on shutdown :D
[11:26] <juliank> or well, u-u will redownload them
[11:27] <rbalint> juliank:yes, it will redownload
[11:29] <rbalint> juliank: if there are still upgrade-able packages apt could keep the cache
[11:29] <juliank> rbalint: Well, that's what happens if you only use autoclean :)
[11:29] <juliank> Just don't set the option to run clean :D
[11:29]  * juliank should drop that option probably
[11:30] <juliank> Although maybe some people do really need an option to regularly delete all cached packages, who knows.
[11:30] <juliank> (like, they have a fast local mirror and don't bother with caching)
[11:32] <rbalint> juliank: by default InstallOnShutdown is false thus the default apt service works as expected with either clean or autoclean
[11:33] <juliank> true, and they are off by default too. it was mostly just a funny remark
[15:32] <doko> slangasek: your libhybris upload ftbfs
[15:33] <doko>         * malloc/malloc.c (cfree): Turn into compat symbol.
[15:33] <doko>         (__cfree): Remove alias.
[15:33] <doko>         * stdlib/stdlib.h (cfree): Remove declaration.
[15:33] <doko>         * malloc/malloc.h (cfree): Likewise.
[15:33] <doko>         * manual/memory.texi (Freeing after Malloc): Remove cfree.
[15:46] <doko> can't find the vwrite change ...
[15:58] <slangasek> doko: yes, already discussed that libhybris ftbfs with infinity on #ubuntu-release last night; and wondered if morphis__ would want to care about this
[15:59] <doko> slangasek: I stand corrected about the inclusion of -proposed. it's possible. but I think we don't want it
[16:02] <slangasek> doko: fwiw in this case I disagree; in general we always build with -proposed enabled in the main archive, and we know that there's almost nothing of relevance in -proposed right now that is both a build dependency and not targeted for release
[16:03] <doko> slangasek: sure, but we empy -proposed for the release
[16:10] <slangasek> doko: yes, but it's already pretty empty right now, compared to past releases... and I've said that we should be trying to drive -proposed to zero throughout the cycle, not just emptying it at release... so the delta in terms of ftbfs false-positives/negatives should be small here
[16:11] <doko> pretty empty? cough ...
[16:18] <cjwatson> doko: we have graphs of this stuff :-)  http://people.canonical.com/~ubuntu-archive/proposed-migration/history.html
[16:18] <cjwatson> ah, hmm, but that's only for this release
[16:19] <cjwatson> not quite the proof I was looking for
[19:30] <pitti> Laney: you restored the second cloud yesterday or today, right? are you aware of any configuration chagnes that could explain failures like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-systemd-semaphore/xenial/amd64/s/systemd-upstream/20170914_160700_910ad@/log.gz ?
[19:31] <pitti> Laney: exact same xenial cloud image as in a successful run from two days ago, same downstream packages, tests with that PR's debs work  locally
[19:36] <pitti> Laney: ah, nevermind, got it reproduced