[07:06] <pitti> tsimonq2: thanks!
[07:06] <pitti> Good morning
[09:30] <doko> Mirv: can you reproduce this in Debian too? I would however suspect a binutils change ...
[11:24] <fossfreedom_> sil2100: hi! did you find anytime yesterday to look at the ubuntu budgie LP build issue?  TIA
[11:45] <sil2100> fossfreedom_: hey! Sadly I got swarmed with post-holiday stuff yesterday, but I'm looking into this nowish
[11:46] <fossfreedom_> sil2100: no worries - same here.  cheers.
[11:47] <sil2100> Mirv: hey! Do you know the autopkgtest infra enough to maybe somehow kick the libnih armhf test from http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#dbus ? Since it seems to be 'Test in progress' but not on any queue
[11:51] <pitti> $ retry-autopkgtest-regressions -s xenial --state RUNNING
[11:51] <pitti> and see "retry-autopkgtest-regressions --help" how to actually send them
[11:51] <pitti> sil2100: ^
[11:52] <Laney> armhf is having a sad time as well
[11:52] <Laney> I'm trying to sort it out but slow going
[11:52] <pitti> in lp:ubuntu-archive-tools; this is also on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests
[11:52] <Laney> might or might not just be trusty
[11:56] <sil2100> pitti: thanks \o/
[11:56]  * sil2100 bookmarks the wobpage
[11:56] <pitti> sil2100: but please ask Laney to check the logs first why the requests disappeared; that's not really expected
[12:08] <Laney> pitti: sil2100: Can't find it immediately, busy trying to understand this "container not running" thing, sorry
[12:09] <doko> ginggs: fyi, freemat ftbfs with LLVM 3.9 (debian-science)
[12:11] <ginggs> doko: thanks, will take a look. i checked julia yesterday and it also fails. are you planning to remove 3.8 for zesty? or are you only changing the default to 3.9?
[12:12] <doko> ginggs: I only wanted it demoted, which is done now
[12:15] <ginggs> doko: sorry what demoted? i do not understand
[12:17] <doko> ginggs: llvm-3.8 demoted (main -> universe)
[12:17] <ginggs> doko: ah, got it now
[12:49] <Mirv> sil2100: hi
[12:50] <Mirv> sil2100: yeah but it seems you got answers already :)
[12:50] <Mirv> sil2100: sorry for the delay, right when you pinged me I started driving my car to yearly service
[12:50] <Mirv> feels like: -24'C, nice weather
[12:56] <Mirv> doko: I've been experimenting a bit, and now I got the same problem with forced binutils 20161212: https://launchpadlibrarian.net/301180375/buildlog_ubuntu-zesty-armhf.qtwebkit-opensource-src_5.7.1+dfsg-1build1~1_BUILDING.txt.gz (fake bumped version number). I don't have Debian armhf available for testing. I'm still building a similarly older gcc-6 to test next.
[12:58] <doko> rbasak: https://bugs.launchpad.net/ubuntu/+source/parallax/+bug/1653959
[12:58] <Mirv> that should be roughly the same binutils that was in use when Debian's package was built (https://buildd.debian.org/status/fetch.php?pkg=qtwebkit-opensource-src&arch=armhf&ver=5.7.1%2Bdfsg-1&stamp=1481858819)
[12:59] <doko> Mirv: thanks for checking
[13:04] <rbasak> doko: noted, thanks.
[14:26] <sruli> i want to run a script each time apt finishes installing updates, i tried apt post success hooks but its not working, dpkg post success runs the script after each package is installed and i dont want that, i only want it to run when all is finished, how can i go about this?
[14:43] <doko> main is now down to one llvm version ... instead of three
[14:52] <dobey> sruli: alias apt-upgrade="apt upgrade && foo" ?
[14:53] <sruli> dobey: thanks, didnt think of that, but i need it to work from gui update-manager
[14:54] <dobey> why? what are you trying to accomplish exactly?
[14:55] <cjwatson> what exactly did you try for apt post success hooks?  those sound like the right tool for the job
[14:56] <cjwatson> perhaps you just got the syntax slightly wrong or something; it would help to know a little more than "it's not working"
[14:56] <sruli> dobey: i am holding back kernel updates for a few weeks after release, wrote a bash script to check date of kernel and install if > x days, i want it to run at the same time of regular updates
[14:58] <cjwatson> ah, you probably can't do that in an apt hook, I bet it's not re-entrant in the right way
[14:58] <dobey> after apt already succeeded in installing the updates, seems like way too late to do that
[14:59] <dobey> seems like you'd want to check that *before* the download/install started
[15:01] <cjwatson> turn the problem on its head: use APT::Update::Post-Invoke-Success to put all kernel packages on hold except for those that it's acceptable to install
[15:01] <cjwatson> that will run immediately after 'apt update', thus generally before download/install
[15:02] <sruli> i am calling an external script, what difference does it make it apt finished installing the updates? my lines in "60aptupdate" APT::Update::Post-Invoke-Success {"path/to/script";}; and APT-get::Update::Post-Invoke-Success {"path/to/script";};
[15:03] <cjwatson> if you put the ones you don't want to install on hold, then all the rest should happen naturally
[15:03] <cjwatson> also, APT-get::Update::Post-Invoke-Success isn't a thing
[15:04] <sruli> i can get by the issue of when it calles it by telling the script to call another one and second one will wait for /va/lib/dpkg/lock to free up.. point is the apt hook is not called when using the gui
[15:04] <sruli> cjwatson: ther are some other scripts i also need to run after install, question is why is the hook not called when running gui update-manager
[15:07] <sruli> actually its also not called when running from command line, i just noticed the hook made no difference, i made a wrapper before for apt-get and have a copy of it in /usr/local/bin, when that file is there then apt update from command line triggers it, however the hooks in /etc/apt/apt.conf.d/ are not being triggered
[15:07] <cjwatson> APT::Update::Post-Invoke-Success definitely should be
[15:08] <cjwatson> and it is here
[15:08] <cjwatson> for example if you have update-notifier-common installed, then you should notice that the timestamp of /var/lib/apt/periodic/update-success-stamp is updated every time you do an apt update; that's handled by /etc/apt/apt.conf.d/15update-stamp
[15:09] <cjwatson> I'd suggest starting by seeing whether that happens from update-manager as well
[15:09] <cjwatson> if so, then that means it must be a problem with your hook rather than with the hook system in general
[15:10] <cjwatson> it's been a while, but I *think* that update-manager possibly doesn't generally do an apt update itself, but just relies on the apt cron jobs to do that
[15:11] <sruli> time stamp does work,
[15:12] <cjwatson> as far as I know the only way to install a hook that runs after install is to use DPkg::Post-Invoke - that's not "after each package is installed", but rather after each dpkg invocation (which may operate on several packages at once)
[15:13] <sruli> i tested the dpkg post invoke it ran after every package, will try again, post-invoke-success or just post-invoke?
[15:16] <cjwatson> APT::Update::Post-Invoke-Success -> after apt update, DPkg::Post-Invoke -> after every dpkg invocation
[15:17] <cjwatson> you will definitely not be able to use apt-get install from DPkg::Post-Invoke, so don't bother trying things like that
[15:19] <sruli> i am not trying to call that directly from post invoke, i am trying to call an external script
[15:20] <cjwatson> sure, just a warning
[15:21] <cjwatson> in general you just need to write things in a way that will cope with being called multiple times from a single apt upgrade run, though
[15:21] <cjwatson> which is usually not difficult, just requires a little thought
[15:21] <sruli> something is wrong with hooks, in 15update-stamp i copied the line to touch another file, it doesnt touch that file
[15:22] <cjwatson> if this were on my system this would be where I'd break out strace
[15:24] <sruli> i dont know how to use that.. try adding to your 15update-timestamp "APT::Update::Post-Invoke-Success {"touch /var/lib/apt/periodic/1234 2>/dev/null || true";};
[15:24] <sruli> its exactly same line but touches different file
[15:26] <cjwatson> works fine for me
[15:26] <cjwatson> $ sudo apt update
[15:27] <cjwatson> $ ls -l /var/lib/apt/periodic/ | head
[15:27] <cjwatson> total 0
[15:27] <cjwatson> -rw-r--r-- 1 root root 0 Jan  4 15:26 1234
[15:27] <sruli> update-manager gui is what i am testing
[15:27] <cjwatson> like I say I don't think it does an apt update
[15:27] <cjwatson> but rather relies on apt's cron jobs to do that from time to time
[15:28] <sruli> but it does update the timestamp on /var/lib/apt/periodic/update-success-time
[15:29] <cjwatson> ok, I tried update-manager and it apparently did kick off an update, and /var/lib/apt/periodic/1234 was touched
[15:29] <cjwatson> I've helped you all I can, need to go and do some other things now, sorry
[15:30] <sruli> how do i do an strace?
[15:30] <cjwatson> best read its documentation
[15:31] <sruli> willdo, thanks for your help
[15:31] <cjwatson> (it will produce a lot of output - you'll want to arrange for that to go to a file, and then you can search for interesting things in that file)
[15:40] <sruli> cjwatson: didnt run a strace but rebooted and tried again, it did kick it of, i checked with ps before reboot and update-manager was not running! how do i apply changes to apt conf files without reboot?
[15:41] <cjwatson> you don't need to reboot to apply changes to apt configuration files
[15:42] <cjwatson> perhaps you didn't check for other apt-related processes in ps
[15:42] <sruli> well i just tried a million different configs, nothing kicked of the post invoke until a made a reboot!
[15:42] <sruli> ok, glad that i got that working,
[15:42] <cjwatson> apt reads its configuration every time it starts.  the only way a reboot could possibly be relevant is if there was some apt-related process running that you missed.
[15:42] <sruli> possibly
[15:43] <cjwatson> (and by apt, I mean anything that uses the apt libraries)
[15:43] <sruli> question is now if there is a way to do a post-invoke for upgrade? else i will need to call a "script &" that script will need to wait for the lock on /var/lib/dpkg/lock to be freed
[15:44] <cjwatson> there isn't a way to do a post-invoke for upgrade, no
[15:44] <sruli> also apt update from command line executes the script once, from gui it calls it 3 times, so will have to touch a tmp file when called and first thing in script is if tmp file exists = exit 0
[15:45] <cjwatson> I'd probably use a cron job or systemd service or similar rather than putting a script in the background, though
[15:45] <cjwatson> and I'm still confused about why you'd need to call apt from a hypothetical post-upgrade hook; that sounds like a symptom of bad design
[15:46] <cjwatson> I gave a design for your kernel use case earlier that wouldn't require that
[15:46] <cjwatson> (and if apt (or dpkg) isn't involved then /var/lib/dpkg/lock shouldn't matter)
[15:49] <sruli> well few reasons, 1. usually after a month the kernel is no longer in cache so cant install it, (my script downloads kernel as soon as its released but keeps in in different dir) 2. i run some other scripts to change m/c/a times on /boot files, (dont want anyone to be able to see when was last time i booted the machine) i need this script to run every time a update changes a file in /boot
[15:50] <cjwatson> if I were you I would have your script maintain a local apt repository
[15:51] <cjwatson> that way it'll still be available in the apt cache and you can use the simpler hold-all-kernels-except-if-approved design above
[15:51] <cjwatson> and 2. doesn't require /var/lib/dpkg/lock to be released, so you can do that stuff any time
[15:54] <sruli> 1. i looke dhard and could not find a way to tell apt/dpkg to install a package based on mtime, and i tried but was not successfull in holding a specific kerne, had to put "linux-image-generic" on hold "linux-image-4.4.0-48-generic" did not hold
[15:54] <sruli> 2. but i need it to change the mtimes after dpkg finishes, if it runs before then dpkg might update some files in boot after...
[15:55] <cjwatson> 1. like I say, maintain a local apt repository, put everything on hold from APT::Update::Post-Invoke-Success except the ones that you determine are old enough
[15:57] <cjwatson> 2. DPkg::Post-Invoke should be sufficient for that - apt holds the lock basically to avoid confusion, but DPkg::Post-Invoke itself is reliably run after dpkg finishes
[15:58] <sruli> how do i determine if its old enough without downloading the file to check the mtime, if i already need to download it, why keep a local repo of many GB's
[16:02] <sruli> also what is the gain of your way? my script downloads, keeps a dir full of them, if it determines mtime is ripe, it moves it to /var/cache/apt/archives and executes "apt install linux-image-x.x.x-x-generic" so it goes through the normal apt install proccess
[16:02] <cjwatson> you can either keep a little database of package names/versions to mtimes, or do an HTTP HEAD request to get the mtime; and a local repository doesn't *necessarily* require actually having all the files locally, you could have just the index information locally and do the download when your APT::Update::Post-Invoke-Success hook decides to unhold a kernel package (for example; there are other ...
[16:02] <cjwatson> ... possible strategies)
[16:02] <cjwatson> the gain of this is that it's more reliable with respect to apt locking etc.
[16:03] <cjwatson> you wouldn't have to mess about with trying to work out when apt isn't running, potentially colliding with other things; and it would mean the package would be straightforwardly visible in update-manager, and be applied as part of the normal upgrade run
[16:03] <cjwatson> anyway you obviously don't have to take my advice, but you asked, so ...
[16:04] <cjwatson> also if your script is already keeping a directory full of them then I don't see why running a bit of extra code to turn that directory into an apt repository is a problem
[16:04] <cjwatson> it might actually end up being less code
[16:04] <cjwatson> (since apt would deal with acquiring stuff straight from that directory)
[16:05] <sruli> i did not find a way to check mtime with http header, also if i remove the hold like you suggest it will install the lastest kernel, unless i misunderstood part of your instruction
[16:06] <sruli> regarding taking your advice.. sure i want and thanks for your time, i want to do things the best way possible... but i have to understand properly.. and it has to achive my goal
[16:07] <cjwatson> the mtime is in the Last-Modified header in an HTTP HEAD request, although if you already have the files locally then using that is certainly easier
[16:07] <cjwatson> I don't understand why it would install the latest kernel
[16:08] <sruli> if there is no hold on it and its doing a update it will install latest
[16:08] <cjwatson> if you have a local apt repository then you'd pin that repository to be preferred over versions in the archive
[16:08] <cjwatson> that's one good reason to have a local repository, in fact; if properly configured then it makes it harder to commit accidents if using apt by hand
[16:09] <cjwatson> hm, might be slightly fiddly with multiple versions though
[16:10] <cjwatson> really out of time to think about this
[16:11] <cjwatson> might be necessary to maintain the repository out of band with a cron job, so it would basically only "publish" the packages that are old enough in its Packages index file
[16:11] <sruli> there are multiple other problems, i will need to download it to the repo to check the date, if its in the repo, it will get installed.. for the moment i will have to go with what i have and at a later stage think of resoing it
[16:11] <sruli> many thanks for your time and advice
[16:12] <cjwatson> then you don't need anything in APT::Update::Post-Invoke-Success, you'd just have a preferences file that causes all kernel packages from the primary archive to be ignored
[16:12] <JanC> sruli: why do you want to postpone important security updates?
[16:13] <sil2100> fossfreedom: I think I see what's wrong, I think I reviewed your livecd-rootfs branch too broadly and we miss some changes there - let me add what's needed and try re-running (once it migrates)
[16:14] <cjwatson> anyway in general the way I would recommend thinking about this kind of thing is that you're basically trying to maintain a curated channel for updates, and the best way to do that is generally to try to make things look as much like the existing channels (e.g. xenial-updates) as possible
[16:14] <sruli> JanC: i do not want anyone to be able to see from my /boot partition when i last booted it so have to postpone kernel few weeks, if you know how i can encrypt boot and at sametime have hidden grub with regular boot going straight to windows you will be my hero
[16:14] <sil2100> fossfreedom: or better said, too narrowly I guess ;)
[16:15] <cjwatson> sruli: what do you do about /proc/uptime?
[16:16] <JanC> I'm not sure what booting has to do with installed kernels
[16:17] <JanC> boot time, I mean
[16:18] <sruli> cjwatson: you cant get that from boot partition, can you? rest of system is luks, i am not worried about when i am using it, i dont want colleagues to try to check when i am not around
[16:19] <cjwatson> ok, but you're not likely to make your system more secure by holding back upgrades just so that it's hard for people to tell how recent it is
[16:19] <sruli> JanC: if a kernel is realeased 2 days ago and its in my boot partition, u know i must have used it in the last 2 days, i want it to be a month since i last used it
[16:19] <cjwatson> sounds like you want two grub installations, one chaining to the other
[16:20] <sruli> cjwatson: correct, actually impossible to tell, without the luks key they can play all they want in boot
[16:22] <cjwatson> (you could also just encrypt /boot if you don't mind having to type in your LUKS passphrase at every boot)
[16:23] <JanC> that's what I was thinking too...
[16:23] <sruli> cjwatson: problem with that is i need windows to be able to boot without pass, my work even demands that it always boots striaght into windows so had to hide the grub menu
[16:24] <sruli> cjwatson: chaningin 2 grubs is one of the ideas that came up on #ubuntu , had a few ideas on how to have encrypted boot with default booting straight into windows, couldnt find any guides.. i guess i will need a week to fugire it out and test it properly.. its on my list
[16:25] <JanC> basically you want your first stage grub (or other bootloader) to be on something else than /boot
[16:25] <sruli> with regards to grub password, i was thinking to use keyfile on usb stick, it usb is connected it shows grub and unlocks else boot windows
[16:27] <sruli> theat the way to go i guess... need some time to figure it out.. unless you can point me to a guide
[16:28] <cjwatson> don't have a guide, but I'd probably do something based on grub-mkstandalone (or maybe grub-mkrescue)
[16:29] <sruli> and i will be able to hide the grub menu and default boot windows?
[16:30] <cjwatson> certainly possible, a matter of crafting an appropriate grub.cfg
[16:31] <sruli> thanks, will be back when i am ready to try it.. really appreciate the help
[16:47] <sil2100> fossfreedom: ...actually scratch that, the error seems to be somewhere else, I continue looking
[16:47] <Mirv> doko: still a problem with forced gcc 6.2.1-5ubuntu1, so maybe it's something Ubuntu specific. https://launchpadlibrarian.net/301204319/buildlog_ubuntu-zesty-armhf.qtwebkit-opensource-src_5.7.1+dfsg-1build1~1_BUILDING.txt.gz
[16:50] <fossfreedom_> sil2100: this really is a roller-coaster!  cheers for the feedback.
[16:51] <Mirv> updated bug #1653529 with how the testing was done and a link to Debian log of the same source that succeeded on Dec 16th
[16:54] <sil2100> fossfreedom_: I'm wondering if the problem might be that your budgie seeds are missing the -live metapackage, e.g. ubuntu-budgie-live
[16:54] <mitya57> Can some SRU team member please look at owncloud-client in Yakkety queue? It's and important fix and waits since 2016-12-19…
[16:54] <sil2100> fossfreedom_: I mean, the seeds do have live configured, but the ubuntu-budgie-meta package doesn't define it (and doesn't link to it in the metapackage-map)
[16:55] <sil2100> fossfreedom_: sadly live-build is very vague in giving any clues on failures quite frequently, but that would be my first guess here
[16:57] <fossfreedom_> sil2100: oh! I'm looking here but not sure what needs updating - http://bazaar.launchpad.net/~ubuntubudgie-dev/ubuntu-seeds/ubuntu-budgie.zesty/files
[16:58] <fossfreedom_> wait - you mean the debian package itself that you run the ./update on to regenerate it?
[17:22] <mitya57> Does anybody know why is the sponsorship tracker "Last updated at: Wed, 21 Dec 2016 16:40:29 -0000"?
[17:23] <rbasak> That sounds familiar. IIRC, the pending-sru report was stuck at a similar time.
[17:23] <rbasak> If it has the same root cause, someone with access to snakefruit can kill things/clear locks.
[17:23] <rbasak> (assuming the sponsorship tracker updates from snakefruit)
[17:23] <cjwatson> the sponsorship tracker isn't on snakefruit is it?
[17:23] <cjwatson> what's the URL?
[17:23] <Laney> It's on a different host
[17:23] <rbasak> Oh
[17:23] <mitya57> The URL is http://reqorts.qa.ubuntu.com/reports/sponsoring/
[17:24] <cjwatson> yeah, that's cranberry
[17:24] <cjwatson> bdmurray: ^-
[17:24] <cjwatson> (IIRC)
[17:24] <mitya57> It's cranberry, yes.
[17:25] <Laney> The files are owned by dholbach... hope it wasn't run out of his crontab or anything like that :)
[17:27] <rbasak> That's be ironic :)
[17:27] <rbasak> THat'd
[17:27] <bdmurray> I'll have a look
[17:40] <bdmurray> mitya57, cjwatson, rbasak, Laney: it looks like it was run by him, I'll move it over to ubuntureports this week.
[17:40] <mitya57> Thanks!
[17:42] <Laney> Ta
[18:47] <fossfreedom> sil2100: hi - I've looked at ubuntu-meta and ubuntu-gnome-meta and they don't have a "live" mapping.
[18:48] <fossfreedom> I'm a little confused - I can't see other community flavours with a "live" name metapackage
[18:51] <sruli> cjwatson: you around? i got my script working fine, but change the hook to dpkg it now only works with post-invoke, not with post-invoke-success, what can that be?
[19:10] <cjwatson> sruli: Because you can't make up configuration key names and expect them to work - you have to use the specific ones that apt cares about.  And, for whatever reason, the key names it has defined in this area happen to be spelled "APT::Update::Post-Invoke-Success" and "DPkg::Post-Invoke".
[19:10] <cjwatson> (though "APT::Update::Post-Invoke" also exists)
[19:11] <cjwatson> apt-pkg/deb/dpkgpm.cc:   if (RunScripts("DPkg::Post-Invoke") == false)
[19:11] <cjwatson> apt-pkg/update.cc:       RunScripts("APT::Update::Post-Invoke-Success");
[19:11] <cjwatson> apt-pkg/update.cc:      RunScripts("APT::Update::Post-Invoke");
[19:11] <sruli> i see so there is no post-invoke-success for dpkg, interesting, google is full it..
[19:13] <cjwatson> The first hit I find for (quoted) "Dpkg::Post-Invoke-Success" is a stackexchange post explaining that it doesn't exist.
[19:13] <cjwatson> As far as I can tell somebody made it up or typoed it in some other stackexchange post and didn't check whether it really existed.
[19:14] <cjwatson> I get three hits total for it before Google starts omitting "very similar" results, and all three hits are basically copies of the same post.
[19:15] <sruli> ok, i see now that stackexchange post, will have to use post-invoke,
[19:16] <cjwatson> I mean, maybe it would be useful if it did exist, but you'd have to file a bug report against apt asking for it.
[19:17] <sruli> thanks
[19:49] <sil2100> fossfreedom: might be unrelated, but I guess I might be onto something - need to poke someone, will continue digging tomorrow
[19:50] <fossfreedom> sil2100: ok - cheers for all your time today.  much appreciated.
[20:25] <bdmurray> mitya57: The sponsors page has been updated and cronned
[20:25] <mitya57> bdmurray, thanks a lot!
[20:27] <mitya57> bdmurray, maybe you can help me one more time today? I need someone to look at owncloud-client in Yakkety SRU queue…
[20:32] <bdmurray> mitya57: Can you properly reference the Launchpad bug in the changelog.  Otherwise the pending SRU report won't show an LP bug and the verification process won't go so well.
[20:33] <mitya57> bdmurray, the previous upload (2.2.2+dfsg-1ubuntu0.1), already in proposed, references that bug properly.
[20:34] <mitya57> But if you want me to put the proper reference to this upload too, please reject it and I'll reupload.
[20:50] <bdmurray> mitya57: please do reference the bug again, I've rejected the existing upload
[20:53] <mitya57> bdmurray, re-uploaded
[21:17] <mitya57> bdmurray, thanks a lot!