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