[00:29] 'Start in 12 hours' Geez, who uploaded KDE again? Thanks for the geoip-database sync. [01:35] Unit193: KDE is the community, LOL [01:35] what was re-uploaded? [03:52] Unit193: Not so much KDE, more that we're in the middle of redeploying one of the builder clouds. [03:52] I'm only noseyparkering it but it looks like it should be done soon. === Guest52925 is now known as RAOF [10:10] xnox: how much do you care about gcc-arm-linux-androideabi ? [10:11] hmm, and we have u-boot-linaro depending on gcc-4.7 [10:13] doko, i thought it should be removed, once all the reverse deps are gone... no? cause it is ubuntu only package? [10:13] yes, I would like to see it removed [10:18] doko, filed RM bug for android and gcc-arm-linux-androideabi -> https://bugs.launchpad.net/ubuntu/+source/gcc-arm-linux-androideabi/+bug/1717229 [10:18] Launchpad bug 1717229 in android (Ubuntu) "RM: obsolete product" [High,Triaged] [10:19] do we know about u-boot-linaro? [10:23] that one is from 2012, just u-boot is from 2016.03 in ubuntu, and it is 2017.09 in debian experimental [10:23] (2017.07 in unstable) [10:24] 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] opened RM bug for u-boot-linaro [10:29] https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/1717232 [10:29] Launchpad bug 1717232 in u-boot-linaro (Ubuntu) "RM: duplicate package" [High,Triaged] [10:33] 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] no, they should not [10:37] I think I never rebuilt these cross packages after introducing newer versions, so maybe the control file still has them? [10:42] doko, i think that reverse-depends is simply confused. [10:44] hm [10:44] xnox: uhm, as far as i know, we don't use u-boot-linaro anywhere [10:45] i think that came from the linaro mx5 images that we used to build in 12.04 [10:45] long dead [10:45] 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] 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] um, apt-daily-upgrade.service too [10:56] A Before=B essentially means that A is stopped after B [10:58] 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] for xenial / zesty [11:01] 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] juliank: why do you believe that ordering is needed? [11:14] juliank: AFAIK recent apt-s do only downloads in apt-daily.service thus it can be killed without any consequence [11:14] rbalint: See second line [11:14] I actually meant apt-daily-upgrade.service [11:15] 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] 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] It's relatively unlikely too happen, probably, but still seems like a good idea [11:16] juliank: depending on InstallOnShutdown = true or not u-u.service or apt.*service will perform the upgrade [11:17] juliank: there is no case when both can upgrade, thus there is no case for taking over [11:18] Let's say you have 64 updates to install. [11:18] apt-daily-upgrade.service is running, but you shut down. It exits after 16 updates. [11:18] What happens to the remaining 48 ones? [11:19] or do you say apt-daily-upgrade.service will not run at all when Unattended-Upgrade::InstallOnShutdown is set [11:19] ? [11:19] u-u.service shuts down the upgrade and does not take over [11:19] juliank: the service will run, but u-u stops when calling from apt's service [11:20] juliank: https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade#L1535 [11:21] aye, then it's fine [11:21] juliank: https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade-shutdown#L134 [11:21] sorry about the confusion [11:21] juliank: no problem, this was not clear to me before diving into u-u code :-) [11:22] There's still some other maintenance cleanup crap done in apt-daily-upgrade.service if the options are enabled [11:22] juliank: if you find something racy in u-u please report it, because i'd like to make it rock-solid [11:23] 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] I should push guillem about the whole frontend lock to get any remaining lock race conditions fixed. [11:26] 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] indeed, that they are. [11:26] But don't enable them together or there will be no packages left to install on shutdown :D [11:26] or well, u-u will redownload them [11:27] juliank:yes, it will redownload [11:29] juliank: if there are still upgrade-able packages apt could keep the cache [11:29] rbalint: Well, that's what happens if you only use autoclean :) [11:29] Just don't set the option to run clean :D [11:29] * juliank should drop that option probably [11:30] Although maybe some people do really need an option to regularly delete all cached packages, who knows. [11:30] (like, they have a fast local mirror and don't bother with caching) [11:32] juliank: by default InstallOnShutdown is false thus the default apt service works as expected with either clean or autoclean [11:33] true, and they are off by default too. it was mostly just a funny remark === JanC is now known as Guest66311 === JanC_ is now known as JanC [15:32] slangasek: your libhybris upload ftbfs [15:33] * malloc/malloc.c (cfree): Turn into compat symbol. [15:33] (__cfree): Remove alias. [15:33] * stdlib/stdlib.h (cfree): Remove declaration. [15:33] * malloc/malloc.h (cfree): Likewise. [15:33] * manual/memory.texi (Freeing after Malloc): Remove cfree. [15:46] can't find the vwrite change ... [15:58] 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] slangasek: I stand corrected about the inclusion of -proposed. it's possible. but I think we don't want it [16:02] 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] slangasek: sure, but we empy -proposed for the release [16:10] 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] pretty empty? cough ... [16:18] doko: we have graphs of this stuff :-) http://people.canonical.com/~ubuntu-archive/proposed-migration/history.html [16:18] ah, hmm, but that's only for this release [16:19] not quite the proof I was looking for [19:30] 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] 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] Laney: ah, nevermind, got it reproduced