| nacc | rbasak: iirc, it didn't work the way it seems like it should | 00:00 |
|---|---|---|
| nacc | rbasak: let me see if i have notes | 00:00 |
| rbasak | We'd need to drop the extracted_dir os.listdir search thing too. Maybe hardcode it to "$extract_dir/x" or similar. | 00:01 |
| nacc | right, but like i said, i think that's what i had before and it didn't do what you expected | 00:01 |
| nacc | :) | 00:01 |
| nacc | rbasak: ah, it's because the output directory must not already exist | 00:02 |
| nacc | and there's no way to make it a temp directory then, without our own managment | 00:02 |
| rbasak | That's what I meant by "$extract_dir/x". | 00:03 |
| nacc | rbasak: i guess we could racily do a tempname() or whatever, but then... racy | 00:03 |
| rbasak | Let me show you what I mean. | 00:03 |
| nacc | rbasak: ok | 00:04 |
| rbasak | nacc: roughly rewritten dsc_to_tree_hash: http://paste.ubuntu.com/23784442/ (untested, diff not helpful) | 00:07 |
| nacc | rbasak: won't, line 59 create the temp directory? | 00:09 |
| nacc | rbasak: per `man dpkg-source` the output dir cannot already exist | 00:09 |
| nacc | that's what i was trying to say above | 00:09 |
| rbasak | nacc: 59 will create temp_dir, yes. But dpkg-source will run on $temp_dir/x, not $temp_dir. | 00:09 |
| nacc | rbasak: oh i see what you're doing | 00:10 |
| rbasak | So then I don't have to search to find out what it called it, and I get to use $temp_dir for $temp_dir/index later on as well. | 00:10 |
| nacc | if you can test it, then sure, that's fine | 00:10 |
| nacc | it seems reasonable, i mean | 00:10 |
| rbasak | OK, thanks. I'll clean up and rebase. | 00:10 |
| nacc | i'd like a comment or something, maybe? it's basically a sneaky way to workaround dpkg-source behavior | 00:10 |
| nacc | and easy to miss, imo :) | 00:11 |
| rbasak | Sure | 00:11 |
| nacc | rbasak: otherwise, in general, the changes for unapproved look good | 00:11 |
| nacc | rbasak: how hard was it for you to spin up the changes? just wondering how non-pythonic i'm being | 00:11 |
| rbasak | nacc: your code is pretty nice and Pythonic IMHO. The only pain was in shoring up some leaky abstractions, but I think that's to be expected. The number of times the code has been adjusted, and not knowing where we were going in the first place meant that it was inevitable. And I think it's fine to clean up as we go along, so anything I touch I'm cleaning up. | 00:13 |
| rbasak | nacc: maybe a few missing context managers (cleaning up stuff by hand instead of using "with" blocks). But nothing major. | 00:14 |
| nacc | rbasak: yeah i think i didn't/don't know enough about the pythonic way at the start, so it's probably more imperative and LBYL than it should be. I've been cleaning that up as I go as well | 00:15 |
| rbasak | As we're talking about it: | 00:16 |
| rbasak | raise SourceExtractionException | 00:16 |
| rbasak | That raises the class object. Should be SourceExtractionException() really - an instance of an exception rather than the definition of one itself. | 00:16 |
| nacc | ah of course, makes sense | 00:16 |
| rbasak | But this stuff is minor really. Doesn't matter much! | 00:17 |
| rbasak | I intend to extend the unapproved stuff and call it "queue" BTW. Since I realised today I want NEW handling too. | 00:17 |
| rbasak | Since in SRUs, stuff that hits NEW is often backported from the dev release, and I want to diff against those and they can be imported. | 00:18 |
| nacc | rbasak: yep, makes sense to me | 00:18 |
| nacc | rbasak: would 'unapproved' be a flag to queue then for that specific case? | 00:18 |
| rbasak | My plan is that "usd queue" will update all queue/{new,unapproved}/<release> tags as necessary. | 00:19 |
| nacc | ah ok | 00:20 |
| rbasak | Assuming you run that from something you have already done "usd clone" on. | 00:20 |
| nacc | right, this is all 'detached' from the usd side, right? local-only, i mean? | 00:20 |
| rbasak | One catch is that I need some way to know what package name to operate on. I'm not sure we store that currently. So I might ask for that to be added with "git config" at "usd clone" time or something. | 00:20 |
| nacc | usd git side, i meant | 00:20 |
| rbasak | Correct. All local only. | 00:20 |
| nacc | yeah, it's probably not a bad idea to stuff that somewhere | 00:21 |
| rbasak | Then, later, I might add something that pulls the entire queue for a release, or all stable releases, or all releases, clones them all, makes sure they're all up-to-date (rerunning "usd import") and then runs "usd queue" in all. | 00:21 |
| rbasak | Also perhaps "usd queue approve" or something to accept from the queue a given tag. | 00:22 |
| rbasak | As I'm storing the Launchpad queue object API URI in the tag, that should be reliable. | 00:22 |
| nacc | ah ok | 00:23 |
| rbasak | (or reject) | 00:23 |
| rbasak | I need to think about the CLI a little. | 00:23 |
| nacc | yeah that seems tricky | 00:23 |
| nacc | we can always mark that part as 'alpha' :) | 00:23 |
| rbasak | It's only a small set of people who can usefully use it, so I think that's feasible :) | 00:23 |
| nacc | and, presuming deps are installed, tab complete works now, so maybe that will help with the options too | 00:24 |
| rbasak | I saw that commit. Neat! | 00:24 |
| nacc | it's a bit slow, which i think is because of my ordering decisions, which can be fixed | 00:27 |
| nacc | but it does work, so little steps :) | 00:28 |
| rbasak | nacc: I've updated my branch (fast-forward) so it works but will rebase and squash later to tidy it up. | 00:43 |
| nacc | rbasak: ack, just ping me when you're ready for me to merge it in (even if just hte cleanup stack) | 00:45 |
| rbasak | Will do | 00:45 |
| nacc | rbasak: thanks! | 00:48 |
| nacc | rbasak: ah, so nice to remerge something i've merged before, it's already broken up (so `git fetch lpusip; usd merge lpusip/ubuntu/devel lpusip/debian/sid; git rebase -i [to drop the empty merge commits]`, puts me at a fully deconsructed state already | 00:53 |
| === JanC is now known as Guest39941 | ||
| === JanC_ is now known as JanC | ||
| === _salem is now known as salem_ | ||
| Mirv | mitya57: retrying pyqt5 i386 as lack of it is blocking Qt 5.7.1 transition and it seems qtwebengine is however now built for i386 | 11:35 |
| Mirv | mitya57: nope, still failed with "Depends: qtwebengine5-dev (>= 5.7.1+dfsg-3~) but it is not going to be installed", maybe it's unistallable for some reason | 11:40 |
| === jamespag` is now known as jamespage | ||
| Mirv | mitya57: ah, pyqt5 amd64 binaries are in new queue | 11:58 |
| tsdgeos | Mirv: what's holding Qt 5.7.1 landing? | 12:23 |
| tsdgeos | i see it marked as "Valid candidate" in the excuses page | 12:23 |
| Mirv | tsdgeos: did you read the lines below which you wrote? :) | 12:26 |
| tsdgeos | reading which kind of crazyness is this? | 12:26 |
| tsdgeos | i see, tx | 12:27 |
| === hikiko_ is now known as hikiko | ||
| acheronuk | Mirv: i386 still did not build, or did you prod it too soon for the amd64 indep packages to have published and be available? | 13:04 |
| acheronuk | E: Package 'libqt5webengine-data' has no installation candidate | 13:15 |
| acheronuk | so I guess needs to wait a bit | 13:15 |
| rbasak | pdeee: can you tell me the relationship between the python-letsencrypt, python-acme and python-certbot source packages please? Which replaced which? | 13:28 |
| rbasak | Is it that acme remains unchanged as the backend protocol library, and letsencrypt->certbot? | 13:30 |
| === hikiko_ is now known as hikiko|ln | ||
| rbasak | pdeee: I don't understand why I don't see a python-letsencrypt transitional package in src:python-certbot in the Xenial new queue. | 13:33 |
| rbasak | Only one for letsencrypt with no prefix. | 13:34 |
| rbasak | pdeee: I commented in the bug. | 13:45 |
| LocutusOfBorg | slangasek, FYI I syncd "libdfp" | 14:05 |
| Mirv | acheronuk: seems like that, now it's building | 14:08 |
| acheronuk | Mirv: so is my staging ppa stuff that was waiting on it :) | 14:09 |
| === hikiko|ln is now known as hikiko | ||
| === scottt is now known as Guest97906 | ||
| pete-woods | xnox: hi. just looking back at your change in indicator-network at this revision: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-network/trunk/revision/660 | 14:36 |
| pete-woods | in the maintscript you do etc/.../ instead of /etc/.../ | 14:36 |
| pete-woods | i.e. without the leading / | 14:36 |
| pete-woods | is that intentional, or a mistake? | 14:36 |
| pete-woods | cause it looks like the scripts are not successfully removing the old XDG files | 14:37 |
| pete-woods | just wanted to double-check before I blunder in and naïvely stuff a / in | 14:38 |
| cjwatson | looks like a clear mistake to me. lots of debhelper files don't need the leading / (and it's conventional to avoid it since the paths are really relative to the installation hierarchy), but .maintscript is just passed through to dpkg-maintscript-helper which does need the leading /. | 14:39 |
| pete-woods | cjwatson: thanks for having a look :) - will put a MR together to fix it, then | 14:41 |
| cjwatson | also IMO that should have a version in it somewhere | 14:41 |
| xnox | pete-woods, mistake. | 14:41 |
| pete-woods | Removing obsolete conffile /etc/xdg/autostart/indicator-network.desktop ... | 14:41 |
| pete-woods | woot, looks like it's behaving again now | 14:41 |
| xnox | pete-woods, but fixed seperately | 14:41 |
| xnox | pete-woods, https://launchpad.net/ubuntu/+source/indicator-network/0.9.0+17.04.20161223.3-0ubuntu2 | 14:41 |
| xnox | i think that needs remerging, and relanding. | 14:42 |
| xnox | cjwatson, there should be a version, but i did not know how to do it properly with substitution of magic version numbers in the silo. | 14:42 |
| cjwatson | doesn't have to be a version that exists, as long as it's comparable :-) | 14:42 |
| pete-woods | oh, did you land that without going through CI train? | 14:42 |
| cjwatson | (also I think bileto supports some kind of poorly-named hack along the lines of 0replaceme | 14:43 |
| cjwatson | ) | 14:43 |
| pete-woods | anyway | 14:43 |
| pete-woods | will try and make the same change again | 14:43 |
| pete-woods | cjwatson: would 0.9.0+17.04.20161223.3-0ubuntu1~ work as the version to compare? | 14:48 |
| pete-woods | (that's the revision that the conf file was removed from) | 14:48 |
| pete-woods | there are so many special characters in the bileto versions, I don't know what is greater or less than anything else | 14:48 |
| xnox | pete-woods, it should be the version that successfully removes it so 0.9.0+17.04.20161223.3-0ubuntu2~ and whatever new for xenial. | 14:48 |
| xnox | i'll try to find the docs for the replaceme stuff. | 14:49 |
| pete-woods | xnox: so I need to know the replaceme thing then, okay | 14:49 |
| pete-woods | also, a link to those docs would be great | 14:49 |
| pete-woods | I don't see, e.g. 0replaceme, in https://wiki.ubuntu.com/Bileto | 14:49 |
| dobey | grrrr | 14:51 |
| dobey | pete-woods: well apparently now you have to manually merge the changes from zesty, and then do a no change rebuild | 14:52 |
| pete-woods | dobey: indeed. always a bit annoying when this happens | 14:52 |
| dobey | or change the version in the maintscript to be @replaceme | 14:52 |
| pete-woods | dobey: i'm happy enough with 0replaceme, if I can find the correct string | 14:53 |
| cjwatson | pete-woods: use dpkg --compare-versions to test things out | 14:53 |
| cjwatson | (badly-named> the design basically assumes there's only ever one thing that might want to be replaced, and it isn't self-documenting) | 14:54 |
| cjwatson | pete-woods: https://wiki.ubuntu.com/DailyRelease/FAQ documents 0replaceme | 14:55 |
| dobey | pete-woods: it's "0replaceme" | 14:55 |
| cjwatson | albeit in stuff about symbols files, but same idea | 14:55 |
| dobey | (c++)"UbuntuOne::Token::addOAuthTimestamp(QString) const@Base" 0replaceme | 14:55 |
| cjwatson | in this case it should be 0replaceme~ though, I think | 14:55 |
| dobey | from a previous branch i landed | 14:55 |
| dobey | cjwatson: maybe, but i think the ~ might break it? | 14:56 |
| cjwatson | break it how? | 14:56 |
| dobey | 0replaceme~ != 0replaceme | 14:56 |
| cjwatson | scripts/vcs.sh: find debian/ -type f -print0 | xargs -0 perl -p -i -e "s/0replaceme/$VERSION/g" | 14:56 |
| dobey | oh ok | 14:56 |
| cjwatson | so I shouldn't think so | 14:56 |
| dobey | yeah if the regex is that dumb it's fine. i just didn't know how clever it was trying to be :) | 14:57 |
| dobey | pete-woods: ^^ so 0replaceme~ is what you want in the maintscript for the version | 14:57 |
| pete-woods | Cool, will stuff that in | 14:58 |
| LocutusOfBorg | hello, how do I fix this bug? https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/1557675 | 15:49 |
| ubottu | Launchpad bug 1557675 in xpdf (Ubuntu) "AppStream icon for xpdf.desktop" [Undecided,Fix released] | 15:49 |
| LocutusOfBorg | sorry https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1649660 | 15:49 |
| ubottu | Launchpad bug 1649660 in hedgewars (Ubuntu) "Gnome Software catalog entry missing for Hedgewars" [Undecided,Confirmed] | 15:49 |
| LocutusOfBorg | this one | 15:49 |
| Laney | LocutusOfBorg: http://appstream.ubuntu.com/zesty/universe/issues/hedgewars.html | 15:53 |
| Laney | same @ debian | 15:53 |
| LocutusOfBorg | thanks | 15:53 |
| LocutusOfBorg | so no icon is missing | 15:54 |
| LocutusOfBorg | wonderful | 15:54 |
| LocutusOfBorg | so adding a Comment section is enough | 15:55 |
| LocutusOfBorg | ta! | 16:03 |
| caribou | infinity: I had a question about silently changing a conffile for tftpd-hpa on Trusty | 16:09 |
| caribou | infinity: that's a discussion we had with rbasak recently | 16:09 |
| infinity | caribou: What's the question, and can I answer it with "don't do that"? | 16:10 |
| caribou | infinity: right now, tftpd-hpa will fail to start if the NIC is not available because it is listening on [::]:69 | 16:10 |
| caribou | infinity: the fix is to change it to :69 in the conffile. rbasak had worries about that triggering a conffile prompt upon update | 16:10 |
| infinity | Oh. Triggering a conffile prompt because a conffile was updated is exactly why the prompts exist. | 16:11 |
| caribou | infinity: and thought that we might sed it in the postinst, since :69 encompass the [::]:69 value and will work in every situation | 16:11 |
| infinity | No. Changing it in postinst is wrong. | 16:11 |
| caribou | infinity: I know, but it seemed to bother rbasak | 16:11 |
| caribou | rbasak: got a comment on this ? | 16:12 |
| rbasak | I said preinst, but I also decided that may not work. | 16:12 |
| caribou | rbasak: yes, sorry preinst | 16:12 |
| rbasak | I wondered if there was some way to work around a conffile prompt since the two are exactly equivalent, so we may be able to sed in all cases. | 16:12 |
| rbasak | But I'm not sure there is. | 16:12 |
| rbasak | Anyway. Someone wants a conffile change? Automatic referral to infinity :-P | 16:12 |
| infinity | Changing it in preinst is also wrong. :) | 16:13 |
| ogra_ | nah, just to a boit that says "don't do that !" | 16:13 |
| ogra_ | *bot | 16:13 |
| infinity | If they've customized their config, we assume they like the one they have, hence the prompt. | 16:13 |
| infinity | If they haven't touched it, they get the new one silently. | 16:14 |
| ogra_ | unless an insane developer mangled it from a maintainer script before :) | 16:14 |
| infinity | The default may be "bad", but we have to assume that if they've touched the file, they audited and decided they liked the bad default. | 16:14 |
| infinity | ogra_: And that developer will be flogged later. | 16:15 |
| ogra_ | :D | 16:15 |
| caribou | rbasak: infinity: I had a similar query regarding a conffile mod for a makedumpfile SRU | 16:16 |
| caribou | rbasak: infinity: I'm doing an SRU of a fix in Zesty that brought in two new values to a conffile. Those values are not required to be present in the conffile and can be added later to alter some timings. Would it be sufficient to add a mention in the README to avoid a conffile prompt ? | 16:16 |
| infinity | Now, that said, I don't see a conffile in tftpd-hpa... | 16:16 |
| LocutusOfBorg | Laney, how long will it take to regenerate that info on software catalog once hedgewars is uploaded? | 16:16 |
| Laney | LocutusOfBorg: Not long, few hours at most | 16:16 |
| LocutusOfBorg | ok I uploaded it a few seconds ago | 16:17 |
| LocutusOfBorg | so, do I need to apt update or is something automatic? | 16:17 |
| infinity | rbasak, caribou: /etc/default/tftpd-hpa is *not* a dpkg conffile, it's created by postinst. | 16:17 |
| rbasak | Oh | 16:18 |
| infinity | rbasak, caribou: And that throws all your concerns about dpkg conffile prompts out the window. It's managed by debconf. | 16:18 |
| rbasak | caribou: sorry! | 16:18 |
| caribou | infinity: sorry! | 16:18 |
| caribou | :) | 16:18 |
| ogra_ | heh | 16:18 |
| Laney | LocutusOfBorg: Did you run desktop-file-validate? | 16:19 |
| Laney | I think that you made a syntax error | 16:19 |
| rbasak | Well then we can just sed it. Though policy does still require that we preserve user changes. | 16:19 |
| infinity | Well, "managed". It seems to be a broken setup that doesn't allow debconf to reconfigure. :P | 16:19 |
| rbasak | And do we also need to manipulate the debconf db? | 16:19 |
| LocutusOfBorg | Laney, I did run it | 16:19 |
| caribou | rbasak: the sed would only change it if it was set to the previous default ([::]:69] | 16:19 |
| infinity | rbasak: debconf is not a registry, you should never need to touch the db. | 16:20 |
| caribou | ([::]:69) | 16:20 |
| Laney | LocutusOfBorg: share/hedgewars/Data/misc/hedgewars.desktop: error: file contains line "Comment: Funny turn-based artillery game, featuring fighting hedgehogs!", which is not a comment, a group or an entry | 16:20 |
| infinity | rbasak: If maintainer scripts aren't written to prefer the config file over the DB, that's a bug. | 16:20 |
| LocutusOfBorg | DAMN | 16:20 |
| LocutusOfBorg | you are right | 16:20 |
| LocutusOfBorg | I didn't quilt push | 16:20 |
| rbasak | infinity: what if debconf suggested the previous default to the user, and then stored it? | 16:20 |
| LocutusOfBorg | :/ | 16:20 |
| LocutusOfBorg | dpkg-buildpackage unapplies patches | 16:20 |
| rbasak | rbasak: then a future dpkg-reconfigure would restore the old default, no? | 16:20 |
| infinity | rbasak: See above. The authoritative version is always the config file, never the debconf DB, per policy. | 16:20 |
| rbasak | Ah, so the config script should read the config file over the DB when prompting for future defaults? That makes sense, thanks. | 16:21 |
| LocutusOfBorg | ta | 16:21 |
| infinity | rbasak: And, indeed, the tftpd-hpa package does that correctly (sources the config file, stores the values, then asks questions). | 16:21 |
| cjwatson | picking the current state out of the config file and stuffing it into debconf as the default value before asking a question is OK though | 16:21 |
| cjwatson | yeah, that | 16:21 |
| infinity | rbasak: What I don't see it doing is actually rewriting the config file on reconfigure. :) | 16:21 |
| infinity | But hey, minor oops. | 16:22 |
| Laney | LocutusOfBorg: Might want to cancel the builds to save the environment a bit. :) | 16:22 |
| LocutusOfBorg | indeed | 16:23 |
| infinity | caribou: As to your makedumpfile thing, you can either ship a new conffile with the new keys or not. Your call as the maintainer. | 16:24 |
| infinity | caribou: If it behave correctly without the keys specified, mentions of them in changelog, READMEs, or manpages are all fine. *shrug* | 16:25 |
| caribou | infinity: the new keys are only comments for reference | 16:25 |
| caribou | infinity: k, I started to have second thoughts after rbasak's comments about tftpd-hpa | 16:25 |
| infinity | caribou: To be fair, people will see that conffile prompt on 16.04->18.04 upgrades anyway, so you can't avoid it forever. | 16:25 |
| infinity | caribou: (Well, they'll see it if they changed their local copy) | 16:26 |
| infinity | conffile prompts aren't evil, what's evil is when packages alter conffiles outside the proper dpkg mechanism and create *spurious* prompts. | 16:26 |
| infinity | Users being prompted because *they* changes the file and then you shipped a new one is working as designed. | 16:27 |
| infinity | s/changes/changed/ | 16:27 |
| caribou | infinity: yeah,never worried too much about it as I saw it as expected behavior | 16:27 |
| rbasak | One problem though is that some people never see conffile prompts (unattended upgrades, etc). So then default conffile handling behaviour takes over, which I think may be confold? And then that defeats some of the point of fixing it, if the goal is to get those users as well. | 16:28 |
| rbasak | This applies to server stuff quite a bit, where a commonly conffiles have to be edited for their packages to be useful. | 16:28 |
| infinity | Default should be confold, yeah. I'd like to think people who run unattended-upgrades on critical infrastructure also go looking for .dpkg-new in /etc occasionally. | 16:29 |
| infinity | But I bet they don't. | 16:29 |
| infinity | I wonder if we could motd snippet that or something. | 16:29 |
| cjwatson | I've gone through all the stages of grief on this and eventually decided that conffile prompts (or ucf) are still the least painful thing. | 16:29 |
| infinity | "A recent upgrade resulted in N unmerged conffiles in /etc" | 16:29 |
| rbasak | That's a good idea. | 16:29 |
| cjwatson | After having years of accretion of weird sshd_config editing runes in openssh-server.postinst. | 16:30 |
| cjwatson | infinity: Very Gentoo :-) | 16:30 |
| caribou | yeah, I like the fact of being told about things that should be looked at | 16:30 |
| cjwatson | (It has something very similar IIRC) | 16:30 |
| infinity | cjwatson: Oh, I thought you were punning about emerge. | 16:30 |
| infinity | cjwatson: But yeah, if they have something like this, they might be doing something right. rbasak's not wrong that there's a general conflict between silent upgrades and conffile updates. Post-facto notification seems not entirely bad. | 16:31 |
| cjwatson | Gentoo doesn't have any automatic conffile merging, so it *has* to have a prompt at the end to tell you to apply changes. But that's not to say it's a bad idea. | 16:31 |
| infinity | I wish we'd done etckeeper-by-defalt long ago, so we could just say "/etc has unresolved conflicts, fix plz". | 16:36 |
| infinity | Well, and hook it into dpkg, so a conffile update is actually a merge attempt that vomits to conffile.rej on failure, etc. | 16:37 |
| infinity | Woulda shoulda coulda. | 16:37 |
| infinity | I suppose we still could some day. | 16:38 |
| === Foxtrot is now known as foxtrot | ||
| infinity | Though, I guess working toward the new world oder of "defaults in /usr, overrides in /etc" is a better use of time. | 16:40 |
| infinity | Maybe we can actually have an empty /etc by 2038. | 16:40 |
| infinity | Well, empty except for /etc/rmt, because that bit of backward compatibility is super important to someone from 1972. | 16:42 |
| philroche | Hi guys, I'm hoping someone can steer me in the right direction. Earlier today gce-compute-image-packages was accepted in to xenial-proposed pocket but the binaries are not being published to the repository. The amd64 build is stuck "Pending publication" (See https://launchpad.net/ubuntu/+source/gce-compute-image-packages) Is there anything I need to do to get past that stage or is it just a matter of waiting? | 17:22 |
| nacc | philroche: i'm guessing here, but it's a new src and binary, so it will need approval by an AA to migrate to -proposed. | 17:27 |
| seb128 | could somebody from the SRU team copy https://launchpad.net/ubuntu/+source/evolution/3.18.5.2-0ubuntu3.1 over from xenial-proposed to updates? the update was accepted without a bug reference and is probably stucked because of that but the change is fine and has been tested | 17:28 |
| seb128 | bdmurray, ^ you maybe? | 17:28 |
| bdmurray | seb128: looking | 17:29 |
| seb128 | bdmurray, thanks | 17:29 |
| cjwatson | nacc is correct; the binaries are new in that suite so it's in the NEW queue for approval. | 17:29 |
| nacc | philroche: --^ | 17:29 |
| bdmurray | seb128: released it | 17:31 |
| philroche | cjwatson: nacc: Thanks | 17:31 |
| seb128 | bdmurray, thanks! | 17:31 |
| nacc | philroche: note that you can also see that from https://launchpad.net/ubuntu/+source/gce-compute-image-packages/20160930-0ubuntu3~16.04.0 (the '(New)') next to the build | 17:34 |
| philroche | nacc: Ah. I see thanks | 17:34 |
| nacc | philroche: and you can also see it here: https://launchpad.net/ubuntu/xenial/+queue | 17:35 |
| philroche | nacc: This process is new to me so thanks for that. | 17:45 |
| nacc | philroche: np, I often forget about it too :) | 17:46 |
| nacc | philroche: / it's new to me as well | 17:46 |
| sil2100 | Laney: hey! Would you mind if I re-upload the dbus package with just the ssh/logind workaround? | 17:48 |
| Laney | sil2100: If you take over the other fix too | 17:49 |
| sil2100 | Laney: what do you mean? | 17:50 |
| sil2100 | Laney: I see it's marked as verification-failed right now and causing some issues, right? | 17:50 |
| sil2100 | We just want to get the ssh fix released as soon as possible as many users are waiting for it | 17:50 |
| Laney | sil2100: Yes, but it's not buggy itself. If you want to revert it to get your other fix in, then I would appreciate you taking care of putting it back when it is safe to do so. | 17:52 |
| sil2100 | Laney: ah, like this | 17:52 |
| sil2100 | Ok | 17:52 |
| sil2100 | Laney: I can do that sure | 17:53 |
| Laney | Cheers | 17:53 |
| nacc | rbasak: still around? | 18:01 |
| mitya57 | Mirv, it looks like pyqt5 built everywhere now. | 18:11 |
| Mirv | mitya57: yes. if you or someone has time, look at the qtquickcontrols examples installability issue on excuses page (I'm going to sleep now already) | 18:46 |
| Mirv | qtquickcontrols5-examples/amd64 unsatisfiable Depends: qml-module-qtquick-extras etc | 18:47 |
| Mirv | acheronuk: ^ note, at least that found from excuses page, no need yet to decipher update_output more | 18:48 |
| bdmurray | Laney: Do you know what Code 20 means in autopkgtest results? | 18:50 |
| davmor2 | bdmurray: it's a countdown to total global annihilation you really need to stop it before it gets to 0 ;) | 18:53 |
| mitya57 | Mirv, qtquickcontrols5-examples is installable in my amd64 chroot. | 18:53 |
| mitya57 | Though, qml-module-qtquick-extras is the only dependency that is in universe, so probably that is the issue. | 18:55 |
| mitya57 | Maybe someone can promote it to main? (It comes from qtquickcontrols-opensource-src source which is in main.) | 18:57 |
| pdeee | rbasak, hlieberman and RAOF may be better equipped to answer your questions, but | 19:00 |
| pdeee | AFAICT python-certbot Replaces: python-letsencrypt | 19:01 |
| pdeee | python-acme is a dependency of either of those | 19:03 |
| pdeee | not sure how that relates to source packages, though | 19:03 |
| bdmurray | jbicha: How was bug 1649995 fixed in zesty? Just setting it to Fix Released doesn't help me from an SRU perspective. | 20:20 |
| ubottu | bug 1649995 in gnome-online-accounts (Ubuntu Yakkety) "Replace Google API key used by GNOME services" [High,In progress] https://launchpad.net/bugs/1649995 | 20:20 |
| bdmurray | zul: The existing nova-lxd SRU hasn't been verified (bug 1642274). Do you want the new upload to supersede it? | 20:29 |
| ubottu | bug 1642274 in nova-lxd (Ubuntu Yakkety) "[SRU] newton nova-lxd 14.0.1 point release " [High,Fix committed] https://launchpad.net/bugs/1642274 | 20:29 |
| zul | bdmurray: lemme check around | 20:30 |
| bdmurray | zul: okay | 20:30 |
| === salem_ is now known as _salem | ||
| smoser | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html <-- why is cloud-initramfs-tools there ? | 20:36 |
| smoser | 'missing build' seems relevant, but there is a build | 20:36 |
| hlieberman | rbasak: Hiya. Debian maintainer of the certbot stuff here. | 20:37 |
| hlieberman | rbasak: So, yes, you're correct: python-acme stays the same, python-letsencrypt => python-certbot, letsencrypt => certbot, python-letsencrypt-apache => python-certbot-apache | 20:37 |
| hlieberman | Generally, users wouldn't have installed python-letsencrypt directly, so there's no transitional package there. | 20:38 |
| cjwatson | mitya57: done | 20:41 |
| hlieberman | If they did, they could be using plugins that wouldn't work in the new namespace. | 20:45 |
| jbicha | bdmurray: it was fixed in gnome-online-acccounts 3.22.3-1, I've added that to Other Info on the bug now | 20:48 |
| jbicha | we have to figure out how to get evolution through phased-updates though… | 20:49 |
| bdmurray | jbicha: Do you know anything about this new crash? | 20:52 |
| jbicha | no, it does look new; I can ping the evolution maintainers about it | 20:54 |
| jbicha | actually it was evolution-data-server that needed to be updated first but that's fully phased so we don't need to let that stop us from updating g-o-a now | 20:57 |
| bdmurray | looking at the error tracker I don't see any other crashes with webkit_editor | 20:58 |
| jbicha | right and it was in yakkety that evolution switched from webkit1 to webkit2 so it's probably new to yakkety | 21:01 |
| jbicha | bdmurray: thanks. Could you look into the libicns yakkety SRU? it's needed for hdhomerun-config-gui to build there | 21:21 |
| === smoser` is now known as smoser | ||
| nacc | juliank: do you know what's going on with LP: #1522675? seen an uptick lately in people hitting it on #ubuntu | 21:46 |
| ubottu | Launchpad bug 1522675 in update-notifier (Ubuntu) "Warning messages about unsandboxed downloads" [Medium,Confirmed] https://launchpad.net/bugs/1522675 | 21:46 |
| juliank | nacc: More users upgrading to >= xenial? | 21:47 |
| juliank | Someone may want to play with update-notifier's use of apt-helper and have it download stuff into a directory writeable by the _apt user | 21:48 |
| nacc | juliank: checking on the current user who brought it up | 21:49 |
| juliank | Same for synaptic apparently. | 21:51 |
| juliank | Funny how ubottu says bug in update-notifier (Ubuntu) but the link it gives redirects to https://bugs.launchpad.net/debian/+source/synaptic/+bug/1522675 | 21:51 |
| ubottu | Launchpad bug 1522675 in update-notifier (Ubuntu) "Warning messages about unsandboxed downloads" [Medium,Confirmed] | 21:51 |
| nacc | juliank: in this case, user already ahd fonts package installed, and a regular update failed, it seems (on 16.04). Not dist-upgrading. | 21:52 |
| nacc | juliank: multiple tasks in same bug | 21:52 |
| juliank | Well, nothing is failing there | 21:52 |
| nacc | juliank: can be referred to by multiple src pkgs (therefore) | 21:52 |
| juliank | nacc: I think you really meant bug 1651923 | 21:53 |
| ubottu | bug 1651923 in apt (Ubuntu Yakkety) "apt https method decodes redirect locations and sends them to the destination undecoded." [Medium,Triaged] https://launchpad.net/bugs/1651923 | 21:53 |
| nacc | juliank: ah that's the underlying spaces issue? | 21:54 |
| juliank | There's a workaround in zesty, and I'll backport this shortly to yakkety and xenial, but I first want to write a regression test case and optimally do the whole thing in an upstream release (scheduled in 4-5 days) | 21:55 |
| nacc | juliank: ack, just trying to get context so I can provide the best answer(s) in #ubuntu | 21:55 |
| nacc | juliank: right now, folks are manually installing the .deb from unstable | 21:55 |
| nacc | for the fonts package | 21:55 |
| juliank | That works too as it skips the redirector or something | 21:56 |
| nacc | yeah, i think the fonts package (debian) has changed that as well | 21:57 |
| nacc | so it's like there are two fixes :) (for that particular package) | 21:57 |
| juliank | Yeah, but there's others mentioned in the bug log | 21:57 |
| nacc | yep, presumably any of the ones that are downloading something during the install could be affected | 21:57 |
| jbicha | I'm guessing bug 1607535 is the same issue | 21:57 |
| ubottu | bug 1607535 in msttcorefonts (Ubuntu) "ttf-mscorefonts-installer 3.4+nmu1ubuntu2 fails to install core fonts and should be updated to version 3.6 from Debian" [Medium,Confirmed] https://launchpad.net/bugs/1607535 | 21:57 |
| nacc | juliank: thanks for the bug link and clarification! | 21:57 |
| nacc | jbicha: ack, that's the one i saw yesterday | 21:58 |
| juliank | If anyone is an http expert: I only urlencoded the path component of URLs we give to curl. I wonder if I should also urlencode some more parts - but I'm not sure. | 21:58 |
| nacc | jbicha: dunno if you want to update with references to the other two bugs | 21:58 |
| jbicha | if 1651923 is the main bug, we can duplicate the other bugs to there | 21:58 |
| juliank | jbicha: Keep one open for the package update request? | 21:59 |
| juliank | It's the same underlying issue of course, but a package update obviously also entails other things and is good to have in either case. | 21:59 |
| jbicha | oh for ttf-mscorefonts? I'll open a different bug requesting that be updated | 22:00 |
| juliank | Yes. I remember someone tried merging that yesterday, but it was a bit complicated. | 22:01 |
| rbasak | hlieberman: hi | 22:33 |
| rbasak | hlieberman: still, it makes python-letsencrypt un-updateable, so I think we do need an update for it bundled with this SRU. | 22:33 |
| hlieberman | rbasak: A dummy? | 22:34 |
| rbasak | hlieberman: we could drop letsencrypt from src:python-letsencrypt, and the same for apache if that works the same way. | 22:34 |
| rbasak | hlieberman: since src:python-certbot is taking the package over. | 22:34 |
| hlieberman | src: python-letsencrypt can be RMed. | 22:35 |
| hlieberman | It's completely replaced. | 22:35 |
| rbasak | hlieberman: not from a stable release, unfortunately. | 22:35 |
| rbasak | We could replace it with an empty package, but users may still theoretically be using python-letsencrypt ("import letsencrypt"), and I don't think there's any need to drop that from a stable release here. | 22:36 |
| hlieberman | python-certbot Break's python-letsencrypt. | 22:36 |
| rbasak | Oh. | 22:36 |
| rbasak | Well, that's something that should be discussed in the bug then. | 22:36 |
| rbasak | Because it's a use case that could exist that we definitely are breaking. | 22:37 |
| hlieberman | Because it ships a symlink for /usr/bin/letsencrypt and Provides: letsencrypt. | 22:37 |
| rbasak | Surely that's letsencrypt, not python-letsencrypt? | 22:37 |
| rbasak | Uh, sorry. | 22:37 |
| rbasak | Surely that's certbot, not python-certbot? | 22:37 |
| hlieberman | Oh, yeah. Sure. I suppose someone could theoretically want python-letsencrypt but not letsencrypt, though it would be very strange. | 22:38 |
| rbasak | Why aren't they the same package? | 22:38 |
| hlieberman | The library isn't really meant to stand alone, like python-acme is. | 22:39 |
| hlieberman | They're the same source package. | 22:39 |
| rbasak | Why aren't they the same binary package? | 22:39 |
| hlieberman | Sorry; I'm on my cell phone, so I might not be explaining this very well. | 22:40 |
| rbasak | If it's not meant to stand alone, shouldn't it be in /usr/lib/certbot? | 22:40 |
| rbasak | https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs "4.2.1 Programs Shipping Private Modules | 22:40 |
| rbasak | " | 22:40 |
| hlieberman | It's can't be private in that sense, since a third package does depend on it. python-certbot-apache. | 22:41 |
| rbasak | I see, OK. | 22:41 |
| rbasak | Why must python-certbot Breaks: python-letsencrypt? | 22:42 |
| hlieberman | And python-certbot-nginx, though that's not relevant. | 22:42 |
| rbasak | AFAICT, they provide different files. | 22:42 |
| hlieberman | It doesn't. I'm sorry, I meant s/python-// before. | 22:42 |
| hlieberman | That's my fault. | 22:42 |
| hlieberman | certbot breaks letsencrypt. | 22:43 |
| rbasak | Actually it looks like it does. | 22:43 |
| rbasak | In queue/xenial/new | 22:43 |
| rbasak | Package: python-certbot | 22:43 |
| rbasak | Breaks:...python-letsencrypt (<= 0.6.0) | 22:43 |
| rbasak | Replaces: python-letsencrypt | 22:44 |
| hlieberman | Ah -- are you going to be around in a bit? This really should wait until I'm actually in front of my computer. | 22:44 |
| rbasak | I appreciate that's fine for ongoing development. | 22:44 |
| rbasak | But for the SRU, maybe we could drop that? | 22:44 |
| rbasak | I'll be going to bed soon, sorry. We can chat another time though, just ping me. | 22:44 |
| hlieberman | Since I am clearly not word-ing very well. | 22:44 |
| hlieberman | Sure thing. I'll put something in the bug and try and catch you tomorrow. | 22:44 |
| rbasak | OK. I appreciate you getting in touch. Thank you for helping with this. | 22:45 |
| hlieberman | Of course! Sorry for the confusion | 22:45 |
| rbasak | No problem. It's confusing by its nature. I don't mind working through it, just want to get to the bottom of it and reach an agreement and get it done :) | 22:45 |
| hlieberman | Yeah. The differences between Debian and Ubuntu is just slight enough to really trip me up, too. | 22:48 |
| hlieberman | Like with Maintainer. I know I knew that, once upon a time. | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!