[00:06] <cryptodan_mobile> nacc: whislock drive firmware update success
[12:59] <ahasenack> rbasak: hi, can you do bug nominations?
[12:59] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1583324
[12:59] <ahasenack> or rather, accept them
[13:01] <rbasak> ahasenack: done (without even reviewing, because IMO you're perfectly competent to decide that for yourself)
[13:01]  * rbasak ponders writing a bot to auto accept nominations from specific people
[13:02] <ahasenack> rbasak: thanks
[13:04] <eugenio_> how can I check in which partition grub2 is installed?
[13:42] <computamike> I'm looking at spinning up a vagrant box - trying my hand at chef.  I'm a bit dubious about the trustworthyness of these images - for example there is an ubuntu/precise64 Official image - but that went out of support last year.  Anyone got any guidance?
[13:47] <rbasak> computamike: why Precise?
[13:47] <rbasak> It's EOL.
[13:47] <rbasak> Or have you been unable to find a more recent official vagrant image?
[13:48] <computamike> rbasak: that's my point - I wasn't sure if the official images are being maintained by canonical, or if someone has just uploaded them
[13:48] <rbasak> I think there has been some interaction in the past. I don't know of current status. Odd_Bloke or gaughen ^ might know
[13:49] <computamike> rbasak: the current list of boxes is here : https://app.vagrantup.com/ubuntu
[13:50] <computamike> rbasak: I'm assuming that ubuntu is like the official canonical/ubuntu project boxes, and not some black hat who registered the name ubuntu
[13:51] <rbasak> I'm pretty sure it's legit, but I don't know how to confirm that.
[13:53] <rbasak> computamike: https://blog.ubuntu.com/2016/01/05/celebrating-over-10-million-vagrant-ubuntu-downloads
[13:53] <rbasak> If that helps
[13:54] <computamike> rbasak: I also found that if you look at the details of an image it says that it is externally hosted at cloudimages.ubuntu.com
[13:57] <computamike> rbasak: cheers for the help - i'm going to try a bionic machine and see how I get on
[13:57] <gaughen> rbasak, computamike those are legit, but I got delayed in my reply because of all those old images. I'll followup with the team, looks like we need to add a step to our EOL process.
[13:58] <computamike> gaughen: cool - thanks for that :)
[15:59] <Nivex> Any news on when do-release-upgrade from 16.04 to 18.04 will be enabled?
[16:01] <leftyfb> ^ that's actually a good question. I thought it was supposed to match up with the 18.04.1 release
[16:15] <nacc> leftyfb: i think there was/is some issue with the upgrade tool, but not sure
[16:30] <ahasenack> rbasak: considering just the "squid" (not squid3) source package, ubuntu's latest release there was squid (2.7.STABLE9-4ubuntu4) oneiric; urgency=low
[16:31] <ahasenack> rbasak: and that's the git-ubuntu repo (squid) where debian/sid is pointing at squid-4.1
[16:31] <ahasenack> so the last "squid" (not squid3) source package in ubuntu was 2.7, and had a delta. That's why it didn't sync?
[16:31] <nacc> ahasenack: the bug has the explanation
[16:31] <ahasenack> which bug?
[16:31] <nacc> (the bug being https://bugs.launchpad.net/ubuntu/+source/squid/+bug/900741)
[16:31] <nacc> ahasenack: the bug refereneced in the blacklist
[16:32] <nacc> src:squid and src:squid3 should both be imported, fwiw
[16:33] <nacc> afaict, in debian, binary squid3 is from src:squid now, as they are at 4.1, as you mentioned, ahasenack
[16:33] <ahasenack> yeah, debian's squid-4 is building squid3 as a transitional package
[16:45] <nacc> ahasenack: makes sense
[16:47] <ahasenack> how could we proceed? Remove the block, let squid sync, and remove our squid3 source?
[16:47] <ahasenack> asking for a friend :)
[16:49] <nacc> ahasenack: it probably should have been fixed once src:squid started shipping squid3 binaries (if it did while squid3 also did)
[16:49] <nacc> ahasenack: i'd need to look at all the binaries in question and makes sure they could be matched up properly
[16:49] <nacc> my guess is at least some delta will be necessary to converge
[16:50] <ahasenack> squid3 does have quite a bit of delta
[16:50] <ahasenack> but that should be revisited anyway
[16:51] <ahasenack> last time I merged that I was quite still focused in the merge process, and not necessarily trying to drop unecessary delta
[16:52] <ahasenack> rbasak: your libnl3 and unixodbc cards in the roadmap board can be tagged with done, right?
[17:36] <rbasak> ahasenack: ah yes. Labels tweaked, thanks.
[17:37] <rbasak> ahasenack: we can always sync manually. So probably best to do it all and only then drop it from the autosync blacklist.
[17:37] <ahasenack> what do you mean "do it all"?
[17:37] <rbasak> I'm just concerned that it's a little late to be starting that now. Less than three weeks to feature freeze.
[17:38] <rbasak> Generally sort it out. I'm not sure what's needed yet :)
[17:38] <rbasak> (update to squid 4 that is)
[17:38] <ahasenack> we could then just bump the minor to the latest upstream, but go ahead of debian in that process
[17:38] <ahasenack> or leave it for the next cycle entirely
[17:38] <rbasak> I have no objection to bumping the minor.
[17:38] <ahasenack> ok
[17:39] <rbasak> (it's just a question of effort vs. going for squid 4, etc)
[17:54] <ahasenack> rbasak: I still don't quite understand how to use rebase to take advantage of the previous work in the apache merge
[17:54] <ahasenack> rbasak: when I start with rebase -i old/debian, I get the 3 previous uploads listed as commits by git-ubuntu
[17:54] <ahasenack> which I would normally take apart
[17:54] <ahasenack> I can't start another rebase in there, because I'm already inside a rebase
[17:55] <ahasenack> so let's say I "e" the first one, that's the 2.4.33-3ubuntu1 import
[17:55] <ahasenack> I would normally do git reset HEAD^, and then proceed with the invidual commits. These I did before, and I can see them in the pkg/upload/2.4.33-3ubuntu1 upload tag
[17:55] <ahasenack> but I can't run rebase again now
[18:01] <ahasenack> maybe I should checkout each one of those "Import ..." commits, then rebase, and somehow glue them together again
[18:04] <ahasenack> how about: checkout (a) ("Import patches unapplied ..."); reset HEAD^; discard; rebase;
[18:05] <ahasenack> then cherry-pick (b); reset HEAD^; discard; rebase
[18:05] <ahasenack> and so on
[18:11] <nacc> ahasenack: sorry, you have broken up commits (your upload tags) for each version of ubuntu, right?
[18:12] <nacc> ahasenack: so checkout to old/debian, cherry-pick the sequence of commits from old/debian->first upload tag; then the sequence of commits from first import tag to second upload tag... etc
[18:12] <nacc> can use a simple wrapper aroudn git-rev-list to get the appropriate commits
[18:14] <ahasenack> nacc: yeah, cherry-pick was my first thought, each one, but rbasak suggested a rebase
[18:14] <ahasenack> which would get them all
[18:15] <ahasenack> as I can give it a range
[18:15] <ahasenack> and on what committish to apply it
[18:24] <nacc> ahasenack: ah yes, you could selectively rebase
[18:24] <nacc> it's functionally the same
[18:24] <ahasenack> ok
[18:24] <nacc> and then verify the diff is the same
[18:24] <nacc> ahasenack: see the git-rebase manpage for the --onto option
[18:25] <ahasenack> yeah
[18:25] <nacc> you're basically taking topic branches and stitching them together, if that makes sense
[18:25] <ahasenack> this was my first one:
[18:25] <ahasenack>  git rebase --onto old/debian old/debian pkg/upload/2.4.33-3ubuntu1
[18:25] <ahasenack> the first import after old/debian
[18:25] <nacc> right, and then you'd 'save' that with a tag or branch locally
[18:25] <nacc> and rebase the next tag onto that saved object
[18:25] <nacc> (i think)
[18:25] <ahasenack> that save is I think what I missed, it's the second time I'm going through this
[18:25] <ahasenack> the state right now is correct, but it got lost when I repeated if for 3ubuntu2 and 3ubuntu3
[18:25] <nacc> you could also use the hash, of course, but tags/branches are easier to type :)
[18:26] <ahasenack> I missed --onto for 3ubuntu2 and 3ubuntu3
[18:26] <nacc> right
[18:26] <nacc> that's what we get to avoid when upload tags get used :)
[18:26] <nacc> otherwise, it's the same as what gu-merge is doing under the covers
[18:26] <ahasenack> git log looks now just what it was like when 3ubuntu1 was uploaded
[18:26] <ahasenack> so that's good
[18:27] <nacc> yep, tbh; i think you didn't need to rebase the first upload tag
[18:27] <nacc> as it should be identical to what it was
[18:27] <ahasenack> right, because right now it's like I just checked out that upload tag
[18:27] <nacc> (since that's how the old merge was done, basically -- old/debian now is what was new/debian then)
[18:27] <nacc> yep
[18:28] <ahasenack> so...
[18:28] <ahasenack> why don't I just checkout the upload tag for the current version in the archive
[18:28] <ahasenack> ah
[18:28] <ahasenack> n/m
[18:28] <nacc> right :)
[18:28] <nacc> you *could* do that, if each of your uploads used the upload history manually
[18:29] <nacc> which technically you could have been doing
[18:29] <ahasenack> it's just the first one that works "automatically" here
[18:29] <ahasenack> the rest have the "Import patches unapplied ..." bits
[18:29] <ahasenack> s/rest/subsequent ones/
[18:30] <ahasenack> ok, continuing, let's see what I get
[18:30] <rbasak> You only need to rebase the most recent upload tag, surely?
[18:30] <ahasenack> there were 3
[18:30] <rbasak> (for the purposes of a package merge)
[18:30] <nacc> rbasak: none of the upload tags have upload tags in the history
[18:30] <rbasak> Oh. I see.
[18:30] <rbasak> OK
[18:30] <nacc> rbasak: since none were integrated, if that makes sense?
[18:30] <nacc> (due to empty dirs in this case)
[18:30] <rbasak> Yeah
[18:31] <rbasak> I get it now
[18:31] <nacc> so you have to manually stitch together the sequence of upload tags
[18:31] <nacc> ack :)
[18:31] <ahasenack> sharpening git-foo skillz
[18:34] <nacc> this is probably something we could do in gu-merge until empty dirs are fixed; as long as the upload<->import tags match along the history except for only empty dirs
[18:34] <nacc> or at least help provide git- commands that should do what you need?
[18:41] <ahasenack> I think it worked
[18:42] <ahasenack> checked out upload/2.4.33-3ubuntu1
[18:42] <ahasenack> then rebase --onto upload/2.4.33-3ubuntu1 import/2.4.33-3ubuntu1 upload/2.4.33-3ubuntu2
[18:42] <nacc> yeah, that seems about right to me
[18:42] <ahasenack> then rebase --onto <hash-i-am-at> import/2.4.33-3ubuntu2 upload/2.4.33-3ubuntu3
[18:42] <nacc> yes, i think so
[18:43] <ahasenack> about to run some checks
[18:43] <nacc> that should give you a treeish that matches upload/2.4.33-3ubuntu3
[18:43] <nacc> but with broken-out commits, i think
[18:43] <ahasenack> ((c957d262...))andreas@nsnx:~/git/packages/apache2/apache2$ git diff pkg/upload/2.4.33-3ubuntu3
[18:43] <ahasenack> ((c957d262...))andreas@nsnx:~/git/packages/apache2/apache2$
[18:43] <ahasenack> diff is empty
[18:43] <ahasenack> and I haz broken out commits
[18:43] <ahasenack> time to \o/ ?
[18:43] <nacc> cool :)
[18:44] <nacc> you can check the treeish
[18:44] <nacc> git diff-tree
[18:44] <ahasenack> that? https://pastebin.ubuntu.com/p/TFTmpr4My5/
[18:45] <nacc> yeah, is that accurate (local modifications to the debian directory)?
[18:45] <ahasenack> git diff-tree HEAD pkg/upload/2.4.33-3ubuntu3 is empty
[18:46] <nacc> cool
[18:46] <ahasenack> without HEAD, it gives that output
[18:46] <nacc> right, local tree vs. commited tree
[18:47] <ahasenack> when using git rebase, is "--onto HEAD" the same as not passing --onto at all?
[18:48] <nacc> "The current branch is reset to <upstream>, or <newbase> if the --onto option was supplied."
[18:49] <nacc> and there is a bit about how upstream is derived if not specified on the cli
[18:49] <ahasenack> ok
[18:50] <ahasenack> ok, so after all this I should be ready to run git ubuntu tag --deconstruct
[18:50] <nacc> ahasenack: i think it's equivalent, although the internal logic may be slightly different. it does depend a bit on what else you pass to rebase
[18:50] <nacc> ahasenack: i think so, yeah
[18:51] <ahasenack> thanks for the guidance
[18:51] <nacc> ahasenack: np, it's at least somewhat still in my head :)
[18:51] <ahasenack> :)
[18:51] <nacc> ahasenack: may be worth MP'ing into the manpages
[18:51] <ahasenack> I have a tips&tricks doc, that could become an faq in the future
[19:15] <nacc> ahasenack: definitely
[19:15] <nacc> ahasenack: and maybe in the 'other info' secitno of the main git-ubuntu manpage?
[19:15] <nacc> or a link to a living doc otherwise
[19:24] <ahasenack> yes
[19:24] <ahasenack> this one will be needed multiple times in the future
[19:25] <ahasenack> because many packages have the empty dir problem
[19:25] <nacc> right
[20:12] <bigpic> hey guys i’m firing up an 18.04 server for the first time
[20:12] <bigpic> I’ve given it a 48gb disk
[20:12] <bigpic> told it to use the entire disk with lvm
[20:12] <bigpic> but it’s only creating a 4gb boot disk
[20:13] <bigpic> screen shot: https://i.imgur.com/gqfCYiu.png
[20:13] <bigpic> any ideas?
[20:14] <nacc> bigpic: to be clear, that's a 4g *root* *logical volume*
[20:15] <nacc> and no, i've not used the installer; is this the 'live' or the non-live iso?
[20:15] <bigpic> yea it’s creating a 4g / a 1g /boot and leaving 43g free unpartioned
[20:16] <ahasenack> that's the live one
[20:16] <ahasenack> powersj: have you seen that? ^
[20:16] <ahasenack> bigpic: those numbers were all automatically chosen?
[20:16] <bigpic> yes
[20:17] <ahasenack> that's not from a previous run by any chance?
[20:17] <bigpic> fresh vm
[20:17] <powersj> hmm
[20:17] <powersj> let me take a look locally
[20:21] <ahasenack> nacc: rbasak: I think it all worked, thanks again: https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+merge/352331
[20:21] <ahasenack> we'll see on Monday when people look at it more carefully :)
[20:21] <ahasenack> cheers
[20:21] <tomreyn> bigpic: is this 18.04(.0) or 18.04.1?
[20:22] <bigpic> i grabbed the ubuntu-18.04.1 iso around noon est
[20:22] <powersj> LVM so it is .1
[20:22] <powersj> and confirmed :\
[20:22] <powersj> not good
[20:22] <ahasenack> I didn't try the auto option :/
[20:22] <powersj> I know I tried it
[20:22] <powersj> but I guess I didn't look hard enough because the install will work
[20:23] <powersj> the layout of course is flat out wrong
[20:23]  * powersj files a bug against subiquity 
[20:23] <bigpic> thx for looking into it.. i’ll sit tight
[20:25] <tomreyn> bigpic: do you know about the alternative server installer?
[20:25] <bigpic> do share
[20:25] <tomreyn> i.e. the 'classic' one
[20:26] <tomreyn> https://www.ubuntu.com/download/alternative-downloads#alternate-ubuntu-server-installer
[20:27] <tomreyn> - less fancy
[20:27] <tomreyn> + works
[20:28] <powersj> bug 1785321
[20:28] <powersj> bigpic, thank you for taking the time to ask here
[21:39] <nacc> ahasenack: nice :)