| Unit193 | LocutusOfBorg: ...You should look into merging dput! >_> | 01:46 |
|---|---|---|
| Unit193 | !info dput artful | 01:46 |
| Unit193 | !info dput unstable | 01:46 |
| ubottu | dput (source: dput): Debian package upload tool. In component main, is optional. Version 0.9.6.4ubuntu3 (artful), package size 32 kB, installed size 164 kB | 01:46 |
| ubottu | dput (source: dput): Debian package upload tool. In component main, is optional. Version 0.12.1 (unstable), package size 53 kB, installed size 196 kB | 01:46 |
| === mwsb is now known as chu | ||
| Unit193 | I have nominated LP 651610 for xenial and zesty, can I have someone ACK? | 02:47 |
| ubottu | Launchpad bug 651610 in gnome-exe-thumbnailer (Ubuntu) "Version number for .msi thumbnail is obtained from unreliable source" [Critical,Fix released] https://launchpad.net/bugs/651610 | 02:47 |
| sarnold | done | 02:48 |
| Unit193 | Thanks. | 02:49 |
| === JanC_ is now known as JanC | ||
| LocutusOfBorg | Unit193, I tried, and I failed | 06:47 |
| LocutusOfBorg | debdiff appreciated | 06:47 |
| Unit193 | Unfortunate. | 06:47 |
| LocutusOfBorg | doko, level 4 scheduled | 06:47 |
| doko | LocutusOfBorg: do you continue with the uploads? | 06:56 |
| LocutusOfBorg | do you want all until the end^ | 07:06 |
| LocutusOfBorg | I'll do | 07:06 |
| LocutusOfBorg | just to be clear, I'm talking of this page http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.26.html :) | 07:07 |
| LocutusOfBorg | all done | 07:10 |
| ricotz | LocutusOfBorg, hi, don't forget apparmor | 07:15 |
| doko | jamespage, rbasak, nacc: some openstack packages trigger component mismatches and need MIRs. see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 08:10 |
| === zyga-ubu1tu is now known as zyga-ubuntu | ||
| doko | jbicha: please could you have a look at https://launchpad.net/ubuntu/+source/libmongodb-perl/1.4.5-1build1/+build/13155795 failing with your mongodb sync from experimental | 09:30 |
| LocutusOfBorg | doko, https://launchpad.net/ubuntu/+source/libanyevent-perl/7.130-2build1/+build/13157635 this is making a lot of s390x sadness | 09:31 |
| LocutusOfBorg | lets see if a give-back works | 09:31 |
| doko | x nox promised to have a look. no, didn't help | 09:32 |
| doko | the libvm-ec2-perl upload wasn't necessary | 09:33 |
| doko | ohh, now it did help. xnox, nothing to do with libanyevent-perl | 09:34 |
| mwhudson | LocutusOfBorg: i don't know if someone has bugged you about this already, but when merging from debian could you ensure your .changes has the debian stuff in too? | 10:11 |
| mwhudson | LocutusOfBorg: the merge-buildpackage etc files you get from grab-merge get this right | 10:12 |
| jamespage | doko: raised https://bugs.launchpad.net/ubuntu/+source/websocket-client/+bug/1706940 | 10:24 |
| ubottu | Launchpad bug 1706940 in websocket-client (Ubuntu) "[MIR] websocket-client" [High,New] | 10:24 |
| doko | jamespage: this page like python-future sets an alternative, but with a higher alternative for python2. I don't think we want this. does this matter for openstack? if not, can we switch the priorities | 10:43 |
| jamespage | doko: for this one no I don't think it does | 10:44 |
| jamespage | doko: happy to switch those around now | 10:44 |
| doko | yep, or else we will look for old python2 uses later | 10:45 |
| doko | jamespage: and do we use the same cert store as debian does, or do we still use our snakeoir certificates? | 10:47 |
| jamespage | doko: is that in reference to the patch in the package? | 10:48 |
| doko | jamespage: yes | 10:48 |
| jamespage | doko: I think we should be using the global cert store as tweaked by that patch | 10:50 |
| doko | jamespage: hmm, the priorities seem to be still wrong? websocket-client | 12:21 |
| jamespage | doko: I'll check again but I switched them around | 12:21 |
| LocutusOfBorg | mwhudson, you are right, but I fail to use merge-buildpackage | 12:21 |
| LocutusOfBorg | and I usually forget about that :( | 12:22 |
| LocutusOfBorg | doko, we have only libmongodb-perl failure left? | 12:23 |
| doko | LocutusOfBorg: yes | 12:23 |
| LocutusOfBorg | and testsute | 12:25 |
| LocutusOfBorg | doko, I'm looking at upstream commits for testsuite failures/fixes | 12:31 |
| LocutusOfBorg | got it, the new mongodb is the culprit I think | 12:39 |
| doko | jamespage: the prios are correct | 12:48 |
| doko | jamespage: but: the package depends on backports.ssl-match-hostname :-/ | 12:49 |
| doko | imo we don't need that with recent python versions | 12:49 |
| jamespage | doko: oh I see what you mean | 12:53 |
| jamespage | doko: which 2.7.x point release is good enough to not need this | 12:54 |
| LocutusOfBorg | mongodb binding seems good, uploaded | 12:55 |
| LocutusOfBorg | doko, is "switching priorities" a matter of s#/usr/bin/python2-futurize 300#/usr/bin/python3-futurize 300#g | 12:57 |
| LocutusOfBorg | and renaming the postinst to the python3 version? | 12:57 |
| doko | jamespage: I think it's 2.7.9, but the package itself doesn't document it | 12:57 |
| doko | LocutusOfBorg: yes, uploaded | 12:57 |
| LocutusOfBorg | oh thanks! I thought the "incomplete" was meaning a task for me, I was looking at the package, nice to see it is ok now | 12:58 |
| doko | jamespage: yes, https://www.python.org/dev/peps/pep-0466/ 2.7.9 | 12:59 |
| LocutusOfBorg | doko, with mongodb fixed it is a matter of kicking autopkgtest to run against the -proposed perl stuff, do you know an easy way (and if this is correct?) | 12:59 |
| === sergiusens_ is now known as sergiusens | ||
| doko | LocutusOfBorg: see #ubuntu-release | 12:59 |
| doko | jamespage: and it's backported into the python2.7 trusty package | 13:03 |
| jbicha | LocutusOfBorg: thanks for the mongo fix | 13:04 |
| LocutusOfBorg | thanks you all | 13:04 |
| LocutusOfBorg | the transition tracker has moved to red into green in 12 h | 13:05 |
| jbicha | kirkland: ugh, generic naming with your proposed 'statistics' package name | 13:29 |
| * rbasak wonders why that isn't going into Debian | 13:42 | |
| === sergiusens_ is now known as sergiusens | ||
| roaksoax_ | win 3 | 14:23 |
| bmw | rbasak: what's the status of the Certbot SRU? | 14:48 |
| rbasak | bmw: otp. Blocked on me. | 14:49 |
| ogra_ | cool kids dont do SRUs ... cool kids do snaps ;) | 14:49 |
| * ogra_ giggles evil | 14:50 | |
| cjwatson | certbot would be pretty challenging to run as a snap given that it wants to fiddle with your apache config | 14:51 |
| bmw | rbasak: kk just wanted to check in | 14:51 |
| bmw | let me know if there's anything we can do on our end to help the process | 14:51 |
| ogra_ | cjwatson, just needs an apache snap with the right interfaces ;) | 14:51 |
| ogra_ | (but yeah ... i was rather joking) | 14:52 |
| seb128 | newbie question of the day | 15:07 |
| seb128 | what does launchpad mean by " Target reference path" in a git mp? | 15:07 |
| seb128 | is that the git branch to target? | 15:09 |
| rbasak | seb128: correct. So often "master". | 15:10 |
| rbasak | The wording is poor IMHO. You can't actually target any reference - it has to be a branch. | 15:11 |
| rbasak | So it might as well say "Target branch". | 15:11 |
| rbasak | (I've wanted to target tags before - ie. a proposal to push a tag, rather than a proposal to merge something) | 15:12 |
| nacc | doko: yep, i am aware of the parsedatetime one, i need to file the MIR still :/ | 15:12 |
| nacc | doko: i believe jamespage is on the openstack ones already | 15:12 |
| seb128 | rbasak, yeah, the wording is not obvious | 15:13 |
| seb128 | googling doesn't help much | 15:13 |
| seb128 | rbasak, thanks | 15:13 |
| cjwatson | seb128,rbasak: Yes, I have work in progress to revamp that page, including making the wording less poor | 15:25 |
| seb128 | cjwatson, good to know :-) | 15:25 |
| rbasak | cjwatson: while you're there, it'd be nice if "Target reference" defaulted to what HEAD points to. | 15:26 |
| cjwatson | rbasak: Yes, that's one of the other included things :) | 15:26 |
| rbasak | Great :) | 15:26 |
| cjwatson | But it's a big and complicated chunk of work that I'm fitting into my back burner | 15:26 |
| cjwatson | (the other substantial chunk of it is search/autocompletion) | 15:28 |
| cjwatson | (oh and also reorganising the layout, because the "Extra options" expander is basically a hindrance and everything is in the wrong order) | 15:29 |
| === klebers_ is now known as klebers | ||
| LocutusOfBorg | doko, can I steal xtrs merge? I know it is useless, but I would like to see restricted and multiverse "free" from outstanding stuff | 17:08 |
| LocutusOfBorg | less delta, less multiverse stuff | 17:13 |
| ginggs | LocutusOfBorg: there's a new xtrs version coming then you can sync, ask spwhitton | 17:27 |
| ginggs | see my comment "4.9c-4 not needed, cannot sync yet" | 17:28 |
| ginggs | LocutusOfBorg: also see debian bug #859751 | 17:29 |
| ubottu | Debian bug 859751 in src:xtrs "xtrs: please pass buildflags" [Wishlist,Open] http://bugs.debian.org/859751 | 17:29 |
| kirkland | jbicha: um, there's no "stastistics" package in Ubuntu, it's super descriptive, and provides exactly what it says -- statistics tools | 17:34 |
| kirkland | rbasak: I'm not a DD | 17:34 |
| rbasak | kirkland: it risks a namespace collision with Debian. Our usual policy is to expect new packages in Debian unless there's a specific reason we can't. I don't think the need to find a sponsor qualifies. | 17:36 |
| kirkland | rbasak: No. There's no reason that Debian can't be a "downstream" of Ubuntu. There's plenty of precedent thereof. | 17:37 |
| rbasak | kirkland: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages | 17:37 |
| rbasak | kirkland: I don't believe there's any precedent for the reason "I'm not a DD". | 17:37 |
| rbasak | kirkland: see the pain regarding "click", for example. | 17:38 |
| rbasak | (and in that case, there was a good reason) | 17:38 |
| kirkland | rbasak: note the "-0ubuntu1" in the package version | 17:39 |
| kirkland | rbasak: it's "-0ubuntu1" for exactly this reason | 17:39 |
| kirkland | rbasak: such that a -1 from Debian would supercede it | 17:39 |
| rbasak | kirkland: there's more to it than that. A potential collision is not just in the versioning. | 17:39 |
| sarnold | and replace your stats package with rusty russell's stats package? | 17:39 |
| cjwatson | Lots of repositories called "statistics" on GitHub too. Namespacing is polite. | 17:44 |
| cjwatson | And wise. | 17:44 |
| cjwatson | (I didn't want to call it just "click", but I was overruled, and then several people had to spend quite a few hours cleaning up the wreckage when there was a conflict. We possibly couldn't have foreseen the specific conflict at the time, but the general issue was foreseeable.) | 17:46 |
| jbicha | kirkland: you could become a DM and maintain it yourself in Debian | 17:48 |
| cjwatson | Wouldn't surprise me if Debian ftpmaster weren't too keen on such a generic name either ... | 17:49 |
| cjwatson | Oh and much of that package duplicates num-utils. | 17:50 |
| jbicha | a recent personal example of Debian's dislike of generic package names: https://bugs.debian.org/854951 | 17:50 |
| ubottu | Debian bug 854951 in wnpp "ITP: gnome-recipes -- Recipe application for GNOME" [Wishlist,Open] | 17:50 |
| cjwatson | Or at least substantially overlaps it. num-utils has had the good sense to put a prefix on all its commands. | 17:51 |
| sarnold | num-utils looks neat, thanks :) | 17:52 |
| kirkland | fine. the package has been renamed from "statistics" to "stawk" | 18:00 |
| sarnold | love it :D | 18:02 |
| kirkland | I'm delighted for it to land in Debian, if someone (anyone) wants to sponsor it | 18:03 |
| cjwatson | are all the program names non-conflicting? I only looked at the bzr branch briefly but those were quite the namespace grab. | 18:04 |
| kirkland | cjwatson: http://paste.ubuntu.com/25185293/ | 18:08 |
| kirkland | cjwatson: no collisions there; I'll change "min" to "minimum" and "max" to "maximum", if that makes you happier | 18:08 |
| cjwatson | there's precedent for putting short and convenient but very namespace-grabby names like that in a subdirectory so that people can opt in, and I think that would be a better approach | 18:08 |
| cjwatson | see e.g. surfraw | 18:08 |
| kirkland | sigh | 18:09 |
| kirkland | the number of times I've looked up these commands in stackexchange over the years... | 18:10 |
| tsimonq2 | cjwatson: But to play devil's advocate, that's an extra step just to install a freaking package. :P | 18:10 |
| kirkland | ...they've landed in my $HOME/bin and been *super* useful | 18:10 |
| kirkland | I thought I'd share that with the Ubuntu world | 18:10 |
| cjwatson | the devil does not need more advocates | 18:10 |
| tsimonq2 | cjwatson: lol | 18:10 |
| cjwatson | look, it's a huge shared namespace, asking you to think about playing nicely in it isn't a rejection | 18:11 |
| cjwatson | the subdirectory approach is a good way to save yourself and others trouble in the future if you want to keep the generic names | 18:11 |
| cjwatson | I've had /usr/lib/surfraw in my $PATH for a decade or more because I really like it, but I can totally see why it seemed best for it not to claim e.g. /usr/bin/google | 18:12 |
| cjwatson | it's a nice cooperative approach | 18:13 |
| kirkland | cjwatson: apt-cache search surfraw isn't finding anything | 18:14 |
| cjwatson | and I mean, sure, I have loads of handy things in my ~/bin/ too, but usually they have names that are mostly meaningful to me and there's often an extra layer of thinking involved in moving that into a shared namespace | 18:14 |
| cjwatson | kirkland: I don't know why that would be; it's been in Ubuntu since warty | 18:14 |
| tsimonq2 | !info surfraw | 18:15 |
| ubottu | surfraw (source: surfraw): fast unix command line interface to WWW. In component universe, is optional. Version 2.2.9-1 (artful), package size 98 kB, installed size 414 kB | 18:15 |
| tsimonq2 | kirkland: ^ | 18:15 |
| kirkland | thx. | 18:15 |
| kirkland | found it. | 18:15 |
| kirkland | hmm, this would safely ensure that *no one* would ever find or use the tool | 18:17 |
| cjwatson | you're being super-dramatic | 18:17 |
| cjwatson | and I need to do housework | 18:17 |
| rbasak | kirkland: surely this should be a snap anyway? I see that it likely is - so why does it need to be in the apt repository too? | 18:20 |
| kirkland | rbasak: ah, a snap.... | 18:20 |
| kirkland | rbasak: would work fine on stdin | 18:20 |
| kirkland | rbasak: but to use against any arbitrary file? needs --classic | 18:21 |
| rbasak | Indeed | 18:21 |
| kirkland | rbasak: a deb is *so* much better for this | 18:21 |
| rbasak | Distribution repos have mostly operated on a pull basis - ie. people don't usually push their own projects. When a project is popular enough a distribution developer packages it. It doesn't have to be this way, but it does avoid a bunch of friction like namespacing issues. | 18:22 |
| kirkland | one posix shell script, that cleanly wraps awk, sort, and uniq, and performs the 9 most frequently used statistical analysis operations, portable anywhere | 18:22 |
| rbasak | If every person with a project on Github pushed into a distribution repository, we'd have to manage that very differently to how we do today. | 18:22 |
| rbasak | It seems to me that snaps solve this problem much more nicely and are much better suited for people pushing their own projects. | 18:24 |
| tsimonq2 | rbasak: But isn't the Snap store a distribution repository? | 18:25 |
| tsimonq2 | It pulls in Ubuntu build dependencies, runs on the Ubuntu build infrastructure, etc. | 18:25 |
| tsimonq2 | It just happens to run on other distros, no? | 18:26 |
| rbasak | tsimonq2: that's just semantics. Whichever way, it's designed for people to be able to push their own stuff with far less friction., | 18:26 |
| LocutusOfBorg | ginggs, thanks :) | 18:26 |
| cjwatson | Snaps also have namespacing restrictions: that's why by default multiple commands delivered by a single snap get a prefix, and requests for unprefixed commands need to go through what amounts to namespace arbitration. | 18:27 |
| kirkland | it makes me sad that I'm trying to give Ubuntu users something useful, and it's getting hung up in red tape :-( | 18:29 |
| rbasak | At least the namespacing is up front though. With the NEW queue it's more hidden, and the review is only on NEW, not for future updates. | 18:29 |
| rbasak | kirkland: you see it as red tape. We see the maintenance burden you're giving us. | 18:29 |
| tsimonq2 | rbasak: I could argue all day on semantics as to why I don't see Snaps as a solution that's ready yet, but I digress :P | 18:29 |
| kirkland | rbasak: sharing with you, my friend | 18:30 |
| kirkland | rbasak: cjwatson: if I re-namespace as: calc-avg, calc-max, calc-min, calc-* | 18:32 |
| kirkland | rbasak: cjwatson: and rename the package again, calc-stats | 18:32 |
| kirkland | rbasak: cjwatson: and then re-upload to -0ubuntu1 in artful | 18:33 |
| cjwatson | (please untag me) | 18:33 |
| kirkland | rbasak: am I going to find myself back here with a new set of hurdles? | 18:33 |
| kirkland | cjwatson: sorry, done. | 18:33 |
| rbasak | kirkland: I still think it should go via Debian. Wearing my MOTU hat, I don't see any reason why MOTU would want to maintain this. Find some users who want it first please, and want your implementation instead of someone else's, and then convince MOTU that they want to maintain it. | 18:34 |
| kirkland | sorry, that's b.s. | 18:35 |
| cjwatson | calc-* is certainly much better naming-wise. (But I'm just stating my opinion, not acting as a gatekeeper.) | 18:35 |
| kirkland | cjwatson: thanks, I understand the global namespace problem; while I don't like it, I can see your point | 18:35 |
| rbasak | kirkland: we work in teams in Ubuntu. What team will be maintaining this package? | 18:36 |
| kirkland | rbasak: the upload-to-debian-first mantra, sorry, there's no reason to punish Ubuntu users because Debian's new queue is 3+ months long | 18:36 |
| rbasak | kirkland: which users, exactly, will be being punished? Do you have a single user who wants this apart from yourself? | 18:36 |
| tsimonq2 | kirkland: I wouldn't say it's that long (last time I needed something through Debian's NEW queue, it took maybe a week or two) | 18:38 |
| rbasak | kirkland: please can we reach consensus on this before you throw more things at the queue? | 18:39 |
| kirkland | rbasak: a few, among hundreds of URLs, where people ask StackExchange, etc., "how do you sum all numbers in a file?" "get the average?" "get the median?" "generate a histogram?" http://paste.ubuntu.com/25185454/ | 18:40 |
| kirkland | rbasak: look, in terms of "maintenance", if we were talking about even a few hundred lines of C/Go/Python -- sure let's make sure we have a team responsible for it | 18:42 |
| kirkland | rbasak: but seriously .... we're talking about what amounts to about a dozen lines of shell code that wrap awk to do some phenomenally useful things | 18:43 |
| rbasak | ...and we've already pointed out potential issues with namespacing and collisions in /usr/bin and package names in Debian, which will need to be looked after should collisions happen. | 18:43 |
| kirkland | rbasak: we're not talking about an encrypted authentication system sending data out to the internet | 18:43 |
| rbasak | This is maintenance of the *packaging*, not of the upstream. | 18:43 |
| rbasak | I'm also not aware of any exception to the general principle in Ubuntu that we do things through teams, rather than individual unilateral action. | 18:44 |
| kirkland | rbasak: I've offered to rename calc-* to drastically reduce the chances of namespace collisions (as well as drastically reducing the discoverability and usefulness) | 18:44 |
| rbasak | Right now you're holding a -1 from multiple developers. | 18:44 |
| rbasak | Please get consensus before uploading. | 18:44 |
| rbasak | Or escalate to the TB as our governance structure dictates. | 18:45 |
| kirkland | rbasak: dude, the packaging? it's %: dh $@, and a direct installation of scripts from bin/* | 18:45 |
| kirkland | rbasak: sorry, again, we're not talking about complexity | 18:46 |
| cjwatson | "drastically reducing the ... usefulness" oh please. | 18:46 |
| rbasak | I feel that you're being deliberately obtuse now. The click situation has been pointed out to you. | 18:46 |
| cjwatson | a little less hyperbole? | 18:46 |
| wxl | why don't you provide your own packages through a ppa or whatever, kirkland ? i mean if you're that impatient— | 18:46 |
| kirkland | wxl: they're already there | 18:47 |
| wxl | good! | 18:47 |
| wxl | then all those desperate users have a solution | 18:47 |
| wxl | thus, no need for urgency | 18:47 |
| wxl | patience is a virtue :) | 18:47 |
| tsimonq2 | kirkland: Back to your previous point, could you elaborate on the point of it not being discoverable? | 18:47 |
| cjwatson | discoverability is a slightly better point, although command-not-found will still show up your package if the searched command is a substring of one of your program names, so it's probably not that terrible | 18:47 |
| tsimonq2 | Because I think that's the point kirkland is trying to make here, the reason against avoiding namespace collision is making it discoverable. Am I wrong? | 18:48 |
| cjwatson | and people will often spell things in slightly different ways than you expect anyway (say, stdev vs. stddev) | 18:48 |
| kirkland | I'm disappointed, but resolved to calc-* for the tool namespacing | 18:48 |
| cjwatson | I think that may be the point they're making but I don't think it's a strong one | 18:48 |
| kirkland | cjwatson: ;-) pre-supposed that one, and shipped both stddev and stdev | 18:48 |
| cjwatson | right, but just an example | 18:49 |
| kirkland | cjwatson: ack. | 18:49 |
| kirkland | cjwatson: and I used the name "summate" to avoid an existing collision with "sum" | 18:49 |
| cjwatson | I'm only -0 on calc-stats et al (the - being because of the substantial overlap with num-utils) | 18:49 |
| rbasak | I think my objection is with the approach you're taking here, rather than any principle of what's OK to put directly into universe. I don't think it's OK for one person to unilaterally decide that a package needs to go into Ubuntu, and that it needs to go into Ubuntu directly and not via Debian. Unless it's safdfl, it should be done by consensus of the TB, or core devs, or some other Ubuntu | 18:50 |
| rbasak | development team. | 18:50 |
| rbasak | That's my understanding of our governance and decision making structure. | 18:51 |
| cjwatson | I think this is the sort of thing that seems bureaucratic when you're looking at a single instance and necessary when you're looking at it in bulk | 18:51 |
| rbasak | A team decision has the power of wider consideration of negative factors, which is easy to be blind to when it's one person wanting to drive a particular thing. | 18:52 |
| cjwatson | e.g. if you've ever had to deal with trying to clean up no-longer-maintained cruft from the archive | 18:52 |
| kirkland | cjwatson: interesting (to the discoverability point), only 1 of the 5 URLs in http://paste.ubuntu.com/25185454/ (where people are asking how to run statistical operations on numbers in a file) mentions num-utils | 18:52 |
| rbasak | On stackexchange sites? That sounds like an easy fix :) | 18:53 |
| rbasak | So...is num-utils sufficient? | 18:55 |
| kirkland | I'm grepping my local archive and finding hundreds -- hundreds of 0ubuntu* packages | 18:56 |
| kirkland | rbasak: nope; num-utils is missing functionality compared to the proposed tools | 18:56 |
| rbasak | Can you get the functionality into num-utils upstream? | 18:56 |
| rbasak | hundreds of 0ubuntu* packages> it tends to explode after doing just one because of dependencies. But also, Openstack, Mir, and other blueprint-level items have their own separate justficiations which probably don't apply here. | 18:57 |
| cjwatson | 0ubuntu* also includes everything that exists in Debian but has been advanced to a higher upstream version in Ubuntu | 18:58 |
| kirkland | okay, I give up | 19:00 |
| kirkland | rbasak: have a beer and celebrate | 19:00 |
| kirkland | I have the statistics tools I need, so I'm not mourning them; I'm sad that there are other useful projects, programs and utilities that won't exist as .debs in Ubuntu | 19:01 |
| cjwatson | http://qa.ubuntuwire.org/neglected/ exists but it's not really the right query here either; e.g. it also includes packages that were once in Debian and have been removed there but where the removal hasn't propagated for one reason or another | 19:02 |
| slangasek | rbasak: the relevant team to decide whether a given package should go directly into Ubuntu instead of via Debian is MOTU, FWIW (with AA veto) | 19:14 |
| rbasak | slangasek: good point. I did mention MOTU before, just forgot about that detail in that message. | 19:20 |
| dpb1 | so, just a simple email to the motu list? | 19:28 |
| rbasak | dpb1: that'd be a starting point, yeah. | 19:29 |
| doko | LocutusOfBorg: stell what you want | 19:36 |
| rbasak | New source: calc-stats (artful-proposed/primary) | 19:40 |
| rbasak | [1.2-0ubuntu1] | 19:40 |
| rbasak | Huh? | 19:40 |
| rbasak | kirkland: you have MOTU agreement now, do yoy? | 19:41 |
| rbasak | *you | 19:41 |
| kirkland | rbasak: I don't understand the question? | 19:41 |
| rbasak | kirkland: I asked you not to upload without consensus (as required by the CoC). Do you have consensus? | 19:41 |
| kirkland | rbasak: I pushed the final resting state of the renamed calc-* scripts; the AA and/or MOTU is welcome to accept it, or reject it, as they wish | 19:42 |
| rbasak | kirkland: MOTU cannot reject out of the NEW queue. That's why we have a sponsorship model. | 19:42 |
| rbasak | kirkland: you wear a MOTU hat because you are a core dev. | 19:42 |
| rbasak | kirkland: but if you don't have MOTU consensus, you shouldn't be uploading with that hat. | 19:42 |
| kirkland | rbasak: the last two were rejected (with my agreement here in ) by slangasek, with the explanation, "Rejected by Steve Langasek: discussed on IRC, rejected under the current names" | 19:42 |
| kirkland | rbasak: the names were fixed; if the package is still unacceptable, then I expect it will be rejected again | 19:43 |
| rbasak | kirkland: as I say: you need MOTU consensus, and the NEW queue is not the place to get that since MOTU do not review the NEW queue nor have any control over it. | 19:43 |
| rbasak | kirkland: and I say this wearing my DMB hat. | 19:44 |
| rbasak | kirkland: please ask an AA for a reject and only upload this with wider MOTU approval (not just you). Or TB or sabdfl override if you wish. | 19:46 |
| kirkland | rbasak: You may ask the AA's to reject the new package, if you wish to prevent this no-longer-namespace-colliding free software from reaching Ubuntu users in 17.10. | 19:53 |
| kirkland | rbasak: But I'm going to ask them to reject it. | 19:53 |
| kirkland | rbasak: But I'm *not* going to ask them to reject it. | 19:53 |
| rbasak | slangasek, or any other AA: please reject calc-stats from Artful NEW. I'm requesting this wearing my DMB hat because I believe it was not uploaded by MOTU consensus as required by my interpretation of the CoC. | 19:54 |
| rbasak | (and I invite a re-upload after and if consensus is reached) | 19:55 |
| Unit193 | Wouldn't it be easier to follow the process in https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Going_through_MOTU rather than trying to throw weight around? | 19:56 |
| rbasak | Unit193: that is exactly the process that I'm asking kirkland to follow. | 19:56 |
| rbasak | The NEW queue is not "submitting it to MOTU". Uploads should go there only after MOTU approval, as I explained above. | 19:57 |
| kirkland | https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages says, "MOTUs can upload new packages directly to the archive." Which is exactly what I did. | 19:57 |
| rbasak | And the https://www.ubuntu.com/about/about-ubuntu/conduct says that you should work together as a team, which you seem to be doing everything possible to avoid doing. | 19:58 |
| rbasak | "We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction." | 19:58 |
| rbasak | First step: seek consensus within MOTU. | 19:59 |
| rbasak | Escalation path: ask the TB. | 19:59 |
| rbasak | You refuse to do even the first thing. | 19:59 |
| ahasenack | bdmurray: thx for the openvpn-auth-ldap sru upload | 20:35 |
| bdmurray | ahasenack: thanks for the detailed verifications! | 20:36 |
| ahasenack | I was waiting a bit to see if someone else would do them, but eventually did them myself :) | 20:36 |
| ahasenack | slangasek: hi, question about https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1686183/comments/24 | 21:05 |
| ubottu | Launchpad bug 1686183 in ubuntu-meta (Ubuntu Artful) "Ship ubuntu-advantage in ubuntu-minimal" [Undecided,New] | 21:05 |
| ahasenack | the ubuntu-advantage script "forward copy" | 21:05 |
| ahasenack | slangasek: what would you expect to see in the debian/changelog version for each ubuntu release, considering upstream is a) a native package; and b) just version "2"? | 21:05 |
| ahasenack | 2 for trusty, then what for xenial? 2ubuntu0.16.04.1? Or even 2ubuntu0.14.04.1? | 21:06 |
| Unit193 | No, because '2ubuntu0.16.04.1' is newer than '2' | 21:08 |
| tsimonq2 | Unit193: ...but he's putting newer versions in newer releases, what's wrong with that? | 21:09 |
| ahasenack | 2ubuntu.... for all I suppose then | 21:10 |
| Unit193 | tsimonq2: The part where I read trusty and my mind switched it to artful, likely. :D | 21:11 |
| tsimonq2 | Unit193: :) | 21:12 |
| Unit193 | Well, that and too many times I've seen ca-certificates and/or tzdata not allowing an upgrade path. :3 | 21:13 |
| infinity | ahasenack: The implication of forward-copying is that there's only upload, and one version. | 21:13 |
| infinity | ahasenack: And it gets binary copied forward to each newer release. | 21:13 |
| ahasenack | infinity: how does that work during release upgrades? | 21:13 |
| ahasenack | it's the same package then, it doesn't upgrade, right | 21:13 |
| infinity | ahasenack: Yes, that. | 21:13 |
| ahasenack | in this case that call was made because it's a shell script and we determined it's ok? | 21:13 |
| infinity | I would guess so, yes. | 21:14 |
| ahasenack | hm | 21:14 |
| infinity | Not a whole lot of point in "rebuilding" it 4 times. | 21:14 |
| infinity | Nor in forcing users to do a no-op "upgrade". | 21:14 |
| ahasenack | infinity: it doesn't mean that future SRUs to this package will be copied like that, right? It depends on what the changes will be | 21:14 |
| infinity | ahasenack: Sure, in future, if there were artful-specific changes that weren't appropriate for trusty, you'd then have a fork. But that doesn't seem to be the case today. | 21:15 |
| ahasenack | infinity: what about the ubuntu release name in debian/changelog? Can it remain "trusty" for all of them without issues? | 21:15 |
| infinity | Or if it included compiled code, which we wanted to use the appropriate toolchains on each release. | 21:15 |
| infinity | ahasenack: There's no "all of them" if it's copied. There's one. So it should target the release it's uploaded to (the oldest one). | 21:16 |
| rbasak | andersk: it'd remain "trusty". You can probably find packages like that installed on your system. | 21:16 |
| rbasak | Sorry, ahasenack | 21:16 |
| ahasenack | infinity: I meant, if you are on xenial (example), and look in /usr/share/doc/<package>/changelog, you will see trusty | 21:16 |
| infinity | ahasenack: If you fork in future for multiple releases, then each should have the correct upload target in the changelog. | 21:16 |
| infinity | ahasenack: Yeah, that's true of many packages on your system already that weren't updated/rebuilt between trusty and xenial. | 21:17 |
| ahasenack | ok | 21:17 |
| ahasenack | thanks for the explanation | 21:17 |
| Unit193 | "top-left-inactive.png: Undefined subroutine &Archive::Zip::computeCRC32 called at /usr/share/perl5/File/StripNondeterminism/handlers/png.pm line 33" oh dear, that sounds like breakage, not package issues. | 21:32 |
| Unit193 | Looking at gcc7 failures, looks like a few hit that. :/ | 21:38 |
| tsimonq2 | Hmmm, let's say that package foo has version 1-1 in Debian. Version 1-1ubuntu1 is uploaded, but it introduces a regression. Is there any way that the upload could be reversed (not completely "reversed" but the changes reversed) and it automatically syncs on next upload? | 21:54 |
| tsimonq2 | If so, which version number should be used? | 21:54 |
| nacc | tsimonq2: upload a 1-1ubuntu2 that drops everything in 1-1ubuntu1? | 21:56 |
| nacc | tsimonq2: then the next merge would be a sync, as there is no delta? | 21:56 |
| rbasak | 1-2~autosync-please might work technically, but I'm not sure that wise. | 21:56 |
| rbasak | I think it'd be less confusing to sync it manually when needed. | 21:56 |
| Unit193 | 1-1+build1 ! :P | 21:56 |
| tsimonq2 | Would what Unit193 said actually work? | 21:57 |
| nacc | rbasak: oh true, that's a good point | 21:57 |
| Unit193 | That is not me making a recommendation... | 21:57 |
| rbasak | Which you should notice because it's the same as when a merge would have been needed, which you've already committed to. | 21:57 |
| tsimonq2 | nacc, rbasak, Unit193: I'm asking because foo is libwebcam. :P | 21:57 |
| Unit193 | Do better testing first, then? | 21:58 |
| rbasak | Yeah so I'd do what nacc said. Upload 1-1ubuntu2, explain in the changelog, and sync manually. | 21:58 |
| rbasak | (after a new Debian upload) | 21:58 |
| tsimonq2 | Alright, I'll go with that. Except, I don't have upload permissions, so it'll go in a bug report anyways. :P | 21:58 |
| tsimonq2 | Thanks! | 21:59 |
| infinity | 1-1+build1 would be fine too. 1-2~build1 would not, because it would be higher than a 1-1.1 NMU. | 22:00 |
| infinity | (And 1-2~build1 implies it a backport of -2 or an upload of an in-progress -2, which it's not) | 22:01 |
| tsimonq2 | infinity: That makes sense, and I like that better than 1-1ubuntu2 because then on the next Debian upload, it should be autosynced, right? | 22:02 |
| infinity | It would do, yes. | 22:02 |
| tsimonq2 | That's exactly my goal here, thus why I asked. :P | 22:02 |
| tsimonq2 | Thanks infinity | 22:02 |
| tsimonq2 | Bug 1707074 if anyone feels like sponsoring ;) | 22:11 |
| ubottu | bug 1707074 in libwebcam (Ubuntu) "Fix FTBFS introduced in most recent Ubuntu upload" [Undecided,In progress] https://launchpad.net/bugs/1707074 | 22:11 |
| infinity | tsimonq2: That looks more like a cmake regression to me. | 22:38 |
| === JanC_ is now known as JanC | ||
| tsimonq2 | infinity: Does it? | 22:38 |
| tsimonq2 | infinity: I mean it could be | 22:39 |
| infinity | tsimonq2: Well, in xenial, /usr/bin/cmake -P cmake_install.cmake installed to multiarch dirs, now it doesn't? | 22:39 |
| tsimonq2 | infinity: Good point. | 22:40 |
| === TheMaster is now known as Unit193 | ||
| === dcmorton_ is now known as dcmorton | ||
| === tumbleweed_ is now known as tumbleweed | ||
| === iulian_ is now known as iulian | ||
| === sarnold_ is now known as sarnold | ||
| tsimonq2 | infinity: But if it's a cmake regression, why would Debian do it in the first place before anyone in Ubuntu touched it? | 22:46 |
| infinity | tsimonq2: Do "it"? | 22:46 |
| tsimonq2 | infinity: The Ubuntu delta installed it to multiarch dirs. | 22:47 |
| tsimonq2 | infinity: So in Debian, it isn't installed to multiarch dirs. | 22:47 |
| infinity | tsimonq2: Note the last time it was uploaded to Debian. | 22:47 |
| infinity | (And Ubuntu, for that matter) | 22:47 |
| infinity | tsimonq2: The last Debian upload was before multiarch. | 22:47 |
| tsimonq2 | infinity: Sure, but this was seen in the GCC 7 rebuilds (that's where I found it), surely Debian would have a bug filed as well? | 22:48 |
| tsimonq2 | infinity: Didn't they do a mass bug filing for GCC 7 regardless? | 22:48 |
| tsimonq2 | infinity: (to be fair, that's digressing from the original point) | 22:48 |
| tsimonq2 | infinity: Alright, I can entertain the idea of it being a cmake regression. | 22:49 |
| infinity | tsimonq2: Uploaded a different fix. | 22:50 |
| infinity | tsimonq2: I mean, it looks like a cmake behaviour change, but it's also something most people with modern packages wouldn't have noticed. | 22:50 |
| infinity | Cause dh(1) fills this in properly. | 22:51 |
| tsimonq2 | infinity: Thanks, you were probably ahead of me on this one. :) | 22:51 |
| infinity | tsimonq2: http://launchpadlibrarian.net/330924451/libwebcam_0.2.4-1.1ubuntu1_0.2.4-1.1ubuntu2.diff.gz | 22:51 |
| tsimonq2 | infinity: Ohhh, I see what you did there. | 22:51 |
| === cjwatson_ is now known as cjwatson | ||
| tsimonq2 | infinity: Yeah, this package is still back on debhelper compat 7 | 22:53 |
| infinity | tsimonq2: Anyhow, it was probably meaningless in this case, as libwebcam appears to have only one rdep, but generally, be wary of anything reverting multiarch status, as that can cascade in multiarch uninstallability. | 22:55 |
| infinity | (ie: a multiarch library with non-multiarch deps is no longer multiarch, at least, not usefully) | 22:55 |
| tsimonq2 | infinity: Alright, I've made a note to be more careful with multiarch deps in the future. Thanks for your time! | 22:57 |
| === AdmWiggin is now known as tianon | ||
| Unit193 | infinity: ...Should I ask how dinner went? | 23:49 |
| infinity | Unit193: Nobody died. | 23:51 |
| Unit193 | Success, congrats! | 23:51 |
| Unit193 | I'm just going to presume steak was good. | 23:51 |
| infinity | It was. Mostly still mooing. | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
