=== boshhead_ is now known as boshhead
=== markthomas_ is now known as markthomas
=== beatzz_ is now known as elsheepo
=== RoyK^ is now known as RoyK
[07:27] <lordievader> Good morning
=== m1dnight1 is now known as m1dnight_
=== Seveas_ is now known as Seveas
[10:19] <frickler> coreycb: sorry, I was away yesterday. I have no feedback yet regarding new releases, I'm going to try to ask in the next meeting
[11:45] <kstenerud> I'm a bit confused as to when to squash commits for a merge
[11:45] <kstenerud> I have the following commit pairs that need to be squashed:
[11:45] <kstenerud>     Fix DKIM signing in 2.11.0 (LP: #1770532)
[11:45] <kstenerud>     d/p/patches/105_amavisd_fix_originating_dkim_signing.patch: correctly reference related Debian bug
[11:45] <kstenerud> and
[11:45] <ubottu> Launchpad bug 1770532 in amavisd-new (Debian) "DKIM signing not working in bionic" [Unknown,Confirmed] https://launchpad.net/bugs/1770532
[11:45] <kstenerud>     Fix Debian/Ubuntu pathing in amavisd-release (LP: #1792293)
[11:45] <kstenerud>     d/p/patches/100_more_amavisd_helpers_fixes: correctly reference related Debian bug
[11:45] <ubottu> Launchpad bug 1792293 in amavisd-new (Ubuntu Cosmic) "amavisd-release use wrong socketname" [Undecided,Fix released] https://launchpad.net/bugs/1792293
[11:46] <kstenerud> Also, the second pair need to be dropped since 100_more_amavisd_helpers_fixes has been fixed upstream
[11:46] <kstenerud> So my question is: At what point in the merge process do I do the squashes?
[11:51] <ahasenack> logical
[11:51] <ahasenack> we want the logical to be, what's the word,
[11:51] <ahasenack> ...
[11:51] <ahasenack> in https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
[11:52] <ahasenack> search for step "5. git rebase -i old/debian"
[11:52] <ahasenack> that's the logical step
[11:53] <ahasenack> the particular step that talks about consolidating the delta is
[11:53] <ahasenack> "An additional goal in this step is to consolidate the delta, e.g. sometimes a change is added in one Ubuntu release and then removed in a subsequent Ubuntu release. The changes, in this case, should simply be dropped.
[11:53] <ahasenack> "
[11:53] <ahasenack> the example it gives is about a change being added and then dropped, so net result is zero
[11:53] <ahasenack> the case above is a small fixup for a patch
[11:53] <ahasenack> which also doesn't make sense to keep as a separate part of the logical
[11:54] <ahasenack> "logical" represents the ubuntu delta that was added on top of the debian package
[11:54] <ahasenack> note the logical tag has a version, so it means the ubuntu delta at that version
[11:55] <ahasenack> the last step in the merge process it to apply the delta to the new debian package (new/debian tag)
[11:55] <ahasenack> that's when the delta can change, due to several reasons
[11:55] <ahasenack> patch already applied (so drop it), patch doesn't apply (needs refreshing), etc
=== Luke is now known as bitnomial
=== bitnomial is now known as Luke
[22:34] <arooni> without doing a lot of setup/learning; is there a *high* level server performance app i can run alongside htop for a given server? (ubuntu 16.04)
[22:35] <arooni> would tell me high level metrics for server performance / hard drive space etc/
[23:00] <sarnold> arooni: when I'm curious about a system I normally check /proc/cpuinfo ; free -g ; and df -h
[23:05] <tomreyn> arooni: maybe netdata / prometheus is roughly what you're thinking of, but "high level" could mean a lot of things.