| Unit193 | 'Start in 12 hours' Geez, who uploaded KDE again? Thanks for the geoip-database sync. | 00:29 |
|---|---|---|
| valorie | Unit193: KDE is the community, LOL | 01:35 |
| valorie | what was re-uploaded? | 01:35 |
| 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. | 03:52 |
| === Guest52925 is now known as RAOF | ||
| doko | xnox: how much do you care about gcc-arm-linux-androideabi ? | 10:10 |
| doko | hmm, and we have u-boot-linaro depending on gcc-4.7 | 10:11 |
| 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:13 |
| 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:18 |
| ubottu | Launchpad bug 1717229 in android (Ubuntu) "RM: obsolete product" [High,Triaged] | 10:18 |
| doko | do we know about u-boot-linaro? | 10:19 |
| 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:23 |
| 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:24 |
| xnox | opened RM bug for u-boot-linaro | 10:29 |
| xnox | https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/1717232 | 10:29 |
| ubottu | Launchpad bug 1717232 in u-boot-linaro (Ubuntu) "RM: duplicate package" [High,Triaged] | 10:29 |
| 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:33 |
| 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:37 |
| xnox | doko, i think that reverse-depends is simply confused. | 10:42 |
| xnox | hm | 10:44 |
| ppisati | xnox: uhm, as far as i know, we don't use u-boot-linaro anywhere | 10:44 |
| 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:45 |
| 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:54 |
| juliank | um, apt-daily-upgrade.service too | 10:55 |
| juliank | A Before=B essentially means that A is stopped after B | 10:56 |
| 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:58 |
| juliank | for xenial / zesty | 10:59 |
| 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:01 |
| rbalint | juliank: why do you believe that ordering is needed? | 11:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| rbalint | juliank: there is no case when both can upgrade, thus there is no case for taking over | 11:17 |
| 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:18 |
| 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:19 |
| rbalint | juliank: https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade#L1535 | 11:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| juliank | I should push guillem about the whole frontend lock to get any remaining lock race conditions fixed. | 11:24 |
| 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:26 |
| rbalint | juliank:yes, it will redownload | 11:27 |
| 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:29 | |
| 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:30 |
| rbalint | juliank: by default InstallOnShutdown is false thus the default apt service works as expected with either clean or autoclean | 11:32 |
| juliank | true, and they are off by default too. it was mostly just a funny remark | 11:33 |
| === JanC is now known as Guest66311 | ||
| === JanC_ is now known as JanC | ||
| doko | slangasek: your libhybris upload ftbfs | 15:32 |
| 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:33 |
| doko | can't find the vwrite change ... | 15:46 |
| 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:58 |
| doko | slangasek: I stand corrected about the inclusion of -proposed. it's possible. but I think we don't want it | 15:59 |
| 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:02 |
| doko | slangasek: sure, but we empy -proposed for the release | 16:03 |
| 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:10 |
| doko | pretty empty? cough ... | 16:11 |
| 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:18 |
| cjwatson | not quite the proof I was looking for | 16:19 |
| 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:30 |
| 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:31 |
| pitti | Laney: ah, nevermind, got it reproduced | 19:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!