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