| === Aztec03 is now known as SmokinClucks | ||
| === SmokinClucks is now known as Aztec03 | ||
| === ShriHari is now known as altmount | ||
| altmount | I oppose! | 04:39 |
|---|---|---|
| Randolf | altmount: What do you oppose? | 04:40 |
| === ShriHari is now known as altmount | ||
| === altmount is now known as ArseToasts | ||
| === ShriHari is now known as Chuchuttta | ||
| cpaelzer | good morning | 06:06 |
| Randolf | Good morning cpaelzer. | 06:17 |
| cpaelzer | hi Randolf, good mornign to you as well | 06:22 |
| === ShriHari is now known as altamount | ||
| === altamount is now known as zzarr | ||
| lordievader | Good morning | 06:53 |
| Randolf | Good morning lordievader. | 07:16 |
| lordievader | Hey Randolf | 07:16 |
| lordievader | How are you doing? | 07:17 |
| Randolf | Good. How are you? | 07:17 |
| lordievader | Doing good here :) | 07:17 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| cpaelzer | rbasak: start reading ... | 10:40 |
| 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:45 |
| cpaelzer | I also think upstream does that the wrong way | 10:46 |
| rbasak | cpaelzer: so you'd prefer I add a quilt patch for now, rather than sed? | 10:51 |
| 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:58 |
| 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 | 10:59 |
| 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:00 |
| 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:08 |
| rbasak | That should cover your mutate-but-count-is-same case. | 11:09 |
| cpaelzer | rbasak: yes | 11:11 |
| cpaelzer | rbasak: but dep8 is needlessly late for this | 11:11 |
| 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:12 |
| rbasak | cpaelzer: good point. Easy enough to do in override_dh_auto_install. | 11:13 |
| * rbasak has filed https://github.com/memcached/memcached/issues/359 | 11:14 | |
| * 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:19 |
| frickler | looks like memcached maintainers are proud of the current publicity and want to make sure they can keep riding that wave? :-/ | 11:58 |
| rbasak | frickler: huh? | 11:59 |
| frickler | https://blogs.akamai.com/2018/03/memcached-fueled-13-tbps-attacks.html | 12:10 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| ahasenack | true, I got such errors in other occasions | 12:34 |
| 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:57 |
| ahasenack | I'll take a look, thanks | 12:58 |
| smoser | rbasak: do you recall the bug where you were asking to change cloud-init to manage_etc_hosts : true ? | 14:33 |
| 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:34 |
| smoser | thanks | 14:37 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:09 |
| 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:10 |
| 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:20 |
| ahasenack | rbasak: mp is fine | 16:53 |
| ahasenack | wrt your question | 16:53 |
| 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:07 |
| 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:08 |
| ahasenack | rbasak: my connection dropped, not sure you saw my dfsg question above? | 17:13 |
| nacc | ahasenack: gbp.conf (see debian/README.source) | 17:16 |
| nacc | ahasenack: (debian/gbp.conf) | 17:16 |
| ahasenack | I see | 17:18 |
| ahasenack | nacc: the filter setting in [import-orig] should be enough? | 17:19 |
| 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:20 |
| nacc | rbasak: i need to drop | 17:28 |
| rbasak | nacc: sorry, back now. That too longer than expected :( | 17:28 |
| nacc | rbasak: np | 17:39 |
| nacc | rbasak: i think your pad does write it up correctly now | 17:39 |
| 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:40 |
| nacc | rbasak: thanks; i'll hold off on the new tests for a bit | 17:41 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:56 |
| 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:57 |
| 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:58 |
| ahasenack | the "merge" would be to just grab debian/* changes from them in that case | 17:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| nacc | mostly because if you really carea bout that level of granularity, check the debian vcs and use that | 18:05 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:20 |
| Odd_Bloke | MitchT: OK, I can reproduce the issue, I'll dig in to it a bit more. Thanks for reporting it here! | 18:23 |
| 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:24 |
| 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] | 18:36 |
| === jelly is now known as MooServ` | ||
| === MooServ` is now known as jelly | ||
| ahasenack | hm, I have a question regarding dfsg orig tarballs | 19:35 |
| ahasenack | let's say I produce one | 19:35 |
| 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:36 |
| 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) | 19:37 |
| rbasak | ahasenack: yeah, that can happen. It's annoying, but sometimes unavoidable. | 20:02 |
| === mikal_ is now known as mikal | ||
| === strive is now known as par4g0n | ||
| === beatzz_ is now known as beatzz | ||
| 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 | 22:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!