| nacc | rbasak: fyi, i found an interetsing case with `usd merge reconstruct` -- the reconstruct commits (and the ones between old/debian and it) are not reproducible (at least not for the sha). I guess it's obvious, because the committer is the one doing the cherry-pick at the time of the cherry-pick; but do we want to make the tooling workaround that (retaining the original commit information, e.g.?) | 00:15 |
|---|---|---|
| rbasak | nacc: kexec-tools> ah. It's nice to not have to do that now! | 00:20 |
| rbasak | Perhaps less of a problem then? | 00:20 |
| rbasak | nacc: not reproducible> I can't think of where that might be an issue, since those commits will not end up in the history that others actually use. Only short-lived branches. Is there any case you can think where that won't happen? | 00:22 |
| rbasak | nacc: I don't see any reason to object to them _not_ being made reproducible, but I also don't see why it would be worth the effort | 00:22 |
| rbasak | nacc: interesting observation though! | 00:23 |
| nacc | rbasak: yeah, the importer will handle it correctly -- it actually produces the same merge as you did, but it doesn't know (currently) how to handle us doing the merge and not it (as it finds a current debian/changelog but no import commit) | 00:24 |
| nacc | rbasak: it will spit a warning now | 00:24 |
| nacc | *error | 00:24 |
| nacc | rbasak: yeah, i'm not sure either, was just thinking about it as i considered two people doing the merge at the same time | 00:24 |
| rbasak | My linting doesn't actually check the intermediate reconstruct branches, only the final one I think. | 00:25 |
| rbasak | But I think that's OK. | 00:25 |
| nacc | rbasak: yeah it doesn't matter, as once we push up to the repository the tagged upload/ it's no longer reconstructed; also that tag is really just a helper | 00:32 |
| nacc | cpaelzer: ok, i just pushe a ton of changes up to master for the merge subtool | 00:32 |
| nacc | i think that fixes your bug | 00:32 |
| pdeee | RAOF, https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978 | 00:43 |
| ubottu | Launchpad bug 1640978 in python-letsencrypt (Ubuntu) "letsencrypt 0.4.1 contains numerous bugs fixed upstream" [Undecided,New] | 00:43 |
| pdeee | ^ hlieberman | 00:53 |
| rbasak | pdeee: interesting. Do you work for certbot upstream? | 01:16 |
| rbasak | RAOF, pdeee: I'd also be happy to help out. Please ping if needed. | 01:18 |
| pdeee | rbasak, yes | 01:27 |
| rbasak | pdeee: good job with the SRU paperwork there! It might be worth making it really clear exactly what behaviour changes you believe will and won't affect your proposed update to 16.04 - that's particularly important. | 01:33 |
| rbasak | I guess that depends a little on the packaging that presumably isn't ready yet? Eg. aliases wrt. letsencrypt vs. certbot, etc. | 01:34 |
| pdeee | aliases etc are handled in debian's 0.9.3 packages | 01:35 |
| pdeee | since they had the same transition | 01:35 |
| pdeee | the only things I could maybe see for Xenial would be: | 01:36 |
| pdeee | - a changelog entry pointing at the SRU paperwork | 01:36 |
| pdeee | - if people want it, a more prominent dselect question about the renewal cron job | 01:36 |
| pdeee | sorry s/dselect/debconf/ | 01:36 |
| rbasak | From an SRU review perspective, what I most want spelled out the exact list of any behaviour changes you expect Xenial users to receive, and your confirmation that you don't believe that there are any other changes. | 01:38 |
| rbasak | Your word as upstream carries a great deal of weight on this. | 01:38 |
| rbasak | What you've written is great and sound like it covers most of this already - it's just a clear summary of what the final upload to Xenial will do is what I feel is missing - though of course I know you haven't finalised that yet. | 01:40 |
| nacc | rbasak: if you have some time, could you do a `usd clone php7.0; cd php7.0; usd merge tag ubuntu/devel; usd merge reconstruct ubuntu/devel`? I'm getting a source change mismatch between reconstruct and old/ubuntu, but only from pygit2. `git` itself isn't showing me any differences and oddly `git-blame` and `vi` are showing me differnt file contents (a $Id$ substitution) | 01:41 |
| rbasak | nacc: note that php7.0 ships (or at least used to ship) a .gitignore file, which messes things up annoyingly. Could that be an issue here? | 01:43 |
| rbasak | And those $Id$ style substitutions are pesky too. | 01:43 |
| rbasak | Unfortunately git didn't seem to have a global option to ignore .gitignore the last time I looked. | 01:43 |
| rbasak | nacc: usage: usd [-h] [import|buildpackage] ... | 01:45 |
| nacc | rbasak: pull master | 01:45 |
| nacc | rbasak: you're about a day of date :) | 01:45 |
| rbasak | Oh I'm sorry. I did pull but I had a detached head. | 01:46 |
| nacc | oh there's also a .gitattributes | 01:46 |
| nacc | that's what's doing it | 01:46 |
| nacc | bah, so frustrating :/ | 01:47 |
| rbasak | git needs a "I'm external to the project; ignore that stuff" mode :-/ | 01:47 |
| nacc | yeah | 01:47 |
| nacc | i believe this is actaully covered somewhere int he manual -- how to repackage upstreams that use git | 01:47 |
| nacc | i will need to look tmrw | 01:47 |
| rbasak | Last time I sent a patch to the git project I got bikeshedded :-/ | 01:47 |
| rbasak | (about a test no less; not even the bugfix) | 01:47 |
| nacc | it seems like they should put this in .git/info/attributes in the php7.0 repo | 01:48 |
| nacc | rather than in the source dir | 01:48 |
| rbasak | That depends on whether they want cloners to automatically inherit all that or not. | 01:48 |
| nacc | well they do now by virtue of it being in the path | 01:48 |
| rbasak | If they want everyone to have it active, then that's what .gitattributes/.gitignore is for | 01:48 |
| nacc | oh you're saying if a user had a separate attributes setting already? | 01:48 |
| nacc | hrm | 01:48 |
| rbasak | No I mean that if they put it in .git/info/attributes then everyone who clones it needs to set it up separately | 01:49 |
| nacc | rbasak: not acc'g to the gitattributes manpage | 01:49 |
| nacc | rbasak: git uses that first | 01:49 |
| rbasak | I don't think you follow me. | 01:49 |
| nacc | i dunno, not a big deal right now | 01:50 |
| rbasak | If they want to do a thing project wide, automatically, for everyone who clones, then they can't put that in .git/info/attributes because others won't pick that up when they clone. | 01:50 |
| nacc | oh i see what you mean | 01:50 |
| nacc | rbasak: i'm not sure how to avoid .gitattributes in an upstream like this, though; istr talking about this a while back, for a case you hit as well | 02:01 |
| nacc | rbasak: ah crlf issues, maybe | 02:03 |
| nacc | rbasak: bouncycastle? | 02:03 |
| nacc | rbasak: at the time, you did a "echo '* -text' > git/info/attributes" I think | 02:05 |
| rbasak | nacc: ah yes. That was to override the default IIRC, rather than a .gitattributes file. | 02:11 |
| rbasak | nacc: IMHO, git should have options to disable everything from inside .git/. If it doesn't we should see if we can get that in upstream. | 02:12 |
| nacc | rbasak: so i think this might just be a bug in `usd merge` -- i think i have a workaround for php at least | 02:12 |
| nacc | but it is something we should look into | 02:12 |
| rbasak | When I did it by hand I ended up committing a removal of .gitattributes and .gitignore from the tree. Painful. | 02:12 |
| nacc | rbasak: ack, not a great solution :) | 02:13 |
| nacc | rbasak: ok, pushed something up that lets me proceed, at least | 02:13 |
| nacc | rbasak: i'm off the evening, thanks! | 02:13 |
| pdeee | rbasak, I replied on the ticket | 03:08 |
| pdeee | in short, we don't believe there should be any workflows that have changed | 03:09 |
| pdeee | there are lots of new flags that and options that are supported | 03:12 |
| cpaelzer | nacc: thanks for the fixes, I'll let you know next time I hit it | 07:12 |
| pitti | Good morning | 07:22 |
| cpaelzer | good morning pitti | 07:44 |
| highvoltage | LocutusOfBorg: no problem at all! | 08:28 |
| pitti | rbasak: iptraf got removed in Debian in favor of iptraf-ng (Debian bug #842355); iptraf is seeded on ubuntu-server daily; do we want to follow suit? | 08:28 |
| ubottu | Debian bug 842355 in ftp.debian.org "RM: iptraf -- ROM; obsoleted by iptraf-ng" [Normal,Open] http://bugs.debian.org/842355 | 08:28 |
| rbasak | pdeee: thanks! | 10:02 |
| rbasak | kirkland, jgrimm: opinion on pitti's question above please? | 10:10 |
| rbasak | Sounds like a yes to me? | 10:10 |
| LocutusOfBorg | highvoltage, kpmcore sponsored | 10:32 |
| LocutusOfBorg | but the symbols are really sad | 10:32 |
| === hikiko is now known as hikiko|ln | ||
| doko | xnox: what is your plan with openssl 1.1? | 12:55 |
| xnox | doko, stay on 1.0 until debian transitions 500 more packages. | 13:05 |
| xnox | doko, then revisit with mdslaur. | 13:05 |
| xnox | doko, at the moment he does not want to maintain cves for two series. or worse two series in a single release. | 13:05 |
| cjwatson | openssh ain't moving off 1.0 for a while yet | 13:05 |
| cjwatson | to name but one | 13:06 |
| xnox | somehow i expect it to drag on forever. | 13:06 |
| Son_Goku | xnox: have you seen this? https://github.com/patch-exchange/openssl-1.1-transition | 13:06 |
| cjwatson | and yes, I'm aware of the patch sent upstream for openssh, but I consider it irresponsible to apply a ~4000 patch with lots of delicate crypto code that isn't yet upstream | 13:07 |
| Son_Goku | Fedora and OpenMandriva guys are collaborating on the openssl-1.1 transition, and maybe you guys could help pitch in for it | 13:07 |
| cjwatson | wouldn't surprise me if a similar thing applied to some other packages | 13:08 |
| cjwatson | s/~4000 patch/~4000-line patch/ | 13:09 |
| xnox | Son_Goku, my advice is for those who are interested in openssl 1.1 contribute to debian, and similar efforts in porting. Longer term I do see it as a necessory transition, but in my mind that's 18.04 LTS not necessarily 17.04 | 13:10 |
| xnox | no objections on the intentions; just the timing; and how the timing makes sense for ubuntu. | 13:11 |
| Son_Goku | xnox, I don't disagree, but I figured I'd make you aware of the patch-exchange for it | 13:11 |
| Son_Goku | you can let your friends in Debian know about it, so that we don't keep duplicating work over and over | 13:12 |
| rbasak | Son_Goku: https://github.com/patch-exchange looks interesting. Someone should mention this on the cross-distro list. | 13:18 |
| Son_Goku | what cross-distro list? | 13:19 |
| rbasak | (what is the cross-distro list, you ask?) | 13:19 |
| rbasak | :-) | 13:19 |
| rbasak | I can make the same point about the patch-exchange :-P | 13:19 |
| rbasak | https://lists.linaro.org/mailman/listinfo/cross-distro | 13:19 |
| Son_Goku | wait, isn't that just for ARM things? | 13:19 |
| rbasak | I don't believe so. | 13:19 |
| rbasak | It just started up because there was a need in that area. | 13:19 |
| * Son_Goku shrugs | 13:19 | |
| Son_Goku | I've seen that list before, but I've only seen ARM things talked about there | 13:20 |
| pitti | realistically, such a list isn't going to happen or be useful | 13:20 |
| pitti | IMHO, for any such porting there should be an upstream bug/issue/whatever where people interested in that project (like distro maintainers) are subscribed | 13:20 |
| pitti | that at least makes it N:1 instead of N:M (which is too intangible) | 13:20 |
| rbasak | pitti: sure, but in addition to that, it's useful to have a general forum for wider issues. I wouldn't expect individual patches to be discussed on such a list, but wide reaching issues would be relevant. | 13:21 |
| Son_Goku | at least in the case of patches, I don't know how it is between Debian and other distros, but at least in my experience in Fedora, Mageia, and openSUSE, we do a lot of patch sharing | 13:21 |
| Son_Goku | so it made sense to set up the patch-exchange | 13:21 |
| rbasak | Indeed. I wasn't aware of a forum before, but it is quite common for Debian/Ubuntu to look at the other distros and grab their patches. I assumed they did the same with us. And patch-exchange certainly does look useful. | 13:22 |
| rbasak | But someone needs to announce them to the distros! | 13:22 |
| rbasak | Or announce _it_, at least. | 13:22 |
| Son_Goku | rbasak, half the time, I have no idea where to find patches for stuff in Debian | 13:22 |
| rbasak | sources.debian.net. | 13:23 |
| rbasak | For modern packages, always inside debian/patches. | 13:23 |
| pitti | https://patches.ubuntu.com/ too | 13:23 |
| Son_Goku | the crappy part is when it's 2.0 or 1.0 split format | 13:23 |
| cjwatson | Son_Goku: Debian developers manage to work it out for other distros :) | 13:23 |
| Son_Goku | which means diff.gz | 13:23 |
| cjwatson | Son_Goku: that's increasingly rare nowadays | 13:23 |
| Son_Goku | Mir is released that way, for example | 13:23 |
| cjwatson | Sure, you can always come up with examples | 13:24 |
| cjwatson | But statistically | 13:24 |
| Son_Goku | it's less common now, thankfully | 13:24 |
| Son_Goku | but it still pops up enough to be annoying | 13:24 |
| rbasak | You should file a bug against mir and ask them to move to 3.0 (quilt). I'm surprised about that one. | 13:25 |
| Son_Goku | 1.0/3.0 native and 3.0 quilt formats are my favorite | 13:25 |
| Son_Goku | everything in the middle sucks | 13:25 |
| cjwatson | https://upsilon.cc/~zack/stuff/dpkg-v3/ graph seems to be broken but it has the numbers at least | 13:26 |
| cjwatson | that's for Debian rather than Ubuntu | 13:26 |
| cjwatson | as for mir, they don't have any patches at the packaging level anyway, so while it would be nice if they used 3.0 (quilt) on general principles, it wouldn't make any difference at all to finding patches | 13:27 |
| cjwatson | the way it's released very nearly enforces landing upstream first | 13:27 |
| === hikiko|ln is now known as hikiko | ||
| Son_Goku | rbasak: filed: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1641121 | 13:28 |
| ubottu | Launchpad bug 1641121 in mir (Ubuntu) "Switch packaging to "3.0 (quilt)"" [Undecided,New] | 13:28 |
| Son_Goku | cjwatson, yes, but it's the principle of the thing | 13:28 |
| Son_Goku | and how the heck am I supposed to know until I do dpkg-source foo? | 13:29 |
| rbasak | Son_Goku: thanks. I'd add that the point is to make it simple for people to easily confirm there aren't any patches, which is just as useful as being able to find any. | 13:29 |
| rbasak | Right :) | 13:29 |
| cjwatson | I guess it doesn't seem particularly harder to me than having to track down and extract a source RPM ... | 13:30 |
| Son_Goku | cjwatson, you typically don't need to go to that level | 13:30 |
| cjwatson | (sure, nowadays it's usually in a git repository, but wasn't historically the case and I'm reaching for an apples-to-apples comparison) | 13:30 |
| Son_Goku | because the sources are in a central VCS typically | 13:30 |
| Son_Goku | right | 13:30 |
| rbasak | Son_Goku: you might be interested in http://summit.ubuntu.com/uos-1611/meeting/22710/git-based-merge-workflow/ BTW. I hope that soon we'll have Ubuntu packages clonable from git. | 13:30 |
| Son_Goku | rbasak, zyga actually is managing snap-confine using a similar workflow to what we do in Fedora | 13:31 |
| Son_Goku | I think it's probably the sanest approach for managing packaging | 13:31 |
| Son_Goku | rbasak: https://git.launchpad.net/snap-confine | 13:32 |
| cjwatson | ugh, non-full-source | 13:32 |
| cjwatson | horrible | 13:32 |
| Son_Goku | cjwatson, it is designed to make it harder to do random monkey-patching | 13:33 |
| Son_Goku | which is something that I've had the misfortune of seeing from Debian packages before | 13:33 |
| cjwatson | I am an absolute unashamed partisan of full-source packaging repositories | 13:33 |
| cjwatson | you won't persuade me otherwise, it's a firm opinion established over 15 years | 13:33 |
| * Son_Goku shrugs | 13:33 | |
| Son_Goku | I've done both workflows myself | 13:33 |
| pitti | bzr-buildpackage actually made debian/ only trees not suck | 13:34 |
| Son_Goku | doesn't git-buildpackage do the same thing? | 13:34 |
| Son_Goku | for git stuff | 13:34 |
| pitti | I actually quite enjoyed it, it was clean and super-fast as it doesn't have to drag along the huge upstream portion | 13:34 |
| Son_Goku | pitti: \o/ | 13:34 |
| pitti | maybe it can, but I've always seen it full-source | 13:34 |
| pitti | and I'm using it myself that way -- the usual triumvirate of upstream, pristine-tar, master | 13:35 |
| cjwatson | ditto except with git-dpm | 13:35 |
| Son_Goku | I personally prefer having the original sources stored as a tarball or archived in a lookaside system and maintaining the packaging sources in VCS | 13:36 |
| Son_Goku | to me, it enforces the split between the software and the packaging better | 13:36 |
| cjwatson | I find it enormously useful to be able to do consolidated 'git blame' across both | 13:36 |
| cjwatson | which doesn't work if you "enforce the split" | 13:36 |
| * pitti waves good bye and bids a nice weekend to everyone; gotta leave early today | 13:37 | |
| Son_Goku | cjwatson, sure, and that is an advantage | 13:37 |
| Son_Goku | until it isn't | 13:37 |
| rbasak | I think "enforcing the split" is more appropriate as a cultural thing at review/upload time. No need to compromise our tooling for it. | 13:37 |
| cjwatson | I've not hit the "until" | 13:37 |
| Son_Goku | when you can't tell whether it's an upstream or downstream change, it's a problem | 13:38 |
| cjwatson | it's not that I can't tell | 13:38 |
| Son_Goku | or when you refer to commit hashes that don't exist upstream | 13:38 |
| cjwatson | it's that I don't care when I'm in the middle of investigating a bug | 13:38 |
| cjwatson | when I'm preparing a fix, sure, I'll work out where the appropriate target is | 13:38 |
| cjwatson | but that comes later, and I don't want my convenience compromised | 13:39 |
| * Son_Goku shrugs | 13:39 | |
| rbasak | Son_Goku: why can't you tell if it's an upstream or downstream change? And why do you accidentally refer upstream to downstream commit hashes? | 13:39 |
| Son_Goku | rbasak, I've seen Debian packages have downstream patches applied to master and referred to in changes as upstream commits | 13:39 |
| rbasak | Certainly I can see how this could be a problem with 1.0 format. But not 3.0. | 13:39 |
| Son_Goku | and because they never made it upstream, I have no idea where they are | 13:40 |
| rbasak | Applied to master where? In debian/patches? Or via git-dpm? | 13:40 |
| Son_Goku | and also, since Debian doesn't enforce a VCS for packaging, tracing it is hard, too | 13:40 |
| rbasak | We have dep3 headers to track origin and status. | 13:40 |
| Son_Goku | rbasak: applied to the master in the deb-git structure | 13:40 |
| Son_Goku | and not as a debian/patch file | 13:40 |
| rbasak | If we're talking about best practice of git, gbp, git-dpm and 3.0 (quilt) packages, you can't invoke "but 1.0 and no VCS". That isn't part of the debate. | 13:40 |
| cjwatson | I really don't think that "some people have screwed things up" is a reason for making the tools harder to use | 13:40 |
| Son_Goku | eh, no, this is with 3.0 packages | 13:41 |
| Son_Goku | with a VCS | 13:41 |
| Son_Goku | but you're right, the not enforcing VCS thing is irrelevant in this case | 13:42 |
| rbasak | Son_Goku: if it's not a debian/patch file, dpkg-source will refuse on a 3.0 quilt package. That's just an error and an unbuildable package. Not a workflow difference that encourages bad practice. It can't encourage bad practice, because it doesn't work. | 13:42 |
| rbasak | dholbach: o/ would you mind setting up a UOS MySQL/MariaDB session for me please? I asked jgrimm but just realised he's out today (US holiday). | 14:14 |
| rbasak | dholbach: I have a slot preference since we have some external employees attending. I'll just work it out from the RSVPs. | 14:15 |
| rbasak | dholbach: can we have it at 1500-1600 UTC on Tuesday please? That seems to fit the key attendees the best. | 14:17 |
| dholbach | hey rbasak, does http://summit.ubuntu.com/uos-1611/propose_meeting/ work for you? | 14:18 |
| rbasak | Oh, I didn't know about that. Sorry! | 14:18 |
| * rbasak uses it | 14:18 | |
| dholbach | you might have to go to http://summit.ubuntu.com/uos-1611/registration before it | 14:18 |
| dholbach | no worries :) | 14:18 |
| rbasak | dholbach: done, but I don't see a scheduling option | 14:20 |
| dholbach | let me take a look | 14:26 |
| dholbach | rbasak, thanks, scheduled | 14:27 |
| dholbach | http://summit.ubuntu.com/uos-1611/2016-11-15/ | 14:27 |
| rbasak | dholbach: thank you! | 14:34 |
| dholbach | anytime | 14:35 |
| jgrimm | thanks rbasak | 14:57 |
| kirkland | rbasak: I have no opinion on that | 15:25 |
| rbasak | kirkland: thanks. We'll JFDI then I think. | 15:26 |
| rbasak | Though I think this may need an MIR :-/ | 15:27 |
| rbasak | No, it looks like it's a fork. | 15:28 |
| rbasak | pitti: iptraf-ng> ^ are you happy to proceed without a MIR? | 15:28 |
| rbasak | pitti: swapped in the seed, and subscribed ~ubuntu-server. Please override. | 15:32 |
| doko | rbasak, jgrimm: please could you have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg ? freeradius tries to pull collectd into MAIN | 18:35 |
| nacc | doko: might be late for rbasak and jgrimm is on holiday; looking | 18:47 |
| nacc | doko: it seems freeradius has grown a b-d on libcollectdclient-dev | 18:47 |
| nacc | doko: looks like we'd need a delta to change our build? | 18:51 |
| nacc | doko: yeah, i think that's what is driving freeradius-utils to dep on libcollectdclient1 | 18:52 |
| nacc | doko: working on a merge now, i'll take a look after this | 18:52 |
| doko | nacc: ta | 18:52 |
| dmj_s76 | What kind of updates can we expect for Unity in the next LTS point release? | 21:25 |
| dmj_s76 | Will there be an updated release or just cherry picks/backports? | 21:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
