[13:24] <DammitJim> do you guys know why I'm getting this message? WARNING: Security updates for your current Hardware Enablement Stack
[13:24] <DammitJim> ended on 2016-08-04
[13:24] <DammitJim> but when I run hwe-support-status --verbose
[13:25] <DammitJim> I get: Your Hardware Enablement Stack (HWE) is supported until April 2019.
[13:25] <DammitJim> did I do something wrong when I upgraded the hwe?
[14:26] <dpb1> DammitJim: you get that on login?
[14:26] <dpb1> (in motd)
[14:26] <DammitJim> yes
[14:28] <dpb1> `lsb-release -d` shows?
[14:29] <DammitJim> ack, I don't have that package installed
[14:29] <DammitJim> do I really need to install it?
[14:29] <dpb1> err
[14:29] <dpb1> lsb_release -d
[14:30] <DammitJim> Description:	Ubuntu 14.04.5 LTS
[14:31] <compdoc> yikes
[14:32] <dpb1> hrm
[14:32] <dpb1> hwe-support-status and the motd snippet are not agreeing here.
[14:32] <dpb1> DammitJim: did you just recently upgrade to the xenial hwe stack?
[14:33] <dpb1> (16.04)
[14:36] <DammitJim> right!
[14:36] <DammitJim> yes, I did it this morning
[14:36] <DammitJim> and I've been updating servers for a month now
[14:42] <DammitJim> and today is the first time that this happens (I've been using scripts)
[15:05] <aadi> join channel #ubuntu
[15:29] <dpb1> DammitJim: good.  this feels like a simple bug in the motd update script
[15:29] <dpb1> "simple"
[15:30] <dpb1> DammitJim: I'm not sure what package installs that, or I would say "file a bug on this package".   perhaps someone else knows
[15:36] <nacc> dpb1: install what?
[15:37] <DammitJim> ok
[15:37] <dpb1> the motd.d that is printing WARNING: Security updates for your current Hardware Enablement Stack ended on 2016-08-04
[15:37] <dpb1> nacc: ^
[15:37] <dpb1> (14.04)
[15:37] <nacc> update-notifier-common: /etc/update-motd.d/95-hwe-eol
[15:37] <nacc> is that it?
[15:38] <nacc> from src:update-notifier
[15:38] <DammitJim> what do I need to run?
[15:40] <nacc> DammitJim: `apport-bug update-notifier-common` i think. Is this desktop or server?
[15:41] <DammitJim> server
[15:44] <nacc> DammitJim: i'm not sure what the bug reporting tool is on server, tbh, you can just file it on launchpad directly (against update-notifier)
[15:45] <DammitJim> ok
[15:46] <nacc> DammitJim: the script that is generating the motd message is: /usr/lib/update-notifier/update-motd-hwe-eol
[15:46] <nacc> DammitJim: if you want to debug it a bit
[15:58] <nacc> DammitJim: actually, hrm
[15:58] <nacc> DammitJim: in my 16.04 lxd, i'm not actually seeing a hwe-support-status command (nor one in xenial's archives)
[15:58] <nacc> DammitJim: can you do a `dpkg -S hwe-support-status` ?
[16:09] <lachokds> hello everyone
[16:10] <lachokds> this might be a bit odd of a question, but is there a way to directly upgrade a server instance from 8.04 to 16.04, that doesn't involve reinstalling?
[16:11] <nacc> lachokds: no, you can't directly do it even when 8.04 was supported
[16:11] <nacc> lachokds: you'd need to do 8.04 -> 10.04 -> 12.04 -> 14.04 -> 16.04
[16:12] <nacc> !eolupgrade | lachokds
[16:12] <nacc> lachokds: but honestly, you're better off reinstalling, I'd say
[16:12] <nacc> lachokds: that's a silly number of EOL upgrades before you even get to the supported state
[16:12] <lachokds> thanks
[16:13] <lachokds> actually yeah, I was trying to upgrade to 10.04 but then my whole system became unbootable
[16:13] <lachokds> after restoring from backups I was wondering what else I could do
[16:14] <nacc> lachokds: how did you upgrade to 10.04? following the above?
[16:14] <lachokds> yeah, I changed the sources.list file to point to old-releases.ubuntu.com and went from there
[16:15] <nacc> lachokds: ah ok
[16:15] <lachokds> I think it might have been that I chose the package maintainer's version for grub
[16:16] <lachokds> do you think I should try once again with the original grub version in the system?
[16:16] <nacc> lachokds: i have no idea. my opinion is you've waiting far too long to do this update. You've been unsupported for years (at least 4 years?), and insecure as well. You might as well reinstall.
[16:17] <genii> You'd be much better off with a clean install to 16.04
[16:19] <lachokds> nacc: I know, I just got the assignment to work on this server. I guess it's gonna be a very interesting conversation :-P
[16:19] <nacc> lachokds: is this a production environment?
[16:19] <lachokds> genii: thanks
[16:21] <lachokds> nacc: seems like so, though I don't really know why it wasn't upgraded before. Anyways, thanks!
[16:21] <nacc> lachokds: that seems even worse, then, yeah ...
[16:22] <dpb1> nacc: seems like it's just trusty
[16:24] <nacc> dpb1: yeah, so i think that could be the problem
[16:24] <nacc> dpb1: something wasn't removed properly
[16:24] <nacc> dpb1: as it shouldn't exist on xenial?
[16:25] <dpb1> nacc: feels very weird to me too
[16:25] <nacc> dpb1: yeah, i'm not sure if that's intentional
[16:25] <nacc> dpb1: and oddly it *does* exist on 17.10
[16:25] <dpb1> wth
[16:25] <lachokds> dpb1: what ?
[16:25] <nacc> lachokds: we're talking about DammitJim's issue from earlier
[16:27] <lachokds> sorry, I wasn't connected
[16:27] <lachokds> my apologies
[16:27] <nacc> lachokds: np
[16:28] <dpb1> lachokds: sorry, multiple conversations going at a time. :)
[16:28] <dpb1> lachokds: I'm impressed you found an 8.04 server out there.  good luck. :)
[16:29] <nacc> s/im/de/ :)
[16:29] <dpb1> nacc: lol
[16:30] <lachokds> nacc: thanks, I guess (?) hehe :)
[16:57] <Ssandy> hello
[17:00] <JPelletier> Hi, my Ubuntu Server is randomly freezing after Grub menu on reboot. Can I find a log somewhere to help me diagnose what happen? Nothing is logged in journalctl
[17:07] <TafThorne> Does it show anything on the screen?
[17:07] <TafThorne> Does hittign the Esc key make it show anything?
[17:07] <TafThorne> Have you tried going down to the Advanced options section ont he menu and booting with an older kernel ?
[17:08] <JPelletier> Black screen, hitting ESC or shift do nothing. I've  tried with ubuntu 16.04.02 LTS (kernel 4.8) - Same issue
[17:24] <DammitJim> nacc... mine is on 14.04
[17:24] <DammitJim> dpkg -S hwe-support-status
[17:24] <DammitJim> update-manager-core: /usr/bin/hwe-support-status
[17:24] <nacc> DammitJim: oh I'm sorry, I misread dpb1's comment (xenial hwe stack can mean two different things)
[17:24] <nacc> DammitJim: in your case, you are on 14.04.5 now?
[17:25] <DammitJim> yes
[17:26] <nacc> DammitJim: afaict, on trusty, the MOTD should match what `hwe-support-status` outputs... I suppose there is a window while the file is being updated ont he first boot
[17:28] <DammitJim> hhmmmm... maybe I should restart again?
[17:29] <DammitJim> exit
[17:30] <nacc> DammitJim: if it's not too much hassle, that would be good to test, or you can just login again (in theory). I'm not sure when motd gets regenned
[17:35] <dpb1> he really restarted
[17:35] <dpb1> :)
[17:44] <ahasenack> nacc: just for kicks, I'm trying another merge: bind9
[17:44] <ahasenack> nacc: something new: http://pastebin.ubuntu.com/24974070/
[17:45] <ahasenack> nacc: the commented pick lines
[17:45] <ahasenack> should I leave them like that and only work on the rest?
[17:48] <ahasenack> they all look like empty commits
[17:48] <nacc> ahasenack: it's referred to in wiki: 2.2.5.4 -- but i forgot to update the later portion at 2.3.2
[17:48] <ahasenack> ah, right
[17:49] <nacc> fixing now
[17:49] <ahasenack> thx
[17:50] <nacc> ahasenack: added 2.3.2.3
[17:50] <ahasenack> o/
[18:00] <nacc> stgraber: just got the update to lxd on artful, now my containers won't start :)
[18:01] <stgraber> nacc: what error are you getting?
[18:01] <nacc> stgraber: http://paste.ubuntu.com/24974162/
[18:01] <nacc> stgraber: it creates it, but it's "STOPPED". Manually starting it works
[18:02] <nacc> stgraber: i don't see a reboot request in /var/run/reboot-required, so I hadn't rebooted yet
[18:03] <Masterphi> Hey guys, I'm getting this WARNING: The following packages cannot be authenticated! libexpat1 libgraphite2-3    should I proceed with the install?
[18:04] <nacc> Masterphi: can you pastebin `apt-cache policy libexpat1 libgraphite2-3` ?
[18:04] <Masterphi> yah, right away
[18:05] <Masterphi> nacc: https://pastebin.com/7i69mf6D
[18:05] <nacc> Masterphi: that's debian not ubuntu
[18:05] <Masterphi> heh, right. This VM isn't ubuntu
[18:05] <Masterphi> oops
[18:15] <ahasenack> debian/patches/series must be the conflict champion
[18:17] <nacc> ahasenack: often, yes
[18:17] <ahasenack> nacc: do you prefer a certain order when decomposing a big change? debian/changelog order, or debian/patches/series order?
[18:18] <nacc> ahasenack: so it's one logical change that is in a bunch of places?
[18:18] <ahasenack> one logical change has two debian/patches
[18:18] <ahasenack> and they are not together in series
[18:19] <ahasenack> nacc: it's the CVE-2016-8864 fix: http://pastebin.ubuntu.com/24974239/
[18:19] <ahasenack> they added a cve patch, and a fix for a regression in that patch as a separate patch
[18:19] <ahasenack> at the same time
[18:20] <ahasenack> and that 10.1ubuntu3 package wasn't even published it seems: https://launchpad.net/ubuntu/+source/bind9/1:9.10.3.dfsg.P4-10.1ubuntu3
[18:20] <nacc> https://launchpad.net/ubuntu/+source/bind9/+publishinghistory
[18:20] <nacc> use that --^
[18:20] <ahasenack> superseeded, deleted
[18:20] <nacc> ahasenack: the individual page reflects what is currently in the archive, iirc
[18:21] <nacc> ahasenack: as opposed to if it was ever published (as this one was)
[18:21] <ahasenack> the dates are odd
[18:21] <nacc> ahasenack: i'm confused, the change that shoulud be in that bit of delta is only in rt43779.patch on my reading
[18:22] <ahasenack> both patch files are there
[18:22] <nacc> ahasenack: let me look in the repo
[18:22] <ahasenack> diff from previous, in lp: http://launchpadlibrarian.net/303851673/bind9_1%3A9.10.3.dfsg.P4-10.1ubuntu2_1%3A9.10.3.dfsg.P4-10.1ubuntu3.diff.gz
[18:22] <ahasenack> CVE-2016-8864.patch is added
[18:23] <ahasenack> as is rt43779.patch
[18:28] <nacc> mdeslaur: --^ can you clarify?
[18:32] <nacc> ahasenack: it might be that it's really two changes, or since they were fixing CVE-2016-8864, and new this further fix was needed, but they hadn't published the CVE fix yet
[18:32] <nacc> ahasenack: just the changelog doesn't make that clear
[18:32] <nacc> and ubuntu4 has a further fix
[18:33] <mdeslaur> huh? it should be in ubuntu2
[18:33] <ahasenack> and the one in ubuntu4 introduces no new patch, according to the changelog
[18:33] <ahasenack> I think what doesn't have a new cve number is the two regressions
[18:35] <ahasenack> mdeslaur: actually, according to https://www.ubuntu.com/usn/usn-3119-1/, the fix for CVE-2016-8864 should be in 1:9.10.3.dfsg.P4-10.1ubuntu1.1 (zesty) or 1:9.10.3.dfsg.P4-8ubuntu1.2 (xenial)
[18:35] <ahasenack> ah
[18:35] <ahasenack> 1:9.10.3.dfsg.P4-8ubuntu1.2 is what introduces the patch in the case of yakkety, for example
[18:35] <ahasenack> er
[18:35] <ahasenack> copy&paste error
[18:35] <ahasenack> https://launchpad.net/ubuntu/+source/bind9/1:9.10.3.dfsg.P4-10.1ubuntu1.1
[18:36] <ahasenack> man, sometimes I wished all packages had the ubuntu release number in them
[18:36] <mdeslaur> wait a sec, I'm confused now
[18:36]  * mdeslaur looks
[18:37] <ahasenack> nacc: i don't see any ubuntuN.M in the rebase (http://pastebin.ubuntu.com/24974070/), all are ubuntuN, if that matters
[18:39] <stgraber> nacc: let me see
[18:39] <ahasenack> mdeslaur: we were wondering about the order of events, it looked like the fix for CVE-2016-8864 was added at the same time as one of its regression fixes  rt43779.patch
[18:39] <nacc> ahasenack: oh wait, a security update to xenial won't show up in the merge
[18:40] <stgraber> nacc: I'm sure it's got something to do with the random name, but we have a test for that and it's passing, so I'm kinda confused as to what's going on here :)
[18:40] <nacc> stgraber: yeah. I can reboot if you think it'd fix it
[18:40] <stgraber> nacc: nope, got the same here
[18:40] <nacc> stgraber: oh ok :)
[18:40] <nacc> stgraber: that's reassuring at least :)
[18:40] <stgraber> nacc: looking into it now, I have a feeling it's going to be a very stupid issue
[18:40] <mdeslaur> ahasenack, nacc: yes, it looks like zesty was missing CVE-2016-8864, and I added it at the same time as the other stuff, but forgot to add it to the changelog
[18:41] <mdeslaur> http://launchpadlibrarian.net/303851673/bind9_1%3A9.10.3.dfsg.P4-10.1ubuntu2_1%3A9.10.3.dfsg.P4-10.1ubuntu3.diff.gz
[18:41] <ahasenack> mdeslaur: and when you say "no CVE number", you mean no CVE number for the regression?
[18:41] <stgraber> nacc: we effectively rewrote the entire client code between 2.14 and 2.15, so that kind of regressions are unfortunately kinda expected... will update the testsuite
[18:41] <mdeslaur> yes, for the regression fix
[18:41] <ahasenack> or no new cve patch? Or what?
[18:41] <nacc> mdeslaur: yep, that makese sense
[18:41] <ahasenack> ok
[18:42] <nacc> ahasenack: sorry, i see it's a fix in zesty (not zesty-security), so it's correct for it to merge
[18:42] <nacc> ahasenack: the N.M uploads won't typically show up in a merge, they aren't in artful's history
[18:42] <stgraber> nacc: sure enough, it's a stupid mistake... fixed
[18:42] <nacc> stgraber: yep, i saw that in d/changelog, so figured it was a dogfood situation :)
[18:42] <stgraber> stgraber@castiana:~$ lxc launch ubuntu-daily:artful
[18:42] <stgraber> Creating the container
[18:42] <stgraber> Container name is: rare-gopher
[18:42] <stgraber> Starting rare-gopher
[18:42] <nacc> stgraber: i just happened to be heavily using lxd at the time :)
[18:43] <stgraber> nacc: if you use fixed names that'll work fine, it's just the logic to fetch the random name back from the daemon that's broken
[18:43] <nacc> stgraber: cool, will adjust my flow for now
[18:43] <stgraber> nacc: will send a branch in a few minutes, once merged, I'll cherry-pick the fix in the package, so everything should be back to normal by tomorrow morning (unless adt takes forever)
[18:44] <nacc> stgraber: great, thanks!
[18:44] <nacc> stgraber: while i have you, is there a file limit to how many files can be pushed by `lxc file push` ?
[18:45] <stgraber> nacc: I don't think so. We don't have batch sending so we just do a request for each arg. That'd make the limit be the maximum number of args you can have on the cmdline
[18:45] <nacc> stgraber: ok, i hit something funky with `lxc file push -r` as well ... but i'll debug it a bit more locally
[18:47] <stgraber> nacc: https://github.com/lxc/lxd/pull/3463
[18:47] <nacc> stgraber: great, thanks
[18:57] <ahasenack> man, are these bind9 patches big
[18:57] <ahasenack> scary stuff, that so much code had to be changed
[18:58] <dpb1> in perhaps the most mature product in the world
[18:58] <ahasenack> -rw-rw-r-- 1 andreas andreas 5,4K Jun 28 15:53 CVE-2017-3135.patch
[18:58] <ahasenack> and this is a regression patch in a *security* patch:
[18:58] <ahasenack> -rw-rw-r-- 1 andreas andreas  15K Jun 28 15:53 rt44318.patch
[18:59] <ahasenack> but, setting the record straight, a lot of that is test changes
[18:59] <ahasenack> which is good
[19:12] <ahasenack> mdeslaur: hi, question: we skipped CVE-2016-2775 because it's in lwresd and that package is in universe?
[19:12] <ahasenack> mdeslaur: https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-2775.html
[19:12] <ahasenack> or that just means it's not as urgent, and it's still work in progress?
[19:13] <mdeslaur> ahasenack: it means someone from the community has to contribute a debdiff and test it, etc.
[19:14] <ahasenack> ok
[19:14] <mdeslaur> I may include it next time, I just keep forgetting
[19:18] <ahasenack> man, it's harder than I thought to read a conflict in a d/p file
[19:19] <nacc> ahasenack: right, because it's a conflict in diff
[19:19] <ahasenack> exactly
[19:19] <ahasenack> the diff should be the same
[19:19] <nacc> ahasenack: you get used to it :)
[19:19] <ahasenack> I mean, the file is named the same :)
[19:19] <ahasenack> but I want to be sure
[19:20] <nacc> ahasenack: md5sum it
[19:20] <ahasenack> nacc: how can I see the two files? git doesn't create .dotfile versions
[19:20] <ahasenack> 	both added:      debian/patches/CVE-2016-2776.patch
[19:20] <nacc> ahasenack: i'm not sure i understand your question
[19:20] <nacc> ahasenack: but you can always do `git show <ref>:/path/to/file`
[19:20] <ahasenack> I want to quickly see the debian version of that file, and my version
[19:21]  * ahasenack tries git show
[19:21] <ahasenack> new/debian
[19:21] <ahasenack> right
[19:21] <ahasenack> works
[19:22] <ahasenack> much metter
[19:23] <ahasenack> ok, just a dep3 difference, and the usual @line numbers
[20:10] <ahasenack> nacc: hm, if you could spare a moment
[20:10] <ahasenack> nacc: http://pastebin.ubuntu.com/24974921/
[20:10] <ahasenack> debian has that patch already
[20:10] <ahasenack> slightly different (dep3 header), and of course the series file has conflicts
[20:10] <ahasenack> how do I drop our change in this case?
[20:13] <ahasenack> I could rebase --skip, but let's say I want to record this with some sort of commit
[20:19]  * ahasenack thinks git checkout --ours on both files
[20:19] <ahasenack> that it becomes an empty commit
[20:27] <ahasenack> s/that/then/
[20:37] <nacc> ahasenack: i'm here now
[20:37] <nacc> ahasenack: can we do a HO?
[20:37] <ahasenack> sure
[20:38] <nacc> ahasenack: use the standup one? just easier to discuss the code if we are looking at the same
[20:38] <ahasenack> nacc: standup, yep
[20:38] <nacc> ahasenack: omw
[20:45] <nacc> ahasenack: ORIG_HEAD
[20:45] <nacc> ahasenack: once all resolved, you'll run `git commit --allow-empty -c ORIG_HEAD`
[21:04] <ahasenack> nacc: after the empty commit, git rebase --continue is complaining about empty changes, and advising --skip
[21:04] <nacc> ahasenack: hrm, `git status` says nothing to commit?
[21:04] <ahasenack> http://pastebin.ubuntu.com/24975282/
[21:04] <nacc> ahasenack: ok, then maybe you do need to explicitly --skip it, sorry
[21:05] <ahasenack> yeah, status is empty
[21:05] <ahasenack> ok
[21:05] <ahasenack>   (all conflicts fixed: run "git rebase --continue")
[21:05] <ahasenack> heh
[21:05] <ahasenack> nothing to commit, working directory clean
[21:05] <ahasenack> ok
[21:11] <Czr3> hi.. Terminal must be at least 80 x 27. and i don't know how to solve this...
[21:13] <ahasenack> Czr3: what do you mean?
[21:14] <Czr3> i was installin asterisk 14 on debian 9, then when i used "make menuselect" it said  error: "terminal must be at least 80 x 27"..
[21:14] <Czr3> installing*
[21:15] <dpb1> debian 9?
[21:15] <Czr3> yeap D=
[21:15]  * dpb1 points at name of channel. :)
[21:25] <ahasenack> patch 6 out of 12
[21:25] <ahasenack> phew
[21:26] <furkan> does anybody here have VMs running with QCOW2 disks under KVM with the discard=unmap setting? fstrim seems to work for me from within the VM, but the disk image size doesn't decrease
[21:26] <furkan> i'm using pc-i440fx-xenial for the machine type, and virtio-scsi
[21:27] <ahasenack> that patch for cve 2016 8864 was infamous it seems:
[21:27] <ahasenack> CVE-2016-8864.patch
[21:27] <ahasenack> CVE-2016-8864-regression2.patch
[21:27] <ahasenack> CVE-2016-8864-regression.patch
[21:28] <ahasenack> furkan: I don't know what discard=unmap does, but regarding qcow2 image sizes, did you check with du and qemu-image info?
[21:28] <ahasenack> as opposed to ls, I mean
[21:28] <sarnold> you may need to repack the qcow2 I wouldn't expect them to magically shrink or pass through the holes to the OS
[21:28] <furkan> discard=unmap enables TRIM on the guest, so it informs the hypervisor of blocks that have been deleted
[21:29] <furkan> so theoretically that's supposed to allow the image to shrink by itself
[21:29] <furkan> http://dustymabe.com/2013/06/11/recover-space-from-vm-disk-images-by-using-discardfstrim/
[21:31] <furkan> so when i run fstrim on the VM, it tells me that it's trimmed 3.8GB, but the image size stays the same