| cryptodan_mobile | nacc: whislock drive firmware update success | 00:06 |
|---|---|---|
| ahasenack | rbasak: hi, can you do bug nominations? | 12:59 |
| ahasenack | https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1583324 | 12:59 |
| ubottu | 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 |
| ahasenack | or rather, accept them | 12:59 |
| 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:01 | |
| ahasenack | rbasak: thanks | 13:02 |
| eugenio_ | how can I check in which partition grub2 is installed? | 13:04 |
| 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:42 |
| 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:47 |
| 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:48 |
| computamike | rbasak: the current list of boxes is here : https://app.vagrantup.com/ubuntu | 13:49 |
| 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:50 |
| rbasak | I'm pretty sure it's legit, but I don't know how to confirm that. | 13:51 |
| rbasak | computamike: https://blog.ubuntu.com/2016/01/05/celebrating-over-10-million-vagrant-ubuntu-downloads | 13:53 |
| rbasak | If that helps | 13:53 |
| 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:54 |
| 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:57 |
| computamike | gaughen: cool - thanks for that :) | 13:58 |
| Nivex | Any news on when do-release-upgrade from 16.04 to 18.04 will be enabled? | 15:59 |
| leftyfb | ^ that's actually a good question. I thought it was supposed to match up with the 18.04.1 release | 16:01 |
| nacc | leftyfb: i think there was/is some issue with the upgrade tool, but not sure | 16:15 |
| 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:30 |
| 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 |
| ubottu | Launchpad bug 900741 in squid (Ubuntu) "Remove and blacklist squid" [Undecided,Fix released] | 16:31 |
| nacc | ahasenack: the bug refereneced in the blacklist | 16:31 |
| nacc | src:squid and src:squid3 should both be imported, fwiw | 16:32 |
| 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:33 |
| nacc | ahasenack: makes sense | 16:45 |
| ahasenack | how could we proceed? Remove the block, let squid sync, and remove our squid3 source? | 16:47 |
| ahasenack | asking for a friend :) | 16:47 |
| 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:49 |
| ahasenack | squid3 does have quite a bit of delta | 16:50 |
| ahasenack | but that should be revisited anyway | 16:50 |
| ahasenack | last time I merged that I was quite still focused in the merge process, and not necessarily trying to drop unecessary delta | 16:51 |
| ahasenack | rbasak: your libnl3 and unixodbc cards in the roadmap board can be tagged with done, right? | 16:52 |
| rbasak | ahasenack: ah yes. Labels tweaked, thanks. | 17:36 |
| 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:37 |
| 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:38 |
| rbasak | (it's just a question of effort vs. going for squid 4, etc) | 17:39 |
| 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:54 |
| 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 | 17:55 |
| ahasenack | maybe I should checkout each one of those "Import ..." commits, then rebase, and somehow glue them together again | 18:01 |
| ahasenack | how about: checkout (a) ("Import patches unapplied ..."); reset HEAD^; discard; rebase; | 18:04 |
| ahasenack | then cherry-pick (b); reset HEAD^; discard; rebase | 18:05 |
| ahasenack | and so on | 18:05 |
| nacc | ahasenack: sorry, you have broken up commits (your upload tags) for each version of ubuntu, right? | 18:11 |
| 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:12 |
| 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:14 |
| ahasenack | as I can give it a range | 18:15 |
| ahasenack | and on what committish to apply it | 18:15 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:34 |
| ahasenack | I think it worked | 18:41 |
| 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:42 |
| 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:43 |
| nacc | you can check the treeish | 18:44 |
| nacc | git diff-tree | 18:44 |
| ahasenack | that? https://pastebin.ubuntu.com/p/TFTmpr4My5/ | 18:44 |
| 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:45 |
| nacc | cool | 18:46 |
| ahasenack | without HEAD, it gives that output | 18:46 |
| nacc | right, local tree vs. commited tree | 18:46 |
| ahasenack | when using git rebase, is "--onto HEAD" the same as not passing --onto at all? | 18:47 |
| nacc | "The current branch is reset to <upstream>, or <newbase> if the --onto option was supplied." | 18:48 |
| nacc | and there is a bit about how upstream is derived if not specified on the cli | 18:49 |
| ahasenack | ok | 18:49 |
| 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:50 |
| 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 | 18:51 |
| 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:15 |
| ahasenack | yes | 19:24 |
| ahasenack | this one will be needed multiple times in the future | 19:24 |
| ahasenack | because many packages have the empty dir problem | 19:25 |
| nacc | right | 19:25 |
| 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:12 |
| bigpic | screen shot: https://i.imgur.com/gqfCYiu.png | 20:13 |
| bigpic | any ideas? | 20:13 |
| nacc | bigpic: to be clear, that's a 4g *root* *logical volume* | 20:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:21 |
| 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:22 |
| 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:23 |
| tomreyn | bigpic: do you know about the alternative server installer? | 20:25 |
| bigpic | do share | 20:25 |
| tomreyn | i.e. the 'classic' one | 20:25 |
| tomreyn | https://www.ubuntu.com/download/alternative-downloads#alternate-ubuntu-server-installer | 20:26 |
| tomreyn | - less fancy | 20:27 |
| tomreyn | + works | 20:27 |
| powersj | bug 1785321 | 20:28 |
| ubottu | bug 1785321 in subiquity "LVM Entire Disk option does not use entire disk" [Undecided,New] https://launchpad.net/bugs/1785321 | 20:28 |
| powersj | bigpic, thank you for taking the time to ask here | 20:28 |
| nacc | ahasenack: nice :) | 21:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
