=== salem_ is now known as _salem [07:06] tsimonq2: thanks! [07:06] Good morning [09:30] Mirv: can you reproduce this in Debian too? I would however suspect a binutils change ... [11:24] sil2100: hi! did you find anytime yesterday to look at the ubuntu budgie LP build issue? TIA === hikiko is now known as hikiko|ln === _salem is now known as salem_ [11:45] fossfreedom_: hey! Sadly I got swarmed with post-holiday stuff yesterday, but I'm looking into this nowish [11:46] sil2100: no worries - same here. cheers. [11:47] 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] $ retry-autopkgtest-regressions -s xenial --state RUNNING [11:51] and see "retry-autopkgtest-regressions --help" how to actually send them [11:51] sil2100: ^ [11:52] armhf is having a sad time as well [11:52] I'm trying to sort it out but slow going [11:52] in lp:ubuntu-archive-tools; this is also on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests [11:52] might or might not just be trusty [11:56] pitti: thanks \o/ [11:56] * sil2100 bookmarks the wobpage [11:56] sil2100: but please ask Laney to check the logs first why the requests disappeared; that's not really expected [12:08] pitti: sil2100: Can't find it immediately, busy trying to understand this "container not running" thing, sorry [12:09] ginggs: fyi, freemat ftbfs with LLVM 3.9 (debian-science) [12:11] 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] ginggs: I only wanted it demoted, which is done now === marcusto_ is now known as marcustomlinson [12:15] doko: sorry what demoted? i do not understand [12:17] ginggs: llvm-3.8 demoted (main -> universe) [12:17] doko: ah, got it now === hikiko|ln is now known as hikiko [12:49] sil2100: hi [12:50] sil2100: yeah but it seems you got answers already :) [12:50] sil2100: sorry for the delay, right when you pinged me I started driving my car to yearly service [12:50] feels like: -24'C, nice weather [12:56] 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] rbasak: https://bugs.launchpad.net/ubuntu/+source/parallax/+bug/1653959 [12:58] Launchpad bug 1653959 in parallax (Ubuntu) "[MIR] parallax, dependency of crmsh" [Undecided,Incomplete] [12:58] 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] Mirv: thanks for checking [13:04] doko: noted, thanks. === marcusto_ is now known as marcustomlinson [14:26] 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] main is now down to one llvm version ... instead of three [14:52] sruli: alias apt-upgrade="apt upgrade && foo" ? [14:53] dobey: thanks, didnt think of that, but i need it to work from gui update-manager [14:54] why? what are you trying to accomplish exactly? [14:55] what exactly did you try for apt post success hooks? those sound like the right tool for the job [14:56] 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] 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] ah, you probably can't do that in an apt hook, I bet it's not re-entrant in the right way [14:58] after apt already succeeded in installing the updates, seems like way too late to do that [14:59] seems like you'd want to check that *before* the download/install started [15:01] 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] that will run immediately after 'apt update', thus generally before download/install [15:02] 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] if you put the ones you don't want to install on hold, then all the rest should happen naturally [15:03] also, APT-get::Update::Post-Invoke-Success isn't a thing [15:04] 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] 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] 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] APT::Update::Post-Invoke-Success definitely should be [15:08] and it is here [15:08] 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] I'd suggest starting by seeing whether that happens from update-manager as well [15:09] if so, then that means it must be a problem with your hook rather than with the hook system in general [15:10] 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] time stamp does work, [15:12] 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] i tested the dpkg post invoke it ran after every package, will try again, post-invoke-success or just post-invoke? [15:16] APT::Update::Post-Invoke-Success -> after apt update, DPkg::Post-Invoke -> after every dpkg invocation [15:17] 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] i am not trying to call that directly from post invoke, i am trying to call an external script [15:20] sure, just a warning [15:21] 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] which is usually not difficult, just requires a little thought [15:21] something is wrong with hooks, in 15update-stamp i copied the line to touch another file, it doesnt touch that file [15:22] if this were on my system this would be where I'd break out strace [15:24] 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] its exactly same line but touches different file [15:26] works fine for me [15:26] $ sudo apt update [15:27] $ ls -l /var/lib/apt/periodic/ | head [15:27] total 0 [15:27] -rw-r--r-- 1 root root 0 Jan 4 15:26 1234 [15:27] update-manager gui is what i am testing [15:27] like I say I don't think it does an apt update [15:27] but rather relies on apt's cron jobs to do that from time to time [15:28] but it does update the timestamp on /var/lib/apt/periodic/update-success-time [15:29] ok, I tried update-manager and it apparently did kick off an update, and /var/lib/apt/periodic/1234 was touched [15:29] I've helped you all I can, need to go and do some other things now, sorry [15:30] how do i do an strace? [15:30] best read its documentation [15:31] willdo, thanks for your help [15:31] (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] 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] you don't need to reboot to apply changes to apt configuration files [15:42] perhaps you didn't check for other apt-related processes in ps [15:42] well i just tried a million different configs, nothing kicked of the post invoke until a made a reboot! [15:42] ok, glad that i got that working, [15:42] 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] possibly [15:43] (and by apt, I mean anything that uses the apt libraries) [15:43] 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] there isn't a way to do a post-invoke for upgrade, no [15:44] 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] I'd probably use a cron job or systemd service or similar rather than putting a script in the background, though [15:45] 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] I gave a design for your kernel use case earlier that wouldn't require that [15:46] (and if apt (or dpkg) isn't involved then /var/lib/dpkg/lock shouldn't matter) [15:49] 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] if I were you I would have your script maintain a local apt repository [15:51] 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] and 2. doesn't require /var/lib/dpkg/lock to be released, so you can do that stuff any time [15:54] 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] 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] 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] 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] 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] 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] 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] ... possible strategies) [16:02] the gain of this is that it's more reliable with respect to apt locking etc. [16:03] 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] anyway you obviously don't have to take my advice, but you asked, so ... [16:04] 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] it might actually end up being less code [16:04] (since apt would deal with acquiring stuff straight from that directory) [16:05] 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] 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] 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] I don't understand why it would install the latest kernel [16:08] if there is no hold on it and its doing a update it will install latest [16:08] if you have a local apt repository then you'd pin that repository to be preferred over versions in the archive [16:08] 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] hm, might be slightly fiddly with multiple versions though [16:10] really out of time to think about this [16:11] 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] 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] many thanks for your time and advice [16:12] 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] sruli: why do you want to postpone important security updates? [16:13] 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] 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] 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] fossfreedom: or better said, too narrowly I guess ;) [16:15] sruli: what do you do about /proc/uptime? [16:16] I'm not sure what booting has to do with installed kernels [16:17] boot time, I mean [16:18] 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] 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] 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] sounds like you want two grub installations, one chaining to the other [16:20] cjwatson: correct, actually impossible to tell, without the luks key they can play all they want in boot [16:22] (you could also just encrypt /boot if you don't mind having to type in your LUKS passphrase at every boot) [16:23] that's what I was thinking too... [16:23] 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] 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] basically you want your first stage grub (or other bootloader) to be on something else than /boot [16:25] 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] theat the way to go i guess... need some time to figure it out.. unless you can point me to a guide [16:28] don't have a guide, but I'd probably do something based on grub-mkstandalone (or maybe grub-mkrescue) [16:29] and i will be able to hide the grub menu and default boot windows? [16:30] certainly possible, a matter of crafting an appropriate grub.cfg [16:31] thanks, will be back when i am ready to try it.. really appreciate the help === JanC is now known as Guest75542 === JanC_ is now known as JanC [16:47] fossfreedom: ...actually scratch that, the error seems to be somewhere else, I continue looking [16:47] 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] sil2100: this really is a roller-coaster! cheers for the feedback. [16:51] 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:51] bug 1653529 in qtwebkit-opensource-src (Ubuntu) "qtwebkit 5.7.1 fails to build on armhf" [Undecided,Confirmed] https://launchpad.net/bugs/1653529 [16:54] 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] 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] 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] 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] 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] wait - you mean the debian package itself that you run the ./update on to regenerate it? [17:22] Does anybody know why is the sponsorship tracker "Last updated at: Wed, 21 Dec 2016 16:40:29 -0000"? [17:23] That sounds familiar. IIRC, the pending-sru report was stuck at a similar time. [17:23] If it has the same root cause, someone with access to snakefruit can kill things/clear locks. [17:23] (assuming the sponsorship tracker updates from snakefruit) [17:23] the sponsorship tracker isn't on snakefruit is it? [17:23] what's the URL? [17:23] It's on a different host [17:23] Oh [17:23] The URL is http://reqorts.qa.ubuntu.com/reports/sponsoring/ [17:24] yeah, that's cranberry [17:24] bdmurray: ^- [17:24] (IIRC) [17:24] It's cranberry, yes. [17:25] The files are owned by dholbach... hope it wasn't run out of his crontab or anything like that :) [17:27] That's be ironic :) [17:27] THat'd [17:27] I'll have a look [17:40] mitya57, cjwatson, rbasak, Laney: it looks like it was run by him, I'll move it over to ubuntureports this week. [17:40] Thanks! [17:42] Ta === alan_g is now known as alan_g|EOD [18:47] sil2100: hi - I've looked at ubuntu-meta and ubuntu-gnome-meta and they don't have a "live" mapping. [18:48] I'm a little confused - I can't see other community flavours with a "live" name metapackage [18:51] 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] 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] (though "APT::Update::Post-Invoke" also exists) [19:11] apt-pkg/deb/dpkgpm.cc: if (RunScripts("DPkg::Post-Invoke") == false) [19:11] apt-pkg/update.cc: RunScripts("APT::Update::Post-Invoke-Success"); [19:11] apt-pkg/update.cc: RunScripts("APT::Update::Post-Invoke"); [19:11] i see so there is no post-invoke-success for dpkg, interesting, google is full it.. [19:13] The first hit I find for (quoted) "Dpkg::Post-Invoke-Success" is a stackexchange post explaining that it doesn't exist. [19:13] 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] 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] ok, i see now that stackexchange post, will have to use post-invoke, [19:16] 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] thanks [19:49] fossfreedom: might be unrelated, but I guess I might be onto something - need to poke someone, will continue digging tomorrow [19:50] sil2100: ok - cheers for all your time today. much appreciated. [20:25] mitya57: The sponsors page has been updated and cronned [20:25] bdmurray, thanks a lot! [20:27] bdmurray, maybe you can help me one more time today? I need someone to look at owncloud-client in Yakkety SRU queue… [20:32] 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] bdmurray, the previous upload (2.2.2+dfsg-1ubuntu0.1), already in proposed, references that bug properly. [20:34] But if you want me to put the proper reference to this upload too, please reject it and I'll reupload. [20:50] mitya57: please do reference the bug again, I've rejected the existing upload [20:53] bdmurray, re-uploaded === salem_ is now known as _salem [21:17] bdmurray, thanks a lot!