[07:31] <lordievader> Good morning
[08:12] <Mr_Pan> smb, from BW :P im in Singen
[10:40] <ahasenack> good morning
[11:08] <ahasenack> rbasak: hi,
[11:08] <ahasenack> rbasak: in terms of the git workflow for merges,
[11:09] <ahasenack> rbasak: do you have a preference about when to commit "added changes": before git ubuntu merge finish, or after?
[12:10] <rbasak> ahasenack: ideally before, but I don't think there's any need to rebase etc if it goes in later.
[12:17] <ahasenack> rbasak: that's fine
[12:17] <ahasenack> rbasak: another question, when consolidating the logical
[12:17] <ahasenack> I have a delta which is adding a file, then another piece of delta which is changing that file
[12:17] <ahasenack> rbasak: I presume it's ok and wanted to consolidate those two into one commit, "adding file"? Or do we want to record the change? The change was a bugfix
[12:17] <ahasenack> specifically, it's the apparmor profile
[12:18] <rbasak> It should definitely be consolidated by the time of the next logical (in he following merge).
[12:19] <rbasak> I don't have a strong feeling on whether it needs doing in _this_ merge
[12:19] <ahasenack> it should have been consolidated in the previous merge already I think
[12:19] <ahasenack> now I'm adding yet another fix to it, that's one of the "added changes"
[12:19] <ahasenack> so here it's still separated, to be consolidated next time
[12:19] <ahasenack> that's when I noticed it wasn't consolidated previously
[12:19] <rbasak> Sometimes the need will be noticed in a MP, and in that case I think it's fine to leave as a fixup commit
[12:19] <rbasak> For consolidation next time
[12:20] <rbasak> So in the general case I think it's fine.
[12:20] <rbasak> (except that it must be consolidated in the "logical" step next time)
[12:20] <rbasak> IOW, the one place that I think it is a requirement to complete full consolidation is in the logical step in our workflow.
[12:21] <rbasak> If a change comes after that for whatever reason, it can wait until the following logical step in the following merge.
[12:22] <rbasak> In the case of a mistake following the workflow (missing a thing in logical) I think being lenient is appropriate.
[12:23] <rbasak> Unless it makes te review harder
[12:23] <rbasak> Since the reason for that step is to move towards a full consolidation of the Ubuntu delta in the long term. Short term unconsolidated commits will happen anyway so the odd extra bit doesn't really matter
[12:30] <ahasenack> rbasak: in this case, the delta is already a) add file; b) fix file. That's the current logical, and was like that in the previous upload and perhaps even before (I didn't check that far)
[12:31] <ahasenack> rbasak: and one of my "added changes" is c) another-fix-for-file
[12:31] <ahasenack> rbasak: so let me ask this
[12:31] <ahasenack> rbasak: I'm already at the end of the merge, and I noticed this
[12:31] <ahasenack> rbasak: so can I do this:
[12:31] <ahasenack> rbasak: a) checkout logical; rebase -i old/debian and fixup the two commits (a) and (b), merging them into (a)
[12:32] <ahasenack> rbasak: now, instead of rebasing that new logical on new/debian and doing all that work, can I go back to my branch and merge the same two commits?
[12:32] <ahasenack> or should I rebase the new logical (with the merged commits) onto new/debian and do the whole process
[12:36] <rbasak> ahasenack: I think it's fine to rebase just your merge branch
[12:37] <ahasenack> and do the same there, right
[12:37] <rbasak> However it will make review of the merge ever so slightly harder
[12:37] <ahasenack> hm
[12:37] <rbasak> Since the reviewer needs to ensure that the merge branch result is the same as the two commits from logical
[12:38] <ahasenack> but I will update the logical tag
[12:40] <rbasak> Oh
[12:40] <rbasak> In that case, that's fine
[12:43] <ahasenack> rbasak: ah, about the previous question about added changes before or after merge finish
[12:44] <ahasenack> rbasak: if doing it before merge finish, then bug references will lose the ":" in the "LP: #xxxxxx" syntax
[12:44] <ahasenack> in d/changelog
[12:44] <rbasak> merge finish does that?
[12:44] <ahasenack> yep
[12:44] <rbasak> That might need manual fixing then
[12:44] <ahasenack> because it thinks it's dealing with remaining changes only
[12:45] <ahasenack> and drops
[12:45] <ahasenack> where it's correct to strip that
[12:45] <ahasenack> or, leave only remaining changes + drops before merge finish, then add changes, and use git-ubuntu.reconstruct-changelog for the added changes
[12:46] <ahasenack> although that might strip the : too, come to think of it
[12:46] <rbasak> I think it's OK to drop the LP reference entirely
[12:46] <rbasak> It'll be further down in the changelog
[12:46] <rbasak> And after consolidation it might not make direct sense any more
[12:47] <ahasenack> but not for added changes. The bug won't be auto-closed
[12:47] <ahasenack> git-ubuntu.reconstruct-changelog does not strip the :, just checked
[12:48] <ahasenack> hm, the wiki page about the git workflow actually recomments to do extra fixes after merge finish
[12:49] <ahasenack> I missed that before
[13:09] <ahasenack> cpaelzer: the main task in this bug is "invalid", right? https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1801128
[13:10] <ahasenack> disco had 7.8 iirc
[13:10] <ahasenack> and now 7.9
[13:10] <ahasenack> or "fix released"
[13:11]  * ahasenack comments on the bug
[13:13] <cpaelzer> ahasenack: released
[13:14] <cpaelzer> ahasenack: updated the bug
[13:14] <ahasenack> thx
[13:14] <ahasenack> it came up in triage, that's why I pinged you :)
[13:14] <cpaelzer> totally fine
[13:15] <cpaelzer> I thought I clean it up (and I did) but forgot that detail - thanks for the ping
[13:15] <ahasenack> cpaelzer: how's your nss upload?
[13:15] <cpaelzer> that waits intentionally
[13:15] <ahasenack> just saw #1803707
[13:15] <cpaelzer> ahasenack: I opened the MP for review
[13:15] <cpaelzer> but we want kstenerud to coplete nspr first
[13:15] <cpaelzer> as nss builds against nspr and mdeslaur told us they usually go together
[13:15] <ahasenack> I remember they were entangled, just didn't remember who came first
[13:15] <cpaelzer> nspr -> nss
[13:15] <cpaelzer> I stated so in the MP to avoid being sponsored by accident
[13:16] <cpaelzer> but even then it would be just a no change rebuild to fix it
[13:16] <ahasenack> I'll link the mp to the bug
[13:16] <ahasenack> (nss)
[13:16] <cpaelzer> isn't it auto linked?
[13:16] <cpaelzer> the merge bug I mean
[13:16] <ahasenack> it wasn't for some reason
[13:16] <ahasenack> let me check your d/changelog
[13:16] <cpaelzer> hmm but it seems right in the changelog to me
[13:16] <cpaelzer> odd
[13:18] <cpaelzer> I still fight the "Too many levels of symbolic links"
[13:18] <cpaelzer> it seems gone in Disco, but still is in D-unstable
[13:18] <cpaelzer> well I do so only in spare time between other bugs - as I wait for good ideas to come to me :-)
[13:18] <cpaelzer> I have isolated enough to hopefully strace it soon
[13:20] <ahasenack> it's gone in disco?
[13:20] <ahasenack> just like that?
[13:22] <cpaelzer> yeah
[13:22] <ahasenack> cpaelzer: this one is now just missing mecab-ipadic, is that something you can do, or an AA?
[13:22] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/mecab/+bug/1781529
[13:22] <cpaelzer> I assumed something like that, due to -testing and -cosmic being fine
[13:22] <cpaelzer> but I can't yet isolate which change it was
[13:23] <cpaelzer> ahasenack: no that needs an AA
[13:23] <ahasenack> k
[13:23] <cpaelzer> ahasenack: like the override vorlon did
[13:24] <ahasenack> right
[13:31] <cpaelzer> ahasenack: hehe, enough debugging code makes the issue go away
[13:31] <cpaelzer> +1 for a race of some sort
[13:31] <cpaelzer> but that makes tracking why it was failing so much harder :-/
[14:05] <rbasak> cpaelzer, kstenerud: should I treat my card for Thursday triage last week as done? Or does it need doing?
[14:08] <ahasenack> rbasak: is this a tell about the user switching between mysql and mariadb:
[14:08] <ahasenack> ERROR: Unable to start MySQL server:
[14:08] <ahasenack> mysqld: Can't read dir of '/etc/mysql/conf.d/' (Errcode: 2 - No such file or directory)
[14:08] <ahasenack> or some other behavior we know about already?
[14:08] <ahasenack> I've seen that in a few mysql bug reports
[14:09] <rbasak> ahasenack: /etc/mysql/conf.d/ is shipped by mysql-common IIRC
[14:09] <rbasak> So either the user has removed it or is using a non-archive mysql-common (shipped perhaps by upstream in a third party repo)
[14:09]  * ahasenack can't figure out what users are doing wrong when installing mysql
[14:09] <rbasak> Yeah: https://packages.ubuntu.com/bionic/all/mysql-common/filelist
[14:09] <ahasenack> oh man:
[14:09] <ahasenack> Commandline: apt-get purge mysql-server* mariadb*
[14:09] <rbasak> So I think that error is automatically a "looks like a local configuration problem".
[14:09] <ahasenack> what's wrong with people installing mysql
[14:10] <ahasenack> Commandline: apt install yum
[14:10] <rbasak> ahasenack: Josh it and move on :)
[14:16] <ahasenack> maybe we should conflict mysql-server with ubuntu-desktop
[14:16] <ahasenack> :)
[14:17] <cpaelzer> ahasenack: rbasak: powersj: all last weeks triage cards are done
[14:19] <rbasak> OK. Thanks!
[14:49] <frickler> coreycb: I got problems rebuilding neutron for stable/pike, you require python-pbr>=2.0.0 here, but stable/pike UCA only has 1.8.0 for me https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/neutron/tree/debian/control?h=stable/pike#n11
[14:49] <frickler> coreycb: this line also looks like a broken edit https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/neutron/tree/debian/control?h=stable/pike#n125
[14:51] <coreycb> frickler: stable/pike has 2.0.0 - http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/pike_versions.html
[14:55] <frickler> coreycb: indeed, weird, for some reason my build vm didn't pull in the uca pkgs. needed another "apt update" run to fix it. sorry for the noise ;-)
[15:02] <coreycb> frickler: np :)
[15:51] <Mr_Pan> can i install openmediavault on ubuntu 18.04 server?
[16:21] <lordcirth_> Mr_Pan, openmediavault is an appliance, ie a pre-configured OS.  What do you actually want?
[16:53] <jamespage> coreycb: OK I uploaded nova to disco-proposed
[16:53] <jamespage> fixed a few more py3.7 issues but not all of them - we still skip three tests...
[16:55] <coreycb> jamespage: ok thanks
[17:08] <bipul> How to install Ubuntu server via preseed method.
[17:08] <jamespage> coreycb: doing some work on the bom for stein to fill in the rest of my day
[17:09] <jamespage> frickler: I appreciate you pinged about an apache2 module issue last week - I've not found time to look yet
[17:10] <coreycb> jamespage: ok. i've not started on stein yet today but will shortly. if i can pick up on anything in particular let me know, other wise i'll focus on core pkgs.
[17:11] <jamespage> coreycb: I've been nudging it along
[17:11] <jamespage> coreycb: core pkg focus is fine for now
[19:28] <Sircle> Iam looking to rent out a vps/server. Iam more interested in disk space (hdd will work) as my database will grow very fast and internet speed. Which host is recommended in a budget?
[19:29] <sarnold> vultr packet.net hetzner all seem popular among folks who want to spend less than aws
[19:29] <Sircle> sarnold,  what about ramnode?
[19:29] <sarnold> Sircle: never heard of it
[19:29] <Sircle> hm
[19:30] <sarnold> don't worry about that too much, I'm not really in that market space
[19:30] <sarnold> it just means I can't give you solid feedback
[19:33] <Sircle> sarnold,  how much disk space is there in ec2?
[19:34] <sarnold> Sircle: as many petabytes as you want to pay for
[19:34] <Sircle> I meant the free tier
[19:35] <sarnold> probably 10 or 20 gigs
[19:37] <Sircle> k
[19:37] <Sircle> I recalled, it was 30