=== Aztec03 is now known as SmokinClucks
=== SmokinClucks is now known as Aztec03
=== ShriHari is now known as altmount
[04:39] <altmount> I oppose!
[04:40] <Randolf> altmount:  What do you oppose?
=== ShriHari is now known as altmount
=== altmount is now known as ArseToasts
=== ShriHari is now known as Chuchuttta
[06:06] <cpaelzer> good morning
[06:17] <Randolf> Good morning cpaelzer.
[06:22] <cpaelzer> hi Randolf, good mornign to you as well
=== ShriHari is now known as altamount
=== altamount is now known as zzarr
[06:53] <lordievader> Good morning
[07:16] <Randolf> Good morning lordievader.
[07:16] <lordievader> Hey Randolf
[07:17] <lordievader> How are you doing?
[07:17] <Randolf> Good.  How are you?
[07:17] <lordievader> Doing good here :)
[10:36] <rbasak> cpaelzer: may I have your opinion please, as my potential future memcached MP reviewer?
[10:36] <rbasak> Upstream landed https://github.com/memcached/memcached/pull/285 in a "bugfix" update.
[10:37] <rbasak> Which is really for RHEL. It disables some systemd sandboxing features as RHEL's systemd doesn't support it.
[10:37] <rbasak> It does so by prefixing '##safer##' to certain lines.
[10:37] <rbasak> The RPM .spec is updated to sed them out again if the systemd is new enough.
[10:37] <rbasak> In our case, systemd is always new enough.
[10:38] <rbasak> But if I pull the new upstream and do nothing, the systemd service unit regresses by disabling this sandboxing.
[10:38] <rbasak> IMHO, it is inappropriate for upstream to ship the lowest common denominator by default.
[10:38] <rbasak> Older RHEL should patch out the lines it can't support or something. So I intend to file an issue about it.
[10:38] <rbasak> In the meantime, how should I package this in Debian?
[10:39] <rbasak> sedding them out again in debian/rules works just fine, and is reasonably future proof if upstream keeps to the same pattern.
[10:39] <rbasak> Or I could add a more rigid quilt patch.
[10:39] <rbasak> Opinion?
[10:40] <cpaelzer> rbasak: start reading ...
[10:45] <cpaelzer> rbasak: as you already said sedding as well as a patch works
[10:45] <cpaelzer> rbasak: I'm somewhat afraid that sed'ding might enable/disable random bits in the future
[10:46] <cpaelzer> I also think upstream does that the wrong way
[10:51] <rbasak> cpaelzer: so you'd prefer I add a quilt patch for now, rather than sed?
[10:58] <cpaelzer> rbasak: sort of yes, quilt + a check if there are more ##safer##
[10:58] <cpaelzer> rbasak: the check could break build
[10:58] <cpaelzer> rbasak: maybe even check count of ##safer## and if != the expected amount the packager has to check them one by one if it is ok to disable
[10:59] <cpaelzer> this could still fail if they add one and remove one upstream but you see where I'm heading to
[10:59] <cpaelzer> some sort of safety what we enable/disable with the sedding
[11:00] <cpaelzer> if at least they would have taken safer-<systemdversion> or something
[11:00] <cpaelzer> then the decision would again be where it belongs (upstream)
[11:00] <cpaelzer> but they didn't
[11:08] <rbasak> cpaelzer: perhaps a quilt patch for now, and a dep8 test to verify that ##safer## doesn't appear in the shipped service unit file?
[11:09] <rbasak> That should cover your mutate-but-count-is-same case.
[11:11] <cpaelzer> rbasak: yes
[11:11] <cpaelzer> rbasak: but dep8 is needlessly late for this
[11:12] <cpaelzer> rbasak: why not a d/rules entry that checks
[11:12] <cpaelzer> so people would realize it mcuh earlier, probably also before it is in some -proposed
[11:13] <rbasak> cpaelzer: good point. Easy enough to do in override_dh_auto_install.
[11:14]  * rbasak has filed https://github.com/memcached/memcached/issues/359
[11:19]  * rbasak has filed https://bugs.launchpad.net/memcached/+bug/1755460
[11:19] <ubottu> Launchpad bug 1755460 in memcached (Ubuntu) "memcached.service is less secure by default" [Medium,Triaged]
[11:58] <frickler> looks like memcached maintainers are proud of the current publicity and want to make sure they can keep riding that wave? :-/
[11:59] <rbasak> frickler: huh?
[12:10] <frickler> https://blogs.akamai.com/2018/03/memcached-fueled-13-tbps-attacks.html
[12:28] <rbasak> Oh. That's something quite separate. I said "secure" in my bug summary, but it's really a different (and lower) order of magnitude of "secure" than the amplification vulnerability.
[12:29] <ahasenack> hi,
[12:29] <ahasenack> how would I go about updating a package version in ubuntu's git with a new upstream (not from debian) tarball?
[12:30] <ahasenack> non-git workflow is essentially uupdate on the new tarball
[12:30] <ahasenack> (the one I know of)
[12:30] <rbasak> I happen to have just done this for memcached (MP not up yet).
[12:30] <rbasak> I used uscan/uupdate, and then hacked things around to gitify it again.
[12:30] <rbasak> Then added one commit that changed upstream sources only (not committing the debian/changelog change made by uupdate).
[12:30] <ahasenack> git status followed by git add/remove as needed?
[12:31] <rbasak> uupdate puts everything in a different directory so I had to bring it all back, including any dotfiles (there were none in my case).
[12:31] <ahasenack> right
[12:31] <ahasenack> feels a bit error prone
[12:31] <rbasak> So a bunch of hackery done by hand, but the end result being that there's a single git commit that pulls in the new upstream but doesn't touch debian/
[12:32] <ahasenack> how does debian do it in their git, do you know?
[12:32] <ahasenack> same thing?
[12:32] <rbasak> This could be automated in the future by git ubuntu uupdate or something, but that's not implemented.
[12:32] <rbasak> gbp has some functionality to do something similar
[12:32] <rbasak> gbp import-orig
[12:32] <rbasak> Maintains a separate upstream branch
[12:32] <rbasak> gbp updates that and then merges upstream into master (and there's a --no-merge flag)
[12:32] <rbasak> That's the common gbp workflow
[12:33] <rbasak> ahasenack: in terms of error-proneness, you can gain some confidence when dpkg-buildpackage doesn't complain. As if it's a 3.0 (quilt) package, then everything apart from debian/ must exactly match the orig tarball, and the orig tarball isn't hacked with.
[12:34] <ahasenack> true, I got such errors in other occasions
[12:57] <cpaelzer> ahasenack: FYI this was a uupdate for example https://git.launchpad.net/~paelzer/ubuntu/+source/iproute2/log/?h=bionic-merge-4.14.1
[12:57] <cpaelzer> going ahead of Debian
[12:58] <ahasenack> I'll take a look, thanks
[14:33] <smoser> rbasak: do you recall the bug where you were asking to change cloud-init to manage_etc_hosts : true ?
[14:34] <rbasak> Yes. Do you want the number? :)
[14:34] <rbasak> smoser: https://bugs.launchpad.net/cloud-init/+bug/1741277
[14:34] <ubottu> Launchpad bug 1741277 in cloud-init (Ubuntu) "Not all platforms running cloud-init end up with the system hostname resolveable by default" [Undecided,Confirmed]
[14:37] <smoser> thanks
[16:04] <nacc> rbasak: when using a fixture with pytest.mark.parametrize, do i need to pass the fixture as a parametrized thing each time? or will pytest dtrt?
[16:05] <nacc> fixture *and* mark.parameterize
[16:05] <rbasak> I think you just add the fixtures to the def line
[16:05] <rbasak> I can't remember whether at the end or the start.
[16:06] <rbasak> But one of those should work I think.
[16:06] <nacc> rbasak: ok, i'll test to figure it out (that's what i wasn't sure of either)
[16:09] <rbasak> nacc, ahasenack: I just created https://code.launchpad.net/~racb/ubuntu/+source/memcached/+git/memcached/+merge/341340. Process question: is it a problem that usd-import-team isn't in the list of reviewers?
[16:10] <rbasak> This happened because I added the first reviewer from the MP creation page.
[16:10] <Odd_Bloke> rbasak: nacc: Adding them anywhere in the parameters should DTRT.
[16:10] <nacc> Odd_Bloke: thanks!
[16:10] <nacc> rbasak: process-wise, no, except that only usd-import-team can create the upload tag
[16:20] <nacc> rbasak: had another test question for you, if you have a moment (HO would be preferred, but I can do IRC)
[16:20] <rbasak> HO is fine. Two minutes. Standup HO?
[16:20] <nacc> rbasak: thanks
[16:53] <ahasenack> rbasak: mp is fine
[16:53] <ahasenack> wrt your question
[17:07] <ahasenack> rbasak: hm, question
[17:07] <ahasenack> rbasak: debian repacks samba's tarball
[17:07] <ahasenack> samba_4.7.4+dfsg.orig.tar.gz
[17:08] <ahasenack> upstream is like https://download.samba.org/pub/samba/stable/samba-4.7.6.tar.gz
[17:08] <ahasenack> how do I know what was changed in that +dfsg repacking? untar it and compare?
[17:13] <ahasenack> rbasak: my connection dropped, not sure you saw my dfsg question above?
[17:16] <nacc> ahasenack: gbp.conf (see debian/README.source)
[17:16] <nacc> ahasenack: (debian/gbp.conf)
[17:18] <ahasenack> I see
[17:19] <ahasenack> nacc: the filter setting in [import-orig] should be enough?
[17:20] <ahasenack> I have
[17:20] <ahasenack>   'source4/heimdal/lib/wind/rfc*txt',
[17:20] <ahasenack>   'source4/ldap_server/devdocs',
[17:20] <ahasenack>   '*chm',
[17:20] <nacc> ahasenack: based upon debian/README.source, that's what ends up munging the orig
[17:20] <ahasenack> ok
[17:28] <nacc> rbasak: i need to drop
[17:28] <rbasak> nacc: sorry, back now. That too longer than expected :(
[17:39] <nacc> rbasak: np
[17:39] <nacc> rbasak: i think your pad does write it up correctly now
[17:40] <nacc> rbasak: or, at least, mostly -- do you want to take that up next, then?
[17:40] <rbasak> nacc: yeah I guess I need to :)
[17:41] <nacc> rbasak: thanks; i'll hold off on the new tests for a bit
[17:44] <ahasenack> nacc: rbasak: could one of you please feed samba to the importer? Debian just released a new package: https://launchpad.net/debian/+source/samba/2:4.7.4+dfsg-2
[17:44] <ahasenack> it's not yet in https://code.launchpad.net/~usd-import-team/ubuntu/+source/samba/+git/samba
[17:44] <nacc> ahasenack: keep-up has not yet started
[17:44] <nacc> ahasenack: once the reimport is done (i just kicked off the remainder)
[17:44] <ahasenack> what is keep-up?
[17:44] <nacc> the normal import script that keeps up with the publisher
[17:44] <ahasenack> ok
[17:45] <ahasenack> it's a daily cron?
[17:45] <ahasenack> or a long-running daemon?
[17:45] <nacc> the latter
[17:45] <ahasenack> which you stopped because of the reimport, right?
[17:45] <nacc> right
[17:45] <ahasenack> ok, thanks
[17:45] <nacc> no publish in the last ~8 days is guaranteed to have been imported
[17:45] <ahasenack> ETA sometime today?
[17:45] <nacc> yeah
[17:45] <nacc> at least, well, to start it
[17:46] <ahasenack> ok
[17:46] <nacc> it will probably take a while to catch all the way up
[17:46] <ahasenack> ah, it's been stopped for all this time
[17:46] <ahasenack> not just since saturday?
[17:46] <nacc> since a week ago saturday, or so
[17:46] <nacc> march 5
[17:46] <ahasenack> ok
[17:46] <nacc> when i started the reimport
[17:56] <ahasenack> nacc: if we go ahead of debian in some package, does git-ubuntu merge work with that package afterwards? Let's say debian updates the version too
[17:56] <ahasenack> I saw there is a -f option to force a merge, would that do it correctly?
[17:56] <ahasenack> s/would/should/
[17:56] <nacc> ahasenack: i expect git-ubuntu merge to be pretty broken right now
[17:56] <nacc> ahasenack: due to the bug you reported
[17:57] <nacc> it needs updating for the new import algorithm
[17:57] <ahasenack> ok
[17:57] <nacc> ahasenack: you can manually tag the old, new bits and just do the rebase yourself
[17:57] <nacc> that's really all git-ubuntu merge is doing
[17:57] <ahasenack> I was just wondering about that case where we would be ahead
[17:58] <ahasenack> since the normal merge is normally with debian being ahead of us instead
[17:58] <nacc> ahasenack: wait, we're ahead of debian and still are?
[17:58] <ahasenack> in this hypothetical case, yes
[17:59] <ahasenack> the "merge" would be to just grab debian/* changes from them in that case
[18:00] <nacc> that's not an ubuntu merge then :)
[18:00] <ahasenack> correct
[18:00] <nacc> ahasenack: so, no, it wouldn't work, as git-ubuntu-merge is for ubuntu merges
[18:00] <ahasenack> "Are you sure you want to merge? (Pass -f to force the merge)." <-- was wondering what would happen with -f here
[18:00] <nacc> you'd get a weird delta that you don't really want to merge?
[18:01] <ahasenack> in other words, going ahead of debian also makes getting future changes from them harder
[18:01] <nacc> ahasenack: well, you'd cherry-pick them
[18:01] <nacc> ahasenack: you wouldn't merge to them
[18:01] <ahasenack> right, it's another process
[18:02] <nacc> right
[18:02] <nacc> i don't think it's harder, though
[18:02] <nacc> it's easier, if anything
[18:02] <ahasenack> harder because debian uploads are just one big commit
[18:02] <ahasenack> you would have to take it apart before cherry picking
[18:02] <ahasenack> or just grab what you want and apply, without cherry picking a specific commit
[18:03] <ahasenack> taking it apart is part of the merge workflow already
[18:03] <nacc> ahasenack: did you see if it's their VCS?
[18:03] <nacc> *in their
[18:03] <nacc> we don't ever take apart debian uploads, fwiw
[18:04] <ahasenack> it's there, yes
[18:04] <ahasenack> I'm just considering pros and cons of going ahead of them
[18:04] <ahasenack> and yes, we take apart our changes only, not theirs, my mistake
[18:05] <nacc> mostly because if you really carea bout that level of granularity, check the debian vcs and use that
[18:12] <hallyn> ruh roh - bionic: apt build-dep libvirt:
[18:12] <hallyn> The following packages have unmet dependencies: builddeps:libvirt : Depends: libcgmanager-dev but it is not installable
[18:12] <MitchT> Hello all.
[18:12] <hallyn> cpaelzer: ^
[18:13] <hallyn> we're inf eature freeze only so i guess i coudl push a fix for this,
[18:13] <hallyn> i assume noone else is doing a libvirt update since, well, we're in feature freeze
[18:14] <MitchT> I hope this is a decent place to ask, but has anyone attempted to deploy an azure vm using 18.04 beta?  As of March8th, all daily images are unable to deploy.  I figured it was azure. I opened a ticket and after escalation, their team confirmed that all images from March 8th+ are 'broken'
[18:14] <hallyn> kirkland: ^
[18:14] <hallyn> kirkland: who handles azure vms these days?
[18:14] <nacc> Odd_Bloke: --^ ?
[18:14] <hallyn> gonna guess not utlelmming utlemming :)
[18:15] <hallyn> meh
[18:15] <hallyn> my control keys why dey no work
[18:15]  * MitchT posts the list of what works and what doesn't https://hastebin.com/icuzavoner.css
[18:15] <hallyn> hm, but in my other vm i don't have that failed dependency,
[18:16] <Odd_Bloke> nacc: Thanks!
[18:16] <Odd_Bloke> MitchT: o/ I'm a person you can talk to about that; how are you deploying them?
[18:16] <hallyn> backports?
[18:17] <MitchT> I'm deploying using a template
[18:17] <hallyn> oh!  haha - do-release-upgrade failed me.  it did not update the release name in deb-src lines
[18:17] <nacc> hallyn: wouldn't expect backports to matter for bionic :)
[18:17] <nacc> hallyn: ah...
[18:17] <hallyn> nacc: yeah this is worse :)
[18:17] <hallyn> thanks
[18:17] <hallyn> cpaelzer: ignore me
[18:17] <MitchT> the template hasn't changed since early feb. it took me a few days to track down that if i specify that last version i have marked "OK" it will deploy.
[18:20] <MitchT> @Odd_Bloke I've found that the problem is exactly what i've described. I'm honestly out of ideas. I'm glad freenode is still around. I should know linux guys would be on IRC
[18:23] <Odd_Bloke> MitchT: OK, I can reproduce the issue, I'll dig in to it a bit more.  Thanks for reporting it here!
[18:24] <Odd_Bloke> MitchT: Could I also ask you to file a cloud-images bug at https://bugs.launchpad.net/cloud-images/+filebug, please?
[18:24] <MitchT> My IT department sits in awe at the level of support from the ubuntu team
[18:24] <MitchT> i will file a bug.
[18:36] <MitchT> Bug filed.  I hope this is helpful.   I can provide more details if needed, but its pretty straightforward. https://bugs.launchpad.net/cloud-images/+bug/1755565
[18:36] <ubottu> Launchpad bug 1755565 in cloud-images "Unable to deploy azure template with Ubuntu18.04 Daily image past March 8th" [Undecided,New]
=== jelly is now known as MooServ`
=== MooServ` is now known as jelly
[19:35] <ahasenack> hm, I have a question regarding dfsg orig tarballs
[19:35] <ahasenack> let's say I produce one
[19:36] <ahasenack> using the same exclusion rules as debian
[19:36] <ahasenack> build the ubuntu package, upload to the ubuntu archive, all is well
[19:36] <ahasenack> then debian catches up, produces the dfsg tarball too
[19:36] <ahasenack> but for some silly reason, it has a different md5
[19:36] <ahasenack> it's the same content, but different md5 because of, say, different compression level
[19:37] <ahasenack> won't that break things on our side? Because it will be the same filename, same tarball version and so on, but with a different md5 (but same content)
[20:02] <rbasak> ahasenack: yeah, that can happen. It's annoying, but sometimes unavoidable.
=== mikal_ is now known as mikal
=== strive is now known as par4g0n
=== beatzz_ is now known as beatzz
[22:24] <nacc> ahasenack: yeah, that's something the importer catches (and why we import origs separately for debian & ubuntu)
[22:24] <nacc> ahasenack: but it *really* should be avoided if at all possible