[13:47] <chrisccoulson> hmmmm, this is the first hot day we've had since i moved my desk in to it's new room
[13:47] <chrisccoulson> and being right next to the window is turning out to be a little bit uncomfortable
[13:47] <chrisccoulson> probably not the best place to sit!


[00:40] <mike802> hi all, i'm new to ubuntu server.  i'm currently stuck trying to install my lamp stack.  i installed apache2 with a vhost and ssl, then tried to install the moinmoin wiki with very frustrating results
[00:41] <blackflow> mike802: any specific problem?
[00:49] <mike802> just a 404 not found
[00:49] <mike802> the default apache2 page shows up (with ssl) on the root
[00:50] <mike802> and, i put a test html in my vhost which works
[00:50] <sarnold> do you need to a2enable a module or two to make the wiki work?
[00:50] <sarnold> are there more detailed errors in the apache logs?
[00:50] <mike802> :/
[00:51] <mike802> i was just going by the ubuntu server documentation
[00:51] <mike802> they only mention a2enable for actual apache2 stuff
[00:51] <mike802> and no mention of logs....
[00:51] <sarnold> logs should be /var/log/apache*/
[00:58] <mike802> first log says  server certificate does NOT include an ID which matches the server name
[03:12] <jak2000> */1 * * * * root /home/scripts/reboot.sh   <--- this command run every minute?
[03:14] <whislock> Yes, but that's awfully frequent for a cronjob. Why?
[03:15] <jak2000> my question is, is hard for server check every minute?
[03:16] <jak2000> My question is, is not it very hard for the server to be checking every minute? Does not saturate the server?
[03:16] <nacc> no, once a minute is nothing
[03:16] <nacc> jak2000: what is your *actual* question
[03:18] <jak2000> if saturate the server...
[03:19] <whislock> What is that script doing is a better question.
[03:29] <jak2000> i am try follow: https://stackoverflow.com/questions/5226728/how-to-shutdown-ubuntu-with-exec-php/45775280
[03:29] <jak2000> first answer, i am on a local network
[03:29] <whislock> Doesn't matter, this is a horrible idea.
[03:31] <jak2000> why?
[03:31] <jak2000> i need create a page for restart server, for restar a system, etc.
[03:32] <whislock> It's called SSH. Use it.
[03:32] <jak2000> any better idea?
[03:32]  * whislock sighs.
[03:34] <kzisme> Hi all - recently installed a fresh copy of 16.04 I can login just fine on one machine, but I cannot ping the server when I switch the drive to my other machine (I can login just fine and such)
[03:34] <jak2000> any better idea?
[03:34] <whislock> jak2000: Use SSH. It supports strong authentication.
[03:35] <jak2000> php + ssh?
[03:35] <whislock> ... No. Just SSH.
[03:35] <whislock> Stop trying to use PHP for this.
[03:35] <jak2000> ok...
[03:35] <jak2000> other question
[03:35] <kzisme> On Desktop 1 I can ping/ssh just fine on Desktop 2 I cannot ping it or ssh to it
[03:35] <kzisme> both are on LAN
[03:35] <whislock> Seriously, I wouldn't trust PHP to serve a lunch menu securely, let alone as a gateway for system-level functions.
[03:36] <jak2000> i can program crontab for every sunday at 11pm restart the server. but after restarted i need execute a command how to do?
[03:36] <whislock> Depends on the command and its complexity.
[03:36] <whislock> And what version of Ubuntu you're running.
[03:41] <kzisme> Who me whislock ?  16.04 LTS
[03:45] <whislock> kzisme: No, sorry. Was talking to jak2000.
[03:45] <kzisme> Ah sry
[04:58] <cpaelzer> good morning
[06:12] <lordievader> Good morning
[08:48] <cadogan> Hello, I am trying to solve problem with authentication using kerberos. So we have Firewall on our network which uses kerberos. When I try to do "sudo apt update" i get Err:1 http://XXXXXXX:XXXX/browser_challenge.php?vsys=2&rule=35&url=http://security.ubuntu.com/ubuntu xenial-security InRelease . is there way to authenticate towards kerberos without using browsers challange?
[08:50] <cadogan> I am new to using kerberos, so just pointing to right direction would be helpful :)
[09:12] <jamespage> tobias-urdin: no - its been split out of neutron I think - https://github.com/openstack/neutron-tempest-plugin
[09:12] <jamespage> and no package so no provision via distro for that now
[09:25] <tobias-urdin> jamespage: yeah tried finding a package for it, but there is none in ubuntu?
[09:25] <jamespage> no
[09:25] <tobias-urdin> weird, wonder where i get neutron-lbaas, neutron-vpnaas and neutron-dynamic-routing plugins on ubuntu hm
[09:25] <tobias-urdin> since those depend on the neutron tempest plugin, they fail
[09:27] <jamespage> tobias-urdin: I suspect those install from the parent project still
[09:27] <jamespage> rather than being split out
[09:27] <jamespage> but depend on the now split out neutron-tempest-plugin project
[09:28] <tobias-urdin> hm so pretty much <python package>/neutron_lbaas/tests/tempest something like that which tempest then loads and fails because neutron tempest is not available
[09:29] <jamespage> yup
[09:35] <boritek> hello
[09:36] <boritek> i am trying to commission a dell server in maas but it says no rack controllers can access the BMC node
[09:48] <boritek> i tried to setup an IPMI for that
[09:48] <boritek> the IP address also should be for the BMC there right as well as the power mac
[09:49] <boritek> I do not get why it cannot reach it
[10:02] <boritek> what is the best way to configure a dell power edge 630?
[10:02] <boritek> is it not ipmi?
[10:03] <boritek> i mean the way to configure it for maas
[11:17] <tobias-urdin> jamespage: any plans on packaging the tempest plugins that has been moved out of project repo trees?
[11:17] <jamespage> boritek: the MAAS rack controller must be able to container the IPMI network address for the servers
[11:17] <jamespage> tobias-urdin: tbh no not really
[11:17] <jamespage> tobias-urdin: afaik the puppet modules project is the only group making use of them
[11:17] <jamespage> tobias-urdin: for all of our tempest testing we make use of venvs and install from source
[11:18] <tobias-urdin> jamespage: ok, i will investigate if we can do that way as well for ubuntu atleast
[11:19] <jamespage> tobias-urdin: they got package originally as a side effect of being in=tree for existnig packaged projects
[11:19] <jamespage> it was never really intentional IMHO
[11:20] <tobias-urdin> ok, i c
[11:47] <jamespage> cpaelzer: thanks for the update on that bug
[11:53] <cpaelzer> jamespage: was that what you wanted to ask about?
[11:54] <cpaelzer> I set Friday as a deadline for the upload to make sure I get yours fixed at soem point
[11:54] <cpaelzer> but review of the MP is slow (as it is huge)
[11:54] <cpaelzer> jamespage: let me know if you want to volunteer (someone else) to review the libvirt MP :-)
[12:21] <jamespage> cpaelzer: it was
[12:29] <ahasenack> cpaelzer: does bileto also test if the new packages are installable with dependencies from the archive? Like migration/excuses?
[12:29] <ahasenack> or is it just build + dep8?
[12:36] <mike-zal> I have a serious problem: after adding cache to site and adding it to cloudflare, my systems stop respoding to hosfile, meaning I forward domain to other server (developer version) but browser still opens it from the production server
[12:37] <mike-zal> cache on wordpress shouldn't trigger that effect so I'm leaning toward cloudflare making this issue
[12:38] <mike-zal> any idea how to work around it? using hostfile is a very useful thing when working on a site so without it, my options are limited
[12:40] <ahasenack> rbasak: are you around? Could you please click on the "lander signoff" dropdown menu at https://bileto.ubuntu.com/#/ticket/3351 so bileto can start the dep8 tests for the squid packages from the test ppa?
[12:47] <rbasak> ahasenack: done
[12:47] <ahasenack> thanks
[12:52] <cpaelzer> ahasenack: no installation test
[12:52] <ahasenack> ok
[13:56] <teward> sdeziel: given that your suggestion on #1782226 SEGVs in recent Ubuntu to remove the header from `ss`, and `-H` doesn't exist as a valid flag in older Ubuntu releases such as Xenial, unless you have a way to strip the header out in a way that doesn't provide the requirement of additional dependencies, I'm not sure if there's a way to skip using lsof (I commented with some details about how the current detection works - and it works well)
[13:56] <teward> (or rather, the current detection in that proposed package in that PPA
[13:58] <sdeziel> teward: how about "ss -nto state listening 'sport = 80' | grep -v ^Recv-Q"
[13:58] <teward> that might work
[13:58] <sdeziel> teward: or "ss -nlt 'sport = 80' | grep -v ^State"
[13:59] <teward> both would work for Xenial, and so long as it doesn't output data if the port isn't in use that should be fine
[14:00] <sdeziel> yup, no output when nothing listens
[14:00] <sdeziel> tested on both Xenial and Bionic
[14:01] <teward> indeed.  now let's just hope that `ss` in Cosmic doesn't randomly start segfaulting heh
[14:01] <teward> (I'm also not awake yet, or i'd have tried the greps.  alas i'm still waking up >.>)
[14:02] <sdeziel> the ss segfault was reported to LP: #1787396
[14:02] <sdeziel> I'll check with a cosmic container
[14:03] <teward> the next question is whether we're confident `ss` will always be present in Ubuntu, is there any case where `iproute2` is not installed in an ubuntu system?
[14:08] <sdeziel> teward: I'd add a "Depends: iproute2".
[14:08] <sdeziel> but I think that most install will already have this dep installed as ubuntu-minimal pulls it in
[14:09] <teward> we'd have to do the same for `lsof` if we use that either.  Both ways work, though I just pushed another version to the PPA that uses 'ss', and didn't add the depends yet (oops?  guess ~lp1782226.8 will have the Depends then)
[14:09] <teward> sdeziel: yeah that was my main concern
[14:09] <teward> since there's quite a few people recently posting on Ask Ubuntu using ubuntu-minimal instead of the full server install
[14:09] <teward> so long as the smallest Ubuntu includes `iproute2` that's fine, though I'll add it as a depends before getting this into Cosmic.
[14:10] <sdeziel> great, thanks!
[14:14] <teward> roaksoax: ccing you to ^ since you were also testing.  Assuming this works, then this is a candidate to be added to Cosmic, and then we can work on the SRU bits.  (I'll be glad when people stop filing bugs just because they have something else listening on Port 80 already and try to install NGINX...)
[14:15] <teward> ~lp1782226.8 pushed up to that PPA, now we let it build :P
[14:21] <blackflow> sdeziel: I just replicated with --no-header and a filter with no mathces. eg.    ss --no-header 'dport = 123456'   => segfault
[14:21] <sdeziel> blackflow: thanks, the LP was also confirmed by others (you?)
[14:22] <blackflow> yah
[14:23] <blackflow> kinda makes sense. no header + no output + something_something = segfault
[14:44] <dpb1> rbasak: we are trying to have standup early, can you make it?
[16:45] <ahasenack> kstenerud: so have you cloned a package repo with git ubuntu yet?
[16:49] <kstenerud> test
[16:49] <kstenerud> cool
[16:49] <ahasenack> hi
[16:50] <kstenerud> ok, so I have git ubuntu installed
[16:50] <ahasenack> ok
[16:50] <ahasenack> try cloning a package
[16:50] <ahasenack> git ubuntu clone <sourcepackagename>
[16:50] <ahasenack> postfix, or strongswan
[16:50] <ahasenack> or both
[16:50] <ahasenack> it may prompt you to configure ~/.gitconfig
[16:51] <kstenerud> fatal: could not read Username for 'https://git.launchpad.net': terminal prompts disabled
[16:52] <ahasenack> add a [gitubuntu] section to ~/.gitconfig
[16:52] <ahasenack> here is mine
[16:52] <ahasenack> [gitubuntu]
[16:52] <ahasenack> 	lpuser = ahasenack
[16:52] <kstenerud> already there
[16:52] <kstenerud> 	lpuser = kstenerud
[16:52] <ahasenack> did it download stuff before that message?
[16:52] <kstenerud> yeah
[16:52] <ahasenack> ah, ok, then it's just because you haven't pushed anything yet
[16:52] <nacc> the fatal message is nothing
[16:52] <nacc> well, it's a known issue
[16:53] <nacc> one sec, let me find the bug
[16:53] <nacc> it has no impact
[16:53] <ahasenack> kstenerud: do you also have a [user] section with full name and email?
[16:53] <kstenerud> yup
[16:53] <ahasenack> canonical email?
[16:54] <kstenerud> ah, no it's my gmail account
[16:54] <nacc> LP: #1761821
[16:54] <nacc> the user seciton shouldn't matter to git-ubuntu, fwiw
[16:54] <kstenerud> hmm so that means I'll have to switch accounts in .gitconfig when managing my github stuff?
[16:55] <nacc> sorry, what's the symptom here?
[16:55] <ahasenack> I don't know how that can be controlled
[16:55] <ahasenack> nacc: nothing, I was just going over my ~/.gitconfig
[16:55] <nacc> ahasenack: ah ok :)
[16:55] <ahasenack> to get him started
[16:55] <nacc> no, you don't need per-remote git user
[16:55] <nacc> kstenerud: were you able to clone with git-ubuntu?
[16:56] <kstenerud> yup it did clone
[16:56] <ahasenack> kstenerud: ok, go over this blog post now: https://blog.ubuntu.com/2017/08/09/git-ubuntu-clone
[16:56] <nacc> kstenerud: the only thing i can imagine you running into, which has not much to do with git-ubuntu itself, is who you want to commit as when using the git-ubuntu repositories
[16:56] <nacc> the email should match your lp email
[16:56] <nacc> (afaik, so that lp will do the right linkage)
[16:56] <ahasenack> that sounds important :)
[17:00] <ahasenack> kstenerud: what I would like you to know is the different branches that are available for the packages
[17:00] <ahasenack> kstenerud: i.e., pkg/ubuntu/devel meaning the current ubuntu development package
[17:01] <ahasenack> pkg/ubuntu/xenial-devel being the current xenial package
[17:01] <ahasenack> and so on
[17:01] <ahasenack> and the several tags for package versions, representing each package version as it was imported at that version
[17:01] <kstenerud> there are 233 branches for postfix
[17:02] <kstenerud> under applied
[17:02] <ahasenack> applied means the branch has the patches from debian/patches applied
[17:03] <ahasenack> we tend to work with the ubuntu/ ones, which have the patches unapplied
[17:04] <nacc> kstenerud: each applied/ubuntu branch has the corresponding ubuntu/ branch as an ancestro (it's the result of doing `quilt push` iteratively on the unapplied until no patches are left to apply)
[17:05] <ahasenack> kstenerud: you can ignore applied/ for now
[17:05] <kstenerud> ok
[17:05] <nacc> kstenerud: it's mostly an implementation detail for you :)
[17:06] <ahasenack> kstenerud: so to fix https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1753470, we want to inspect pkg/ubuntu/devel (git-ubuntu should have landed you in ubuntu/devel after the clone)
[17:07] <ahasenack> to see what the fix was
[17:07] <ahasenack> and then we want that fix in bionic, so for bionic you could create a local branch based on pkg/ubuntu/bionic-devel
[17:08] <teward> sdeziel: i just got around to testing the ss-powered packages for that NGINX bug, and it seems to work.  Feel free to test if you want.  I intend to wait until I hear anything bad about it, or confirmation that it works as intended before I start prepping for its inclusion in Cosmic
[17:08] <teward> roaksoax: anything to note about the daemon-only NGINX package as well?
[17:08] <teward> since i'm gearing up to patch things and then push to Cosmic
[17:09] <sdeziel> teward: alright, I'll give it a try and report in the bug
[17:09] <teward> yep no rush
[17:10] <kstenerud> ahasenack: ok so: git checkout -b pkg/ubuntu/bionic-devel remotes/pkg/ubuntu/bionic-devel
[17:10] <ahasenack> I suggest:
[17:10] <teward> sdeziel: because i won't be getting around to pushing it out until, what, Saturday?  (tomorrow's a day filled with busy busy work and meetings, while the rest of today is network maintenance on site here and I'll be busy reconfiguring switches heh)
[17:10] <ahasenack> git checkout -b bionic-postconf-segfault-1753470 pkg/ubuntu/bionic-devel
[17:10] <ahasenack> how you name it is up to you, of course. As a matter of preference, I like to include the ubuntu release, package/issue and bug number
[17:11] <rbasak> I have my ~/.gitconfig configured to personal email, and try to remember to change it to my Canonical email when doing stuff sponsored by Canonical (ie. when I'm "at work")
[17:11] <ahasenack> because I tend to acumulate a lot
[17:11]  * sdeziel is happy to watch the git-ubuntu walk-through!
[17:11] <ahasenack> sdeziel: \o/
[17:12] <ahasenack> kstenerud: git-ubuntu should have set up a default remote of "pkg"
[17:14] <kstenerud> ok I have my local branch
[17:18] <ahasenack> cosmic or bionic?
[17:18] <ahasenack> create both
[17:19] <kstenerud> ok done
[17:19] <ahasenack> switch to the cosmic one, and take a look at git log
[17:19] <ahasenack> I suggest this in ~/.gitconfig
[17:19] <ahasenack> [log]
[17:19] <ahasenack>     decorate = short
[17:21] <sdeziel> no need to have the local cosmic branch. On the bionic branch: git log -p -b pkg/ubuntu/cosmic-devel
[17:21] <ahasenack> works too
[17:21] <sdeziel> this save the branch switching
[17:21] <sdeziel> (just found out about -b)
[17:22] <ahasenack> what is -b for?
[17:22] <nacc> i don't thjink you need -b
[17:22] <nacc> git-log should understand the argument as ref, which the remote-tracking branch is
[17:22] <sdeziel> nacc: you are right
[17:23] <nacc> techincally, you never need to switch branches with git anymore :)
[17:23] <nacc> use working trees and go crazy
[17:23] <kstenerud> nifty!
[17:24] <ahasenack> kstenerud: ok, so the cosmic log
[17:24] <kstenerud> last entry is from git-ubuntu import
[17:24] <sdeziel> -b was not even unneeded, it was wrong as it changes how diffs are displayed
[17:24] <ahasenack> kstenerud: ah, another command for you: rmadison
[17:25] <ahasenack> kstenerud: that will show you the current versions of a package in each release
[17:25] <nacc> sdeziel: yeah, i was looking in the manpage for what it does, as i've never used it :)
[17:25] <ahasenack> kstenerud: anyway, the tip of cosmic, shows the import of 3.3.0-1ubuntu1
[17:25] <ahasenack> and all the accompaining tags
[17:25] <ahasenack> and branches
[17:25] <ahasenack> ag: pkg/import/3.3.0-1ubuntu1, tag: import/3.3.0-1ubuntu1, pkg/ubuntu/devel, pkg/ubuntu/cosmic-proposed, pkg/ubuntu/cosmic-devel, pkg/ubuntu/cosmic, ubuntu/devel
[17:25] <ahasenack> a bit down you will see the previous cosmic package
[17:25] <ahasenack> pkg/import/3.3.0-1,
[17:26] <ahasenack> between the two, two commits from me
[17:26] <ahasenack> one with the fix
[17:26] <ahasenack> another one saying "changelog"
[17:26] <ahasenack> if you do git log -p you will see what was done in each
[17:26] <ahasenack> our standard workflow is to commit a change, then commit the corresponding debian/changelog entry
[17:26] <ahasenack> using the same as the commit message
[17:28] <kstenerud> so in the changelog commit your message is simply "changelog"
[17:28] <ahasenack> right
[17:28] <ahasenack> but the contents, i.e., what was committed, is identical to the change I introduced in the previous commit
[17:29] <ahasenack> we just say "changelog" so they are easily recognized later on when dealing with merges from debian, a topic for another time
[17:29] <ahasenack> I've seen people saying "changelog: <actual change description>"
[17:30] <ahasenack> but don't worry about that now, you will get your preference as time goes by
[17:30] <nacc> it's mostly convention what the commit messages say at this point
[17:30] <ahasenack> kstenerud: how familiar are you with the debian/patches structure?
[17:30] <nacc> there are no hard and fast "requirements"
[17:30] <kstenerud> ahasenack: not at all
[17:31] <ahasenack> kstenerud: ok, so take a look at the debian/patches directory in that branch
[17:31] <ahasenack> you will see one file called "series", and then a bunch of other files
[17:31] <ahasenack> kstenerud: the series file contains a list of patches that will be applied before the binary build starts, and in that order
[17:32] <kstenerud> OK. Is there a reason for the numbering?
[17:32] <ahasenack> convention by some people
[17:32] <ahasenack> it's free-form
[17:32] <nacc> debian is stricter about it than ubuntu, imo
[17:32] <nacc> well, 'stricter' :)
[17:32] <ahasenack> ideally one should follow the established pattern in the package
[17:32] <ahasenack> I don't remember why I didn't do it here
[17:32] <ahasenack> probably because I wanted to avoid a possible future conflict with a patch from debian that started with the same number
[17:33] <nacc> yeah, and it's also less required once it's in Git (at least for this team) IMO
[17:33] <sdeziel> tls_version.diff broke the uniformity before you did
[17:33] <ahasenack> yeah
[17:33] <nacc> heh
[17:33] <ahasenack> and that was added by debian
[17:33] <ahasenack> so meh :)
[17:34] <ahasenack> kstenerud: you should setup quilt, have you heard of that before?
[17:34] <kstenerud> nope
[17:34] <ahasenack> let me fetch you some config files
[17:35] <ahasenack> kstenerud: create these two files in your home: https://pastebin.ubuntu.com/p/bxQr552PGY/
[17:35] <ahasenack> kstenerud: and add this bash alias somewhere: alias dquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg"
[17:36] <ahasenack> (assuming you use bash :)
[17:36] <ahasenack> if you use ksh or something else, you are on your own :)
[17:36] <dpb1> ksh
[17:36] <dpb1> wow
[17:37] <ahasenack> kstenerud: once you have that done, and the alias sources, try "dquilt push -a" and afterwards "dquilt pop -a" inside the package branch directory
[17:37] <ahasenack> push -a means apply all patches, and pop -a means deapply
[17:37] <ahasenack> all of them
[17:37] <ahasenack> you can push up to an individual patch by giving its name
[17:39] <Ussat> ewww.....just had a request to install Mate GUI on a server...
[17:39] <Ussat> I feel all sullied now
[17:39] <ahasenack> Ussat: go over to #ubuntu-desktop :D
[17:39] <ahasenack> j/k :)
[17:39] <kstenerud> Damn that's cool!
[17:40] <Ussat> OH no.....anything but that.........
[17:40] <ahasenack> Ussat: :)
[17:40] <sdeziel> ahasenack: both ~/.quiltrc and ~/.quiltrc-dpkg are identical, expected?
[17:40] <ahasenack> sdeziel: oh man, I set that up so long ago
[17:40] <sdeziel> ahasenack: tabs vs spaces diff only
[17:40] <ahasenack> hah :)
[17:41] <ahasenack> dquilt (the alias) uses the -dpkg one
[17:41] <ahasenack> for raisins
[17:41] <ahasenack> oh well
[17:41] <sdeziel> quilt uses ~/.quiltrc by default
[17:41] <ahasenack> yes
[17:42] <ahasenack> maybe at some point I wanted separate configs, who knows. I don't remember
[17:42] <sdeziel> sorry for nitpicking, just trying to follow
[17:42] <ahasenack> no, it's helpful
[17:42] <ahasenack> keep the picks coming
[17:42] <sdeziel> hehe
[17:42] <ahasenack> kstenerud: how are you doing?
[17:42] <nacc> quilt uses --quiltrc option, then ~/.quiltrc, then /etc/quilt.quiltrc
[17:42] <nacc> (iirc)
[17:42] <kstenerud> I'm taking down notes on all of this so be as pedantic as possible :)
[17:42] <ahasenack> kstenerud: so you can see that d4cb4562480496f8a1b25ddc397cef45dd45d855 then adds the quilt patch, and adds its name to the series file
[17:42] <ahasenack> but does not touch the actual source code from postfix
[17:43] <ahasenack> so we are adding a patch with git
[17:43] <ahasenack> kstenerud: two things about the patch
[17:43] <nacc> actual source code = upstream part of the packaging
[17:43] <ahasenack> kstenerud: a) we want to mention in the commit message which files we are touching
[17:44] <ahasenack> kstenerud: that's why you see the commit message prefixed with debian/patches/fix-postconf-segfault.diff:
[17:44] <ahasenack> (we don't mention d/p/series because that's "obvious")
[17:44] <ahasenack> kstenerud: and b) the patch we added to debian/patches/ has quite the verbose header
[17:45] <ahasenack> kstenerud: we call that header DEP3
[17:45] <ahasenack> kstenerud: there's a whole spec about that
[17:46] <ahasenack> (and I just misplaced the url to it, and google is failing me)
[17:46] <ahasenack> kstenerud: here is a summary: https://pastebin.ubuntu.com/p/X3KnfftthK/
[17:46] <ahasenack> or template, if you will
[17:46] <nacc> https://dep-team.pages.debian.net/deps/dep3/
[17:46] <ahasenack> thanks nacc
[17:46] <nacc> all the DEP are there, iirc
[17:46] <nacc> DEP14 being the other relevant one to g-u
[17:47] <ahasenack> oh, and it's in the header template I pasted even
[17:47] <nacc> yeah, i thought `dpkg-source --commit` added a link :)
[17:47] <ahasenack> you can also use dquilt to add this header: dquilt header -e --dep3 <patchname>
[17:47] <ahasenack> to an existing patch, that is
[17:49] <sdeziel> wow, that's nice ^
[17:49] <ahasenack> kstenerud: we really want all patches we are adding to have a dep3 header, it helps soooo much when doing package maintenance later on
[17:49] <ahasenack> not all existing patches have it, though, but we enforce it for new patches
[17:50] <ahasenack> in our team, that is
[17:52] <ahasenack> kstenerud: with me still? :)
[17:53] <kstenerud> yup :)
[17:53] <sdeziel> ahasenack: is there a tool that you use when merging that uses the "Applied-Upstream" field to know if a given patch should be dropped?
[17:53] <ahasenack> sdeziel: not that I know of
[17:53] <sdeziel> I'm asking cause that specific bug was fixed by upstream in 3.3.1
[17:53] <sdeziel> OK, thanks
[17:54] <ahasenack> it wasn't applied yet when the patch was made
[17:54] <ahasenack> kstenerud: ok, so we need to apply that fix to the bionic version
[17:55] <ahasenack> kstenerud: this might be as easy as cherry-picking the cosmic fix
[17:55] <sdeziel> yeah, was just asking how much manual work was required for merges
[17:55] <nacc> sdeziel: i'd file a bug against git-ubuntu for that feature :)
[17:55]  * sdeziel obliges
[17:55] <ahasenack> kstenerud: now, of course the cherry-pick itself will probably apply
[17:55] <ahasenack> but that doesn't mean the patch might apply in the bionic version
[17:55] <ahasenack> hence cherry-pick, and then try "dquilt push -a" to see if it applies
[17:56] <kstenerud> ok so cherry-pick d4cb45?
[17:56] <ahasenack> kstenerud: you can also run "rmadison postfix" to see which versions of postfix were released into each uuntu release
[17:56] <ahasenack> kstenerud: yep
[17:57] <ahasenack> in this case, bionic has the same major version as cosmic, so it should be fine
[17:57] <sdeziel> nacc: LP: #1787455
[17:58] <kstenerud> ok which branch am I cherry-picking on to?
[17:58] <ahasenack> the bionic one you created before
[17:58] <ahasenack> based on pkg/ubuntu/bionic-devel
[17:58] <ahasenack> pro-tip: compare the version at the top of debian/changelog with what is actually released in bionic
[17:58] <nacc> sdeziel: thx
[17:58] <ahasenack> sometimes the git-ubuntu importer failed and wasn't restarted, and it could be lagging behind
[17:59] <kstenerud> er.. but d4cb45 is already in that branch
[17:59] <ahasenack> nope
[17:59] <ahasenack> are you sure you are not on the cosmic one still
[17:59] <ahasenack> or that you created the bionic branch based on cosmic, instead of bionic?
[17:59] <kstenerud> oh wait wrong branch :P
[18:00] <ahasenack> ah, I use a PS1 change to always have the branch name in my prompt
[18:00] <ahasenack> you may want to do something similar, if you haven't already got something like it
[18:00] <ahasenack> annoying drawback is that the prompt gets confused when typing a long line, because of the colors :/
[18:00] <kstenerud> yeah I have it on one of my machines somewhere.. This is a fresh install
[18:01] <kstenerud> Now at patch fix-postconf-segfault.diff
[18:01] <ahasenack> try applying it with quilt
[18:01] <ahasenack> see if it applies cleanly
[18:01] <kstenerud> yup it did
[18:01] <ahasenack> cool
[18:01] <ahasenack> revert that then
[18:01] <ahasenack> get back to a clean branch
[18:01] <kstenerud> or at least it didn't complain :P
[18:01] <ahasenack> git status should only show .pc
[18:01] <kstenerud> yup
[18:01] <ahasenack> .pc is the control directory for the quilt patches
[18:02] <ahasenack> you can rm -rf it to get a clean state, once you have unapplied all patches
[18:02] <ahasenack> ok, now changelog
[18:02] <ahasenack> sometimes the hardest part, heh
[18:02] <nacc> ahasenack: fwiw, `git clean` can do it as well
[18:02] <nacc> (-fdx, iirc)
[18:02] <ahasenack> nacc: yeah, I do git clean -f -x -d
[18:02] <dpb1> there is a social aspect to the changelog. :)
[18:02] <ahasenack> and a version part
[18:03] <ahasenack> kstenerud: bookmark this, you will refer to it often: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[18:03] <ahasenack> (I do)
[18:03] <ahasenack> specifically, go to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[18:03] <ahasenack> and look at that table of version examples
[18:04] <ahasenack> the version in bionic is 3.3.0-1
[18:04] <ahasenack> the version in cosmic is, as of this moment, 3.3.0-1ubuntu1
[18:04] <nacc> dpb1: definitely, it's a large social engineering project in some sense. It's the 'shared' bit
[18:05] <ahasenack> kstenerud: we need a version that is higher than 3.3.0-1, but lower than 3.3.0-1ubuntu1
[18:05] <dpb1> hehe.
[18:05] <dpb1> it's true
[18:06] <kstenerud> why lower than ubuntu1?
[18:06] <ahasenack> because that is in cosmic already, and we want a release upgrade from bionic to cosmic to upgrade to the cosmic package
[18:06] <ahasenack> instead of leaving the bionic package installed
[18:07] <kstenerud> ok, so ubuntu0.1?
[18:07] <ahasenack> 1ubuntu0.1
[18:07] <kstenerud> Or some other scheme in case we're putting this fix in multiple releases?
[18:07] <ahasenack> the "1" before ubuntu means it's based on debian's -1 release
[18:08] <sdeziel> 1ubuntu<IP_ADDRESS> ?
[18:08] <ahasenack> just 1ubuntu0.1 in this case
[18:08] <ahasenack> but it's a good question whether the bug happens in other releases
[18:09] <ahasenack> that's something that the bug triager should have checked, but you can check too
[18:09] <ahasenack> this is where lxd containers help a lot
[18:09] <kstenerud> so if the bug did trigger in earlier versions as well, would that affect the naming scheme?
[18:09] <ahasenack> or, if you just want to check code, you can checkout the branches for each past ubuntu release
[18:10] <ahasenack> kstenerud: depends on what version is in the other releases
[18:10] <ahasenack> if they all had 3.3.0-1, they perhaps
[18:10] <ahasenack> hence, check "rmadison postfix"
[18:10] <ahasenack> s/they/then/
[18:10] <dpb1> versions are only slightly less hard than the changelog
[18:12] <ahasenack> kstenerud: so we have a version, here is another tip to reconstruct the changelog
[18:13] <ahasenack> kstenerud: following the pattern of using the same text for the commit message and the d/changelog entry, there is a script that can do this for us
[18:13] <ahasenack> part of the git-ubuntu snap
[18:13] <ahasenack> git-ubuntu.reconstruct-changelog
[18:13] <ahasenack> give it a base, and it will populate d/changelog with the commit messages from base to head
[18:13] <ahasenack> in this case, the base could be pkg/ubuntu/bionic-devel for example
[18:13] <ahasenack> just prior to your cherry-pick
[18:14] <ahasenack> it will try to guess the version number to use, and it does that correctly most of the time for uploads to the devel release, but not for SRUs
[18:14] <ahasenack> so you will have to adjust that bit, and the ubuntu release (it will say UNRELEASED by default)
[18:16] <sdeziel> shouldn't "git-ubuntu.reconstruct-changelog" assume the base to be the currently checkout branch if not specified as "$1" ?
[18:16] <nacc> sdeziel: it's never 'wrong' to use the full numeric release, IMO. rbasak and i have gone back and forth on it, as it's not strictly necessary in some cases.
[18:16] <nacc> it won't know what to do if not given an option
[18:16] <nacc> it needs to start somewhere *before* current branch
[18:16] <nacc> and reconstruct d/changelog entries from there to HEAD
[18:17] <sdeziel> nacc: OK, I was trying to find edge cases of using the full numeric release but couldn't
[18:18] <nacc> sdeziel: right, it's the 'safer' option, but isn't necessary in some well-defined case (but using it can break future cases, etc. :)
[18:18] <nacc> err, not using it can break future cases
[18:18] <ahasenack> kstenerud: let me know when you have a d/changelog ready to commit, and commit it
[18:18] <ahasenack> I'll grab some coffee, brb
[18:19] <kstenerud> hmm
[18:19] <kstenerud> karl@karl-tp:~/work/postfix$ git-ubuntu.reconstruct-changelog
[18:19] <kstenerud> karl@karl-tp:~/work/postfix$ git diff
[18:19] <kstenerud> diff --git a/debian/changelog b/debian/changelog
[18:19] <kstenerud> index 6d9e6754..44046d9e 100644
[18:19] <kstenerud> --- a/debian/changelog
[18:19] <kstenerud> +++ b/debian/changelog
[18:19] <kstenerud> @@ -1,3 +1,8 @@
[18:19] <kstenerud> +postfix (3.3.0-1ubuntu1) UNRELEASED; urgency=medium
[18:19] <kstenerud> +
[18:19] <nacc> kstenerud: use a pastebin :)
[18:19] <kstenerud> +
[18:20] <kstenerud> + -- Karl <karl@karl-tp>  Thu, 16 Aug 2018 11:19:05 -0700
[18:20] <powersj> lol
[18:20] <kstenerud> +
[18:20] <powersj> https://paste.ubuntu.com/
[18:20] <dpb1> there is a thing
[18:20] <dpb1> !pastebin | kstenerud
[18:20] <dpb1> there you go!
[18:21] <nacc> and/or | nc termbin.com 9999
[18:21] <sdeziel> nacc: I don't understand why git-ubuntu.reconstruct-changelog could assume the currently checked out branch to be like passing it as $1
[18:21] <kstenerud> https://pastebin.ubuntu.com/p/qnbPByFKpb/
[18:23] <sdeziel> s/could/could not/
[18:24] <sdeziel> kstenerud: git-ubuntu.reconstruct-changelog pkg/ubuntu/bionic-devel
[18:24] <ahasenack> kstenerud: back
[18:24] <nacc> sdeziel: wait, that's not your current branch, that's the branch you are based off of
[18:24] <nacc> sdeziel: sorry, i'm otp right now, so i need more context
[18:25] <nacc> sdeziel: in general, if you're checkout to a branch, `git-ubuntu.reconstruct-changelog <current branhc name>` is a no-op
[18:25] <nacc> as HEAD=<current branch name> and there are no commits betweeen them
[18:25] <ahasenack> kstenerud: you didn't give it a committish where to start
[18:25] <sdeziel> nacc: err, sorry my bad
[18:25] <nacc> sdeziel: does that make sense?
[18:25] <kstenerud> ok so https://pastebin.ubuntu.com/p/Gtgx4QFKFk/
[18:25] <sdeziel> nacc: yes, absolutely, I was not making sense ;)
[18:26] <ahasenack> kstenerud: do git log, and use the commitish just before the cherry pick, or any of its tags
[18:26] <ahasenack> kstenerud: that's better
[18:26] <ahasenack> kstenerud: but you need to fix your email :)
[18:26] <ahasenack> and full name
[18:26] <nacc> sdeziel: we would love to be able to detect it perfect automatically, it's just not easy to always do right
[18:26] <kstenerud> er how do I do that?
[18:27] <ahasenack> kstenerud: your ~/.gitconfig is correct in that regard?
[18:27] <dpb1> DEBEMAIL?
[18:27] <ahasenack> hm, maybe it's using that
[18:27] <ahasenack> yeah
[18:27] <dpb1> and DEBFULLNAME
[18:27] <ahasenack> $ env|grep DEB
[18:27] <ahasenack> DEBFULLNAME=Andreas Hasenack
[18:27] <ahasenack><EMAIL_ADDRESS>[18:27] <ahasenack> I assumed it used ~/.gitconfig
[18:27] <kstenerud> I don't have any DEB envs. .gitconfig has my full name and gmail address
[18:27] <ahasenack> but I also had those vars set
[18:28] <ahasenack> ok, then set those vars in some .bashrc file for later, and now just export them
[18:28] <ahasenack> trash the changes, and run the script again
[18:30] <sdeziel> nacc: how about looking at the branch's ancestor by default then?
[18:31] <sdeziel> that's assuming that one always does `git checkout -b bionic-postconf-segfault-1753470 pkg/ubuntu/bionic-devel` prior to cherry picking
[18:31] <nacc> sdeziel: right, which i think i thought was fragile :)
[18:33] <kstenerud> https://pastebin.ubuntu.com/p/XQFrwPts4m/
[18:33] <sdeziel> nacc: alright. reconstruct-changelog is pretty cool even if we have to provide that commitish arg
[18:34] <dpb1> what about UNRELEASED ahasenack ?
[18:34] <ahasenack> kstenerud: better
[18:34] <ahasenack> kstenerud: now we need to fix the version number, as discussed before, and the ubuntu release, which is what dpb1 just asked about
[18:35] <ahasenack> unreleased should be replaced with "bionic"
[18:35] <nacc> sdeziel: yeah :)
[18:37] <kstenerud> ok so the bionic change, and then 1ubuntu0.1?
[18:37] <ahasenack> yes
[18:37] <kstenerud> https://pastebin.ubuntu.com/p/Dq9bGVgMcr/
[18:38] <ahasenack> +1
[18:38] <ahasenack> one more thing about the changelog entry: the "(LP: #1753470)" string is special
[18:39] <ahasenack> it will auto-close that bug once the package is published to updates
[18:39] <ahasenack> if you open the bug url, you will see it has an open "bionic" task
[18:39] <ahasenack> kstenerud: feel free to assign that task to yourself, and switch "status" to "in progress"
[18:40] <kstenerud> where is the task link?
[18:40] <ahasenack> it's the row that starts with "bionic"
[18:41] <ahasenack> next to each name in each collumn should be a small yellow pencil icon
[18:41] <ahasenack> and the "assigned to" column has the entry "unassigned"
[18:41] <ahasenack> can you click on that pencil, or you don't have it?
[18:41] <ahasenack> might be a permissions problem
[18:41] <kstenerud> ok got it
[18:42] <ahasenack> each one of those rows we call "tasks", because one bug can affect multiple projects
[18:42] <dpb1> specifically, launchpad calls them tasks
[18:42] <kstenerud> ok
[18:43] <dpb1> (and doesn't expose that they are called tasks very well)
[18:43] <dpb1> :)
[18:43] <ahasenack> lots of tricks there
[18:43] <dpb1> tasks, bug tasks
[18:43] <ahasenack> kstenerud: can you change status as well?
[18:44] <kstenerud> to fix committed?
[18:45] <ahasenack> no, to "in progress"
[18:45] <ahasenack> that task, the bionic update, is in progress now, since you are working on it
[18:45] <ahasenack> it's not yet in the archive, nor uploaded, so fix committed or released are incorrect at the moment
[18:46] <ahasenack> ok, so where do we stand
[18:46] <ahasenack> you have a local branch with a proposed fix
[18:46] <ahasenack> you need to test it
[18:46] <ahasenack> there are a few ways to do it
[18:46] <ahasenack> I like two, and it depends on the package
[18:46] <ahasenack> a) build it locally and test
[18:46] <ahasenack> b) build it in a ppa, and then test
[18:47] <ahasenack> it depends if the package takes a while to build, how fast your computer is, etc
[18:47] <ahasenack> we can try both
[18:47] <ahasenack> sometimes ppas are slow, if we are approaching a release, for example
[18:47] <ahasenack> then the builders are busy
[18:47] <ahasenack> let's try a ppa first, to expose you to them
[18:48] <ahasenack> cool?
[18:48] <kstenerud> yup let's do it
[18:48] <ahasenack> ok, so another versioning trick we will need
[18:48] <ahasenack> we are proposing 3.3.0-1ubuntu0.1 for ibonic
[18:48] <ahasenack> bionic
[18:48] <ahasenack> if it works, that's the version that will land in bionic
[18:49] <ahasenack> for the ppa, we will want to use a version that's lower than 3.3.0-1ubuntu0.1, because if somebody installed the package from the ppa, and the release happens, we will want that person to uprade to the official package from the archive
[18:49] <ahasenack> so the trick is to append ~ppaN
[18:49] <ahasenack> for example, 3.3.0-1ubuntu0.1~ppa1
[18:49] <ahasenack> that is higher than the current version of postfix in bionic (3.3.0-1), is lower than the version we want to propose as a fix (3.3.0-1ubuntu0.1)
[18:50] <ahasenack> so go ahead and add ~ppa1 to the verison in d/changelog, and make a simple commit. for example, "git commit debian/changelog -m ppa1"
[18:50] <ahasenack> we need to commit because of the step that comes next
[18:50] <kstenerud> ok so the previous changelog change should be commited before I do this?
[18:50] <ahasenack> but we would not push that to a remote git repo
[18:50] <ahasenack> yes please
[18:50] <ahasenack> kstenerud: let's do it like this then:
[18:50] <kstenerud> with the message "changelog"?
[18:51] <ahasenack> yes
[18:51] <ahasenack> commit that, without the ~ppa1 suffix
[18:51] <ahasenack> then push that to launchpad
[18:51] <ahasenack> and then commit the ppa1
[18:51] <ahasenack> to push, use your launchpad name as a remote
[18:51] <ahasenack> like this
[18:51] <ahasenack> git push kstenerud/<branchname>
[18:51] <ahasenack> (assuming I didn't mispell your name)
[18:51] <ahasenack> sorry
[18:51] <ahasenack> it's git push kstenerud <branch>
[18:52] <dpb1> git ubuntu push?
[18:52] <ahasenack> no, just push
[18:52] <dpb1> and there is a remote called kstenerud?
[18:52] <kstenerud> ok so I'm going to call: git push kstenerud bionic-postconf-segfault-1753470
[18:52] <ahasenack> yes
[18:53] <kstenerud>  * [new branch]        bionic-postconf-segfault-1753470 -> bionic-postconf-segfault-1753470
[18:53] <ahasenack> dpb1: git ubuntu clone set that up beforehand iirc
[18:53] <dpb1> oic
[18:53] <ahasenack> the remote as lp username
[18:53] <ahasenack> kstenerud: cool: http://code.launchpad.net/~kstenerud/+git
[18:54] <ahasenack> kstenerud: now add the ~ppa1 suffix to the version in d/changelog, commit that (but do not push)
[18:55] <kstenerud> +postfix (3.3.0-1ubuntu0.1~ppa1) bionic; urgency=medium
[18:55] <kstenerud> like that?
[18:55] <ahasenack> +1
[18:55] <kstenerud> ok what commit msg should I use?
[18:55] <ahasenack> a dummy one, just so you can keep track yourself
[18:55] <ahasenack> that will never be published
[18:55] <ahasenack> I use -m ppa1
[18:55] <kstenerud> ok done
[18:55] <ahasenack> ok, now we will build a source package that we can upload to a ppa
[18:56] <ahasenack> kstenerud: git-ubuntu has a nice feature that works *most* of the time ;)
[18:56] <ahasenack> kstenerud: git ubuntu build-source
[18:56] <ahasenack> kstenerud: the parameters I would use are:
[18:56] <ahasenack> git ubuntu build-source -v --lxd-image <bionic-lxd-image-name> --sign
[18:56] <ahasenack> -v for verbose, --sign to sign the upload (otherwise the ppa won't accept it)
[18:56] <ahasenack> and --lxd-image needs the name of your ubuntu bionic lxd image
[18:57] <ahasenack> lxc image list and get it from there
[18:57] <ahasenack> can be an alias or fingerprint
[18:57] <ahasenack> build-source needs a clean branch to work, that's why we had to commit the ppa1 change
[18:58] <sdeziel> ahasenack: omitting the --lxd-image arg seems to pick something that worked for me in the past, what's the added benefit of providing it?
[18:58] <ahasenack> sdeziel: it will try to guess the name of the image
[18:58] <ahasenack> I think it assumes the name is the ubuntu release name
[18:58] <ahasenack> my images happen to have a different name
[18:58] <sdeziel> OK
[18:58] <ahasenack> for historical reasons: juju wanted a particular name that was not just "bionic"
[18:59] <dpb1> and you are still doing that?
[18:59] <ahasenack> I type fast
[19:00] <ahasenack> I also have images for debian, centos, etc
[19:00] <ahasenack> so prefixing the names with ubuntu- sounded fine
[19:00] <kstenerud> lxd image or lxc image?
[19:00] <dpb1> ko
[19:00] <ahasenack> kstenerud: "yes" :)
[19:00] <ahasenack> it's all lxd
[19:00] <ahasenack> but the command line is lxc
[19:00] <dpb1> unless you are using 'lxc-command' names
[19:00] <dpb1> that's the *old* lxc
[19:00] <dpb1> you shouldn't use anymore
[19:00] <kstenerud> $ sudo lxd image
[19:00] <kstenerud> EROR[08-16|12:00:39] Failed to start the daemon: LXD is already running
[19:00] <kstenerud> Error: LXD is already running
[19:01] <ahasenack> take it up to management :P
[19:01] <dpb1> (not for this type of work anyway)
[19:01] <ahasenack> it's "lxc image list"
[19:02] <kstenerud> ok so I'll be calling: git ubuntu build-source -v --lxd-image bbb592c417b6 --sign
[19:02] <ahasenack> yes,
[19:02] <ahasenack> but let's check something else first
[19:03] <ahasenack> to not waste time if it fails later
[19:03] <ahasenack> the --sign step
[19:03] <ahasenack> it will call debsign on the resulting .changes file
[19:03] <ahasenack> do you have your gpg key with the same email as DEBEMAIL
[19:03] <ahasenack> ?
[19:04] <kstenerud> umm not sure actually
[19:04] <ahasenack> do a gpg --list-secret-key
[19:04] <kstenerud> it's using my gmail account
[19:05] <ahasenack> you should add another email to it
[19:05] <ahasenack> do a gpg --edit-key <email>
[19:05] <kstenerud> ok
[19:06] <ahasenack> then "adduid" at the prompt
[19:06] <ahasenack> answer the questions
[19:06] <ahasenack> exit with save, when back at the prompt
[19:06] <ahasenack> and push the key to the keyserver again like we did yesterday (gpg --keyserver keyserver.ubuntu.com --send-keys <email>)
[19:07] <kstenerud> which email do I use?
[19:08] <ahasenack> the same as DEBEMAIL
[19:08] <ahasenack> the canonical one
[19:08] <ahasenack> it's how you will sign your source package
[19:08] <kstenerud> gpg<EMAIL_ADDRESS>not a key ID: skipping
[19:08] <ahasenack> is that what you used with adduid?
[19:09] <kstenerud> yeah
[19:09] <ahasenack> does the @canonical email show up in gpg --list-keys now, alongside your gmail one?
[19:09] <kstenerud> [ultimate] (1)  Karl Stenerud<EMAIL_ADDRESS>[19:09] <kstenerud> [ unknown] (2). Karl Stenerud<EMAIL_ADDRESS>[19:09] <ahasenack> use the keyid then
[19:09] <ahasenack> the hex-md5-like string just above that
[19:09] <kstenerud> ok that worked
[19:10] <ahasenack> what is it? let me fetch your key as well
[19:10] <kstenerud> 7C177302572849D84A5048349E9C224744EF2A5A
[19:10] <ahasenack> gpg: key 9E9C224744EF2A5A: public key "Karl Stenerud<EMAIL_ADDRESS>imported
[19:10] <ahasenack> cool, got it
[19:10] <ahasenack> ok
[19:10] <ahasenack> back to the build-source command, go ahead and run it
[19:12] <kstenerud> 08/16/2018 12:11:32 - ERROR:Failed to run apt-get in ephemeral build container (attempt 2/6)
[19:12] <ahasenack> it tries apt-get before the network is up
[19:12] <ahasenack> so it keeps trying
[19:12] <kstenerud> ah ok. Yeah I had to put 5s delays in my containers for that
[19:12] <ahasenack> afaik there is no standard/clean way to determine that from the outside
[19:14] <ahasenack> it will install build tools, then the build dependencies of the package, and then build the source package
[19:14] <ahasenack> and pull the files out of the container and place them in ../
[19:15] <kstenerud> ok, build completed
[19:15] <ahasenack> did it sign it as well? Did you get a prompt for your gpg passphrase?
[19:16] <ahasenack> check the changes file in ../, it should have gpg markers inside it
[19:16] <ahasenack> kstenerud: oh, do you need a break for lunch?
[19:17] <ahasenack> we like to respect local time :)
[19:17] <kstenerud> yeah, but let's get this part done first
[19:17] <kstenerud> I didn't get prompted to sign
[19:17] <ahasenack> but is it signed?
[19:18] <kstenerud> 08/16/2018 12:14:06 - INFO:Signing changes file ../postfix_3.3.0-1ubuntu0.1~ppa1_source.changes
[19:18] <ahasenack> so either it was cached, from a previous usage, or you didn't set a passphrase
[19:18] <ahasenack> you can check later
[19:19] <ahasenack> cat you paste that file please?
[19:19] <kstenerud> Oh I got prompted when I added the new email
[19:19] <ahasenack> ok
[19:19] <ahasenack> so leave that terminal for a moment, you now have to create a ppa in the launchpad gui
[19:19] <ahasenack> go to https://code.launchpad.net/~kstenerud
[19:19] <ahasenack> er
[19:19] <ahasenack> I mean https://launchpad.net/~kstenerud
[19:19] <kstenerud> https://pastebin.ubuntu.com/p/fXV3YtMBjb/
[19:20] <ahasenack> looks good
[19:20] <ahasenack> in that lp page, look for the "personal package archives"
[19:20] <ahasenack> and "create a new ppa"
[19:20] <ahasenack> click on that
[19:20] <kstenerud> ok
[19:21] <ahasenack> first field in the form, url, use a name that will help you later. I suggest "postfix-postconf-segfault-1753470"
[19:21] <ahasenack> or something like that, but at least keep the bug number
[19:21] <ahasenack> it's free form, you may decide you like other naming schemes better, up to you
[19:21] <ahasenack> use the same name in the next field
[19:22] <ahasenack> "display name"
[19:22] <ahasenack> description you can leave empty
[19:22] <ahasenack> then "activate"
[19:22]  * sdeziel wish git-ubuntu could support uploading to a PPA
[19:22] <ahasenack> you can change these later, except the url bit I think
[19:22] <kstenerud> ok done
[19:22] <ahasenack> ok, see it
[19:23] <ahasenack> now let's upload
[19:23] <ahasenack> first, let's configure dput
[19:23] <ahasenack> create this file: https://pastebin.ubuntu.com/p/XMkkRdmYbr/
[19:23] <ahasenack> and leave the unspecified bit there as is
[19:23] <ahasenack> I'll explain it later
[19:24] <kstenerud> ok
[19:24] <ahasenack> now the command:
[19:24] <ahasenack> dput ppa:kstenerud/postfix-postconf-segfault-1753470 ../postfix_3.3.0-1ubuntu0.1~ppa1_source.changes
[19:24] <ahasenack> it's dput <target> <changes-file>
[19:25] <kstenerud> done
[19:25] <ahasenack> you should get an email shortly
[19:25] <ahasenack> telling you if it was accepted or not
[19:26] <ahasenack> looks like it was accepted
[19:26] <ahasenack> https://launchpad.net/~kstenerud/+archive/ubuntu/postfix-postconf-segfault-1753470/+packages is listing your build
[19:27] <kstenerud> yup
[19:28] <ahasenack> ok, wanna have lunch now?
[19:28] <kstenerud> yeah, then we do the local build approach after?
[19:28] <ahasenack> I'll be around for 2h more
[19:28] <ahasenack> yes
[19:28] <kstenerud> ok cool
[19:28] <ahasenack> good job!
[19:29] <kstenerud> I'll get it eventually :P
[19:29] <ahasenack> ping when ready to continue
[20:44] <kstenerud> ahasenack: ready when you are
[20:44] <ahasenack> ok
[20:44] <ahasenack> kstenerud: the local way,
[20:44] <ahasenack> kstenerud: the command is simimlar
[20:44] <ahasenack> git ubuntu build -v --lxd-image <image>
[20:44] <ahasenack> no --sign needed, and it's build instead of build-source
[20:45] <ahasenack> it will do the same, create a container, but this time build the binaries
[20:45] <ahasenack> and pull them out, and then shutdown the container it use
[20:45] <ahasenack> used
[20:50] <kstenerud> ok built
[20:50] <ahasenack> next step would be to test it
[20:51] <ahasenack> you should bring up a cosmic container,
[20:51] <ahasenack> install the normal cosmic version, reproduce the bug
[20:51] <ahasenack> then install the updated package, confirm the bug is gone
[20:52] <ahasenack> it also helps to write down the steps you take, because you will need them later on when preparing the bug for the update. It needs test steps;
[20:53] <ahasenack> you can install the updated version from these binaries you just build, or the ppa that we used previously
[20:53] <ahasenack> the ppa is always good to have, because at some point you will submit this change for review, and it helps reviewers if there is a ppa already with the fix, so they don't have to build it themselves
[20:53] <kstenerud> ok so I'm in the cosmic container
[20:55] <sdeziel> s/cosmic/bionic/ ^ ?
[20:55] <keithzg> Welll great, those hardware lockups on the internal-facing ethernet adapter that I was experiencing on the router at work are happening again now.
[20:56] <ahasenack> sorry, bionic
[20:56] <ahasenack> sdeziel: thanks
[20:56] <kstenerud> ok hang on
[20:57] <kstenerud> ok so first off just apt install postfix?
[20:57] <dpb1> keithzg: hrm
[20:57] <ahasenack> yeah
[20:57] <ahasenack> that will get you the one that is currently the latest in bionic, and has the bu
[20:57] <ahasenack> bug*
[20:57] <dpb1> keithzg: can  you remove the hardware and see if the lock ups persist?  or is it not that kind of equipment
[20:59] <keithzg> dpb1: Alas it's a built-in adapter (two, in fact, although the external-facing built-in NIC on the motherboard isn't showing any issues)
[21:00] <kstenerud> hmm I'm not getting a crash when I call postconf virtual_alias_map
[21:00] <ahasenack> it has to be as a user who cannot read the map file
[21:01] <keithzg> Hrmm wait, I bet the patched and recompiled network driver got overwritten by the latest kernel update!
[21:01] <ahasenack> and it has to be a db map
[21:02] <kstenerud> ok how do I set up a db map?
[21:02] <ahasenack> I think there is an example in the bug
[21:02] <kstenerud> what I get is /usr/sbin/postconf: fatal: open /etc/postfix/main.cf: No such file or directory
[21:03] <ahasenack> add this to /etc/postfix/main.cf (the file should exist already):
[21:03] <ahasenack> virtual_alias_maps = pgsql:/etc/postfix/valiases.cf
[21:03] <ahasenack> then greate /etc/postfix/valiases.cf with any content
[21:03] <ahasenack> and chmod 0600 /etc/postfix/valiases.cf
[21:03] <ahasenack> then run postconf as a non-root user
[21:03] <ahasenack> that would be one way to trigger the bug
[21:03] <ahasenack> that was comment #8 in the bug, more or less
[21:03] <ahasenack> and comment #9
[21:06] <kstenerud> ah ok got the crash
[21:07] <ahasenack> now leave config files as they are, add the ppa, and dist-upgrade to the new packages you prepared
[21:07] <ahasenack> https://launchpad.net/~kstenerud/+archive/ubuntu/postfix-postconf-segfault-1753470/ has instructions on how to add the ppa
[21:08] <ahasenack> basically sudo add-apt-repository ppa:kstenerud/postfix-postconf-segfault-1753470
[21:09] <kstenerud> then apt upgrade?
[21:09] <ahasenack> yes
[21:09] <ahasenack> sometimes dist-upgrade, shouldn't make a difference in this case
[21:09] <ahasenack> you may get other updates, not coming from the ppa
[21:09] <ahasenack> as good practice I always dist-upgrade the container right after it started
[21:10] <kstenerud> ok the fix works :)
[21:10] <ahasenack> nice
[21:11] <ahasenack> I guess now we can make a merge proposal
[21:11] <ahasenack> and tomorrow we can run the dep8 tests, since postfix has some in debian/tests
[21:11] <kstenerud> so if I weren't using the ppa, is it still possible to test?
[21:11] <ahasenack> this test you just made?
[21:12] <kstenerud> yeah. We pulled from ppa this time
[21:12] <ahasenack> yes, you would copy the ../*.deb files that were produced by git ubuntu build previously
[21:12] <ahasenack> into the test container
[21:12] <ahasenack> there you would then just "sudo dpkg -i *.deb"
[21:12] <ahasenack> or, instead of *.deb, check which postfix pcakages you have, and dpkg -i just those
[21:12] <kstenerud> ok, but it didn't produce a .deb file. only a tar.xz file
[21:12] <nacc> did you build or build-source?
[21:12] <ahasenack> that was the build-source one
[21:12] <ahasenack> didn't you run "build" before, without the --sign?
[21:13] <ahasenack> that produces debs
[21:13] <kstenerud> yeah that's what I did
[21:13] <ahasenack> if that worked, the parent dir (../) should have deb files
[21:13] <kstenerud> oh wait no
[21:13] <kstenerud> I did builld-source :P
[21:13] <ahasenack> you repeated the previous one?
[21:13] <kstenerud> So when signing, I use build-source, and when building locally I use build?
[21:13] <ahasenack> the signing is about uploading to the ppa
[21:14] <ahasenack> the remote server only accepts signed uploads
[21:14] <ahasenack> it's the authentication
[21:14] <kstenerud> So the original I did was:
[21:14] <kstenerud> git ubuntu build-source -v --lxd-image bbb592c417b6 --sign
[21:14] <ahasenack> only you can upload packages to that ppa
[21:14] <ahasenack> and ppas only take source uploads
[21:14] <kstenerud> ok
[21:14] <ahasenack> that builds the source, signs it, and you can upload that to a ppa, or even to the ubuntu archive once you have upload permission
[21:14] <kstenerud> and then for just building the deb locally, I use:
[21:14] <ahasenack> the same command with just "build" instead of build-source will produce binary debs
[21:14] <kstenerud> git ubuntu build -v --lxd-image bbb592c417b6
[21:15] <ahasenack> which can also be signed, but won't matter in this case
[21:15] <ahasenack> since you won't upload binary deps anywhere
[21:15] <ahasenack> correct
[21:17] <kstenerud> ok, so next a merge proposal?
[21:17] <ahasenack> yes
[21:17] <ahasenack> go to the launchpad url for your branch
[21:17] <ahasenack> https://code.launchpad.net/~kstenerud/+git lists all your git repositories
[21:18] <ahasenack> click your way through until you are viewing your branch
[21:18] <kstenerud> ok
[21:18] <ahasenack> are you there?
[21:18] <kstenerud> yup
[21:19] <ahasenack> you should have landed at https://code.launchpad.net/~kstenerud/ubuntu/+source/postfix/+git/postfix/+ref/bionic-postconf-segfault-1753470
[21:19] <ahasenack> right?
[21:19] <kstenerud> yup. I see the commit msgs
[21:19] <keithzg> Hmm. If reinstalling the patched kernel module works, then that definitely implies that that was *previously* working, which is odd since initially when I installed that, the problem persisted for a few hours after a reboot, so I was just assuming it hadn't helped.
[21:19] <ahasenack> ok, click on "propose for merge"
[21:19] <kstenerud> ok
[21:19] <ahasenack> kstenerud: target repository should be correct already
[21:20] <ahasenack>  lp:ubuntu/+source/postfix
[21:20] <kstenerud> yup
[21:20] <ahasenack> kstenerud: target branch now, we have to fill in
[21:20] <ahasenack> kstenerud: since this is for a bionic update, the branch is ubuntu/bionic-devel
[21:20] <ahasenack> that's where you branched from even
[21:21] <ahasenack> kstenerud: commit message leave empty
[21:21]  * keithzg wonders what's up with the Intel e1000e driver then, particularly considering the long silence in https://sourceforge.net/p/e1000/bugs/_discuss/thread/9048ab8e/
[21:21] <ahasenack> kstenerud: description you have to fill in (we will get back to this)
[21:21] <ahasenack> kstenerud: for reviewer, type canonical-server
[21:22] <ahasenack> kstenerud: good so far? Then lets get back to the description. We will also add a second reviewer later on
[21:22] <kstenerud> ok
[21:22] <ahasenack> kstenerud: ok, in the description, which is free form, you basically say what you did
[21:23] <ahasenack> kstenerud: you should mention that you grabbed the fix that is in cosmic already,
[21:23] <ahasenack> kstenerud: also that you tested it and how, so others can try repeating your testing steps
[21:23] <ahasenack> kstenerud: also mention the ppa that has test packages built
[21:24] <ahasenack> kstenerud: you can also say you will run dep8 tests still. You can start reading up on that today if you still have time, but we will get to that tomorrow
[21:24] <ahasenack> it needs a bit of infra setup on your machine
[21:25] <ahasenack> then click "propose merge" at the bottom
[21:25] <ahasenack> this description text you can change after proposing, that's fine
[21:26] <kstenerud> OK so something like this?
[21:26] <kstenerud> https://pastebin.ubuntu.com/p/7zFNP4NFG9/
[21:27] <ahasenack> kstenerud: the test user won't exist by default, will, it?
[21:27] <ahasenack> I suggest to use ubuntu, which is the default user
[21:27] <kstenerud> no, there's a "useradd test" command
[21:28] <kstenerud> oh ok
[21:28] <ahasenack> ah, I missed that
[21:28] <ahasenack> ok
[21:28] <ahasenack> yeah, that's fine
[21:29] <kstenerud> OK, so putting that in the description field
[21:30] <ahasenack> yes
[21:30] <kstenerud> then propose?
[21:30] <ahasenack> yes
[21:30] <kstenerud> https://code.launchpad.net/~kstenerud/ubuntu/+source/postfix/+git/postfix/+merge/353267
[21:30] <ahasenack> nice
[21:30] <ahasenack> now add another reviewr
[21:30] <ahasenack> reviewer
[21:30] <ahasenack> there are three options
[21:30] <ahasenack> depending on what type of package it is
[21:31] <ahasenack> if it's a universe package, the reviewer is canonical-server-motu-reviewers
[21:31] <ahasenack> if it's a server package, then we use canonical-server-packageset-reviewers
[21:31] <ahasenack> the rest, which is core/main, we use canonical-server-core-reviewers
[21:31] <ahasenack> postfix is in main, so that leaves motu out
[21:31] <ahasenack> (you can see with rmadison postfix, or apt-cache policy postfix)
[21:32] <ahasenack> to see if it's core or server-packageset, I use "ubuntu-upload-permission -a postfix"
[21:32] <ahasenack> that will list who can upload postifx
[21:32] <ahasenack> it only lists core
[21:32] <ahasenack> so the extra reviewer slot is canonical-server-core-reviewers
[21:32] <ahasenack> hopefully this will be automatic someday
[21:32] <ahasenack> but we are not there yet
[21:35] <kstenerud> ok so how do I add an extra reviewer?
[21:35] <ahasenack> you should see a button/link just below the existing reviewer
[21:36] <kstenerud> All I see is "claim review"
[21:36] <ahasenack> "request another review" on the right?
[21:36] <ahasenack> green link
[21:36] <kstenerud> ah ok
[21:37] <kstenerud> done
[21:37] <ahasenack> good
[21:37] <ahasenack> the mp part is done
[21:37] <ahasenack> bookmark this link: https://code.launchpad.net/~canonical-server/+activereviews
[21:37] <ahasenack> that shows all reviews
[21:37] <ahasenack> or rather, all mps
[21:38] <ahasenack> now we need to touch the bug again, since this is an update for a stable release (bionic)
[21:38] <ahasenack> kstenerud: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
[21:38] <ahasenack> the bug description needs to be filled out with that information
[21:39] <kstenerud> ok
[21:39] <ahasenack> what I do is edit the bug description (click on the pencil icon), write "[Original Description]" at the very top, so that the existing description is below it,
[21:39] <ahasenack> and paste the template above it all
[21:39] <ahasenack> so you will have something like
[21:39] <ahasenack> sru template
[21:39] <ahasenack> [original descrption]
[21:39] <ahasenack> (here goes on what the original description was)
[21:40] <ahasenack> and then you have to really fill out that template. Think about how this is affecting users
[21:40] <ahasenack> how the fix was done
[21:40] <ahasenack> why the fix is safe (committed upstream?)
[21:40] <ahasenack> add testing steps (in this case, omit the ppa, bceause if the sru is accepted, your package will be uploaded to a special proposed pocket). Just assume people know how to get it
[21:41] <ahasenack> that page with the sru template has links to existing sru bugs where you can see some examples
[21:41] <ahasenack> https://bugs.launchpad.net/bugs/1583324 is a recent one I worked on
[21:42] <ahasenack> kstenerud: ah, and if you go back to the postfix bug, you'll see your branch and merge proposal attached to it: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1753470
[21:42] <ahasenack> that's because of the special (LP: #xxxx) in the changelog entry
[21:44] <ahasenack> kstenerud: I have to go now, shoot me an email if you have any questions, and we will continue tomorrow
[21:44] <kstenerud> ok sounds good. Thanks! Lots to digest here :)
[21:44] <ahasenack> cheers :)
[22:59] <keithzg> Well I just spent a long long time trying to get systemd ethernet renaming to work, I swear that's how I have things currently named "external0" and "internal0", but changing the entries in /etc/systemd/network doesn't change anything, and I can't find where else I could have set those . . .
[23:00] <sarnold> the usual place is /etc/udev/rules.d/70-persistent-net.rules
[23:02] <keithzg> sarnold: Yeah that's the classic, udev (rather than systemd) place, but I have no files there at all.
[23:02] <sarnold> oh. hrm.
[23:02] <keithzg> Like, the entire /etc/udev/rules.d directory is empty.
[23:06] <keithzg> This all was to try to make the spare PCIe adapter I've shoved in now be "internal0" so that I wouldn't have to change anything else, but I eventually gave up and just changed the /etc/network/interfaces and iptables rules to refer to "enp1s0" (the autogenerated name for the PCIe NIC) instead. Which has generally worked, although somehow OpenVPN clients seeing our internal network now, which is . . . bad :(
[23:08] <keithzg> (And that also doesn't make sense really, since the OpenVPN conf only specifies routing rules, not specific adapters, although maybe I need to re-do the tun bridge? Yeah that's probably it.)
[23:09] <keithzg> (Hmm no, that's just created by the OpenVPN service. Hrmmm.)
[23:10] <sdeziel> tun bridge is a weird combo ... tap+bridge maybe?
[23:12] <keithzg> sdeziel: I think I was just mistakenly presuming it was a bridge, since that would explain why changing adapters would break it. But it's definitely tun0 that's being brought up and theoretically used by OpenVPN.
[23:13] <sdeziel> keithzg: gotcha
[23:17] <keithzg> I wonder if this is the problem: "Thu Aug 16 17:16:00 2018 us=759598 /sbin/ip route del <IP_ADDRESS>/24 | RTNETLINK answers: Operation not permitted | Thu Aug 16 17:16:00 2018 us=760404 ERROR: Linux route delete command failed: external program exited with error status: 2"
[23:17] <sdeziel> keithzg: usually harmless
[23:18] <sdeziel> keithzg: that's openvpn trying to cleanup something that's cleaned automatically afterwards anyways
[23:18] <keithzg> sdeziel: Fair enough, although *something* is making the VPN entirely fail to work, and with multiple people who work only remotely this is a problem I really gotta figure out!
[23:21] <sdeziel> keithzg: could you pastebin the journalctl output of the openvpn service?
[23:23] <keithzg> sdeziel: Oh that's not gonna help any, haha, it just says "Starting OpenVPN service..." whenever I start it and "Stopped OpenVPN service." "Started OpenVPN service." when I stop it ;) I'll grab an excerpt of the actual log though . . .
[23:23] <sdeziel> keithzg: would that be "journalctl -u openvpn" by any chance?
[23:24] <sdeziel> keithzg: the real deal is in "journalctl -u openvpn@$INSTANCE" where instance is /etc/openvpn/$INSTANCE.conf
[23:27] <keithzg> sdeziel: That's true, but the config file is just openvpn.conf and `journalctl -u openvpn@openvpn only differs in that it gives some errors from last week when the troubles that led me to now changing physical adapters started. Nothing other than logging the starting and stopping today.
[23:27] <sdeziel> keithzg: maybe you have a very low "verb" param in that conf
[23:27] <keithzg> However, it //is// logged to a file and here's the output from the most recent start of the service and while some clients connected and failed to get anything: https://paste.kde.org/pwd9kfb5y
[23:28] <keithzg> (As of this moment no more has been written to the log)
[23:30] <sdeziel> keithzg: do you have IP forwarding enabled?
[23:30] <sdeziel> keithzg: now that your internal0 NIC is named differently, have you updated your firewall FORWARD rules?
[23:30] <sdeziel> (if you use -i/-o in those rules)
[23:31] <keithzg> sdeziel: Yes, I changed the iptables rules accordingly. To be clear, the internal0 NIC is still named the same (mysteriously), I changed the rules and the /etc/network/interfaces entry to refer to enp1s0 rather than internal0.
[23:32] <sdeziel> keithzg: OK, cause that android client seems to have successfully connected
[23:32] <keithzg> sdeziel: Indeed, the clients seem to connect successfully, but now cannot access anything on our internal network.
[23:33] <sdeziel> keithzg: have you tried tcpdump'ing while the client tries to connect to the internal net?
[23:39] <keithzg> sdeziel: Hmm. Well, `tcpdump -i tun0` doesn't show much, https://paste.kde.org/p9n8wz4wu
[23:41] <keithzg> And I do see stuff like "17:38:43.586600 IP <IP_ADDRESS> > boots: ICMP echo request, id 13, seq 3, length 64" when dumping enp1s0
[23:42] <keithzg> So in theory the ping requests are being forwarded, although they (and any other form of traffic) certainly don't seem to be making it back to the clients.
[23:42] <sdeziel> keithzg: try with tcpdump -ni any icmp
[23:42] <sdeziel> err: tcpdump -nei any icmp
[23:44] <sdeziel> keithzg: do you mind sharing iptables-save?
[23:47] <sdeziel> keithzg: I have to go, sorry. Good luck though!
[23:47] <keithzg> sdeziel: https://paste.kde.org/pbt8yxxyo is the ICMP dump
[23:47] <keithzg> sdeziel: Fair enough, thanks for the help!
[23:49] <sdeziel> keithzg: looks like systemd-resolved is not running but that's not related ;)
[23:49] <sdeziel> keithzg: I'd check on <IP_ADDRESS> and see if you get the ICMP packets
[23:50] <sdeziel> keithzg: if you do get them, check how it tries to respond to them with "ip route get <IP_ADDRESS>". It should send packets toward the VPN server
[23:50] <keithzg> sdeziel: Yeah on the receiving end I'm seeing "17:50:18.190642  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 128: <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92"
[23:51] <keithzg> (`ip route get` returns the adapter I'd expect it to be using to reply)
[23:51] <sdeziel> keithzg: the interesting part of ip route get is the gateway/via used
[23:52] <keithzg> sdeziel: Hrmm, it doesn't say anything more than "<IP_ADDRESS> dev br0  src <IP_ADDRESS>" and then "cache" on the next line.
[23:53] <sdeziel> keithzg: hmm, that's wrong
[23:54] <sdeziel> it means it thinks that <IP_ADDRESS> is in the same LAN as the VPN client
[23:54] <sdeziel> but they are not as you have a router (the VPN server) between the 2
[23:55] <keithzg> sdeziel: Hmm? <IP_ADDRESS> *is* the VPN client, though?
[23:56]  * keithzg is very tempted to just try the udev method for adapter renaming and hope that magically fixes everything, heh
[23:56] <sdeziel> keithzg: <IP_ADDRESS> thinks that <IP_ADDRESS> is in the same LAN
[23:56] <sdeziel> keithzg: didn't you say the NIC was renamed somehow though?
[23:56] <keithzg> sdeziel: Yeah I suppose that's not true, although they *do* have the same gateway.
[23:58] <sdeziel> keithzg: please pastebin: "cat /etc/network/interfaces; ip link; ip ro; iptables-save" from the VPN server
[23:58] <keithzg> sdeziel: The exact situation is, the internal adapter is called "internal0" . . . somehow. I know that was me, but the only settings I have for that are in /etc/systemd/network, and changing those and rebooting changes nothing. The 'internal0' adapter is experiencing hardware lockups, so I put in a PCIe adapter to use instead.
[23:59] <keithzg> sdeziel: Here ya go, from our router (which is also the VPN server): https://paste.kde.org/pi4tooz7a