| RAOF_hates_all_c | Yeah! It was during an automatic upgrade, too. | 00:00 |
|---|---|---|
| RAOF_hates_all_c | So everything was working, and then the keyboard and mouse stopped responding to anything. | 00:00 |
| infinity | RAOF_hates_all_c: Maybe it upgraded the PS/2 driver and blew up on rescan. | 00:00 |
| infinity | RAOF_hates_all_c: If so, the USB keyboard trick might work. | 00:00 |
| RAOF_hates_all_c | That's my current theory, yes. | 00:00 |
| infinity | *handwavy* | 00:00 |
| RAOF_hates_all_c | Alternatively, I can wait for it to drop from suspend to hibernate and then boot from USB. | 00:01 |
| RAOF_hates_all_c | But maybe I can be bothered to find a USB keyboard... | 00:01 |
| RAOF_hates_all_c | So much effort, though! | 00:01 |
| RAOF_hates_all_c | Much more enjoyable to bitch on IRC using $BACKUP_LAPTOP | 00:02 |
| infinity | Hah. | 00:02 |
| infinity | USB mouse might be easier? :P | 00:02 |
| RAOF_hates_all_c | I'm not sure I could find one of those, actually. | 00:02 |
| mwhudson | rdp? | 00:02 |
| infinity | Either one should get you to a reboot button. | 00:02 |
| sarnold | any chance you've got an sshd running on it? | 00:02 |
| infinity | mwhudson: rdp implies either (a) it's always open (I'd assume not) or (b) he has input devices to turn it on. | 00:02 |
| lifeless | RAOF_hates_all_c: what if you toggle it on and while its resuming you'r still doing the 5 second hold of death ? | 00:03 |
| mwhudson | true | 00:03 |
| infinity | RAOF_hates_all_c: Alternately, maybe you hit a magic Fn+F combo that swapped internal/external input (or, the driver "toggled" that for you), and hammering Fn and all your function keys will fix it? :) | 00:03 |
| RAOF_hates_all_c | lifeless wins! | 00:03 |
| lifeless | \o/ | 00:04 |
| lifeless | thank you, thank you, I take requests. | 00:04 |
| infinity | RAOF_hates_all_c: Next step: uninstall Windows. | 00:04 |
| lifeless | mwhudson: wiki login in suspiciously slow but worked | 00:04 |
| lifeless | mwhudson: just had to be awesomely patient, if you mean w.u.c | 00:05 |
| mwhudson | lifeless: yeah i think something got restarted, i'm in now | 00:05 |
| RAOF_hates_all_c | Woot! | 00:48 |
| RAOF_hates_all_c | The laptop boots *much* better when a kernel is installed. | 00:48 |
| infinity | RAOF_hates_all_c: Kernels are overrated. | 00:50 |
| pitti | Good morning | 06:11 |
| dholbach | good morning | 06:54 |
| pitti | seb128: so it seems you already fixed all the FTBFS in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+packages ? | 07:01 |
| LocutusOfBorg1 | hi folks, what happened to the Debian automatic import? | 07:26 |
| LocutusOfBorg1 | I see many packages that hasn't been syncd | 07:26 |
| infinity | LocutusOfBorg1: cjwatson noticed it was a bit broken last night before he went to bed, I imagine he'll poke at it this morning to see why. | 07:29 |
| infinity | pitti: Can I get you to look at the apt SRU in trusty? It's point-release crticial. | 07:29 |
| pitti | infinity: yup | 07:29 |
| infinity | pitti: Explanation of the patch can be gotten from reading between the lines in the referenced Debian bug. Ish. | 07:30 |
| LocutusOfBorg1 | infinity, thanks, I saw the breakage right now | 07:30 |
| infinity | pitti: It's tested here and works. | 07:30 |
| LocutusOfBorg1 | http://packages.debian.org/changelogs/pool/main/p/python-3to2/python-3to2_1.1.1-1/changelog.txt: HTTP Error 404: Not Found | 07:30 |
| LocutusOfBorg1 | http://metadata.ftp-master.debian.org/changelogs/main/p/python-3to2/python-3to2_1.1.1-1_changelog | 07:30 |
| LocutusOfBorg1 | this seems to be the right link now | 07:30 |
| pitti | infinity: ah, not fixed for wily yet either? | 07:30 |
| infinity | pitti: No, I'll do wily, vivid (and I suspect precise too, haven't tested there yet) Soon(tm), but the clock's ticking on 14.04.3, so that gets love first. | 07:31 |
| pitti | infinity: ack | 07:31 |
| infinity | pitti: I think that single line has been changed in apt about 5 times in the last 6 months. I suspect it's going to wear out soon. | 07:34 |
| LocutusOfBorg1 | can anybody please kick of python3-3to2 from the archive? | 07:34 |
| pitti | seb128, doko: So, I'll start weeding through https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org until/unless you give me something more urgent? | 07:34 |
| LocutusOfBorg1 | the new binary in python-3to2 has that binary now | 07:34 |
| infinity | pitti: Hopefully (until David decides to rewrite the whole autoremove feature), this is the last fix. :P | 07:35 |
| pitti | infinity: famous last words | 07:35 |
| infinity | pitti: Yeah, seriously. | 07:35 |
| infinity | pitti: I'm beginning to wish I hadn't reported the first bug that started this all. | 07:35 |
| infinity | pitti: Once this builds, I get to apply still more hacks to livecd-rootfs in my PPA, test build all the point release livefses AGAIN, and then, I think, we're set. With a week to spare. | 07:39 |
| infinity | Fingers crossed. | 07:40 |
| seb128 | pitti, wfm | 07:46 |
| pitti | wgrant: argh, I screwed up! | 07:55 |
| pitti | wgrant: seems my britney changes have some bug that caused a lot of stuff on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html to migrate | 07:55 |
| pitti | wgrant: but have test failures | 07:55 |
| pitti | wgrant: I'll start investigating, but it might be that we need some Launchpad magic for reverting this :/ | 07:56 |
| wgrant | pitti: When did this happen? | 07:56 |
| wgrant | Do you have an example package? | 07:56 |
| pitti | wgrant: some 20 mins ago | 07:56 |
| pitti | wgrant: the first one on the page, for example | 07:56 |
| pitti | for most it's probably okay, as we have a couple of broken tests | 07:56 |
| pitti | wgrant: I'll go through the "valid candidate"s now and compile a list of stuff that we need to revert/handle | 07:57 |
| wgrant | cjwatson: ^^ fyi | 07:57 |
| wgrant | pitti: This shouldn't require any particular LP magic, though. | 07:57 |
| wgrant | pitti: Reverting packages is possible, I think there might even be a script to do it. | 07:57 |
| pitti | wgrant: yeah, hopefully; just a warning | 07:57 |
| wgrant | It is ugly, though. | 07:57 |
| infinity | It's possible, but please don't unless absolutely necessary. | 07:58 |
| wgrant | It would be easier if they weren't published. | 07:58 |
| wgrant | Which they're not, it seems | 07:58 |
| infinity | Since you need to check rdeps, make sure you're not making life worse, plus you've left users who upgraded high and dry. | 07:58 |
| wgrant | So we could stop the publisher and delete them before they supersede the old ones, if we decide to do that in the next minute or so | 07:58 |
| pitti | e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pycurl | 07:58 |
| pitti | this is again a case where the migration was premature, but harmless | 07:58 |
| infinity | pitti: Go through the list of premature promotions and make some value judgements. | 07:59 |
| pitti | infinity: it doesn't migrate uninstallable/FTBFS stuff, just test regressions, so it shoudln't cause new uninstallability | 07:59 |
| infinity | pitti: In most cases, I think we'll probably just want to live with it. | 07:59 |
| pitti | infinity: yep, that's what I'm doing now | 07:59 |
| pitti | right | 07:59 |
| infinity | pitti: No, I meant that reverting could cause breakage. :P | 07:59 |
| pitti | in particular, python3-defaults has not been promoted yet (adding 3.5 as supported version) | 07:59 |
| infinity | pitti: Promotion should be fine, except for the part where we ignored tests. But, hey, we used to do that for every package. | 08:00 |
| infinity | pitti: I assume you've reverted or fixed your britney oops? | 08:00 |
| pitti | infinity: I reverted britney, yes | 08:00 |
| lifeless | pitti: that sounds *so* wrong | 08:01 |
| pitti | I don't yet have any idea why this happened, and I want to go through the current promotions before looking at that | 08:01 |
| infinity | .me nods. | 08:01 |
| * infinity too. | 08:01 | |
| pitti | sorry about the mess -- here's to writing tests that don't prevent breakage :/ | 08:01 |
| * lifeless raises the glass | 08:01 | |
| pitti | *clink* | 08:01 |
| infinity | pitti: It's the classic QA governance dilemma, who tests the testsuite? | 08:02 |
| pitti | Riddell: see ^ -- a lot of KDE 5.10 -> 5.12 just landed in wily because the kdelibs4support test regression got ignored | 08:04 |
| pitti | Riddell: where on a scale of "intended -- okay -- OMGrevert" is that? | 08:04 |
| pitti | (the kdelibs4support test regression happenend much earlier, FTR, in 5.10 already) | 08:05 |
| Riddell | mm, I've not made any changes recently | 08:05 |
| Riddell | pitti: which ignore is that? | 08:06 |
| pitti | Riddell: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html e. g. the topmost entry | 08:06 |
| pitti | Riddell: or solid, kitemviews, etc. | 08:06 |
| lifeless | infinity: the test test suite suite | 08:07 |
| lifeless | infinity: actually more seriously, depends on known unknowns or unknown unknowns. | 08:07 |
| pitti | that was definitively an unknown unknown | 08:07 |
| infinity | Riddell: The kdelibs4support regression looks like one failing test. Shouldn't be hard to hunt. If I were you, I'd just let pitti's screwup go and enjoy the free promotions (and find the test failure). | 08:08 |
| doko | pitti, the list is fine, maybe give those packages in main priority | 08:09 |
| pitti | doko: ack, good idea (will continue after the britney SNAFU) | 08:09 |
| infinity | pitti: Also, still no browser-friendly content headers before switching to the new shiny? :( | 08:09 |
| pitti | Riddell: my main question to you is whether you are fine with 5.12 landing in wily now | 08:09 |
| Riddell | pitti: yes I'm all for it | 08:10 |
| pitti | infinity: I spent like an hour on that, there's no effing way to do that :( | 08:10 |
| pitti | (I sent a summary to bug 1474271) | 08:10 |
| ubottu | bug 1474271 in Auto Package Testing "fix MIME type of log.gz" [Medium,Triaged] https://launchpad.net/bugs/1474271 | 08:10 |
| pitti | Riddell: ok, thanks | 08:10 |
| infinity | pitti: Humor me, what happens if you serve/link it as foo.txt.gz? | 08:11 |
| infinity | pitti: Depending on the httpd in play, it might decide to do all the right things for you at that point. | 08:11 |
| pitti | infinity: I actually tried all combinations of *.txt.gz, *.gz, Content-Type:, and Content-Encoding: | 08:12 |
| infinity | pitti: Hrmph. Kay. | 08:12 |
| pitti | infinity: the httpd is swift in this case | 08:12 |
| pitti | we could store the logs uncompressed, but they'll get quite a bit larger then | 08:12 |
| infinity | pitti: I could "fix" it with a transparent apache sitting in front, but pretty sure there's got to be a cleaner way. :P | 08:12 |
| pitti | yeah, the bug is still on my list, but less important -- opening in gedit works okayish | 08:13 |
| wgrant | pitti: Hm, Content-Encoding: gzip should work fine | 08:14 |
| wgrant | pitti: We totally don't do this in Launchpad: | 08:14 |
| wgrant | if filename.endswith('txt.gz'): | 08:14 |
| wgrant | encoding = 'gzip' | 08:14 |
| infinity | pitti: FWIW, LP's correctly-behaving logs are Content-Encoding: x-gzip | 08:14 |
| wgrant | mimetype = 'text/plain; charset=utf-8' | 08:14 |
| wgrant | Hahahahaha "correctly-behaving" | 08:14 |
| pitti | slangasek: to confirm, promoting the no-change rebuilds for 3.5 are "harmless" (although unintended), so I don't think we need to revert those, right? | 08:14 |
| infinity | wgrant: Correct, per my browser. ;) | 08:14 |
| pitti | wgrant: yes, I did set Content-Encoding:, but swift doesn't send it or the browser doesn't take it into account | 08:14 |
| infinity | wgrant: Curious that you push encoding=gzip, but twisted insisted in x-ifying it. | 08:15 |
| pitti | wgrant: see https://bugs.launchpad.net/auto-package-testing/+bug/1474271/comments/1 | 08:15 |
| ubottu | Launchpad bug 1474271 in Auto Package Testing "fix MIME type of log.gz" [Medium,Triaged] | 08:15 |
| pitti | so with "Content-Type: text/plain; charset=UTF-8" and the ignored COntent-Encoding, you see the gzipped garbage inline | 08:15 |
| wgrant | pitti: Ah, I guess Swift could well realise that what you're doing is completely wrong. | 08:16 |
| infinity | So, I'm talking to an apache here, not "swift". Is that a proxy, or do you have some control over that apache and its config? | 08:17 |
| infinity | Oh, I assume you'd have no control yourself, since it seems to be a shared prodstack resource. Hrm. | 08:18 |
| infinity | pitti: Did you revert the attempt to set Content-Type, etc? | 08:18 |
| pitti | slangasek, infinity: so I went through all the promotions; it's basically KDE 5.12 (already cleared with Riddell), a bunch of python 3.5 no-change rebuilds, some packages whose tests now succeed on the new infra (a lot was blocked on sqlalchemy), and some harmless updates; I didn't import the test regressions from the new r-base, as they come from debian and nobody looks at those anyway, so we now | 08:23 |
| pitti | consider those as "always failed" | 08:23 |
| pitti | so I think by and large we are okay | 08:23 |
| pitti | *phew* | 08:23 |
| pitti | curiously test regressions are holding up *some* package updates, but not most of them; I'll chase that bug now | 08:24 |
| pitti | wgrant, cjwatson: ^ panic mode off | 08:24 |
| pitti | infinity: right, it's ProdStack's swift; this might be RT matter, but I think this is by and large a browser problem that it ignores Content-Encoding:. | 08:25 |
| pitti | infinity: I never rolled this out as it didn't work | 08:25 |
| pitti | slangasek, infinity: pretty much the only "questionable" promotion that I found is https://launchpad.net/ubuntu/+source/python-setuptools/18.0.1-1 | 08:25 |
| infinity | pitti: Browser's don't ignore content-encoding though... | 08:26 |
| infinity | pitti: So, I'd be curious to see the bits you tried, or play myself a bit. | 08:26 |
| pitti | that or python3-defualts broke tox, python-html2text, and ipython; but I suspect that it's the py3.5 transition, checking logs | 08:26 |
| infinity | pitti: Seems a bit broken if setuptools was breaking as-installed tests. Would be more likely to cause build failures, no? | 08:27 |
| infinity | pitti: Odds are it wasn't to blame. | 08:28 |
| pitti | yeah, the logs of those look like it was py3.5, not setuptools | 08:28 |
| pitti | so, I think by and large I was lucky in my screwup | 08:28 |
| infinity | Yay luck. | 08:28 |
| * pitti exhales and lowers blood pressure again | 08:28 | |
| LocutusOfBorg1 | python3.5 broke some gl stuff | 08:32 |
| LocutusOfBorg1 | http://paste.ubuntu.com/11965059/ | 08:33 |
| LocutusOfBorg1 | can anbody please englight me for this? | 08:33 |
| LocutusOfBorg1 | from OpenGL.GL import * works on python3 but not on python3.5 | 08:33 |
| LocutusOfBorg1 | leading to a build failure for python-pyqtgraph | 08:33 |
| LocutusOfBorg1 | I would like to help for the transition if possible | 08:34 |
| pitti | presumably it needs a rebuild to build against 3.4 and 3.5 | 08:37 |
| pitti | ah sorry, no -- looks like this actually needs to be fixed in source | 08:37 |
| LocutusOfBorg1 | pitti, who needs to be fixed? | 08:48 |
| pitti | OpenGL.GL apparently | 08:49 |
| LocutusOfBorg1 | mmm ok, that was my though | 08:49 |
| LocutusOfBorg1 | thanks | 08:49 |
| LocutusOfBorg1 | python-qt4 (4.11.4+dfsg-1build2) wily; urgency=medium | 08:49 |
| LocutusOfBorg1 | * No-change rebuild to fix damaged filename caused by dh-python3 bug | 08:49 |
| LocutusOfBorg1 | Laney, ^^^ is that fixing my issue? | 08:50 |
| Laney | LocutusOfBorg1: I doubt it | 09:12 |
| LocutusOfBorg1 | me too :( | 09:14 |
| doko | seb128, now working on double-conversion | 09:19 |
| seb128 | doko, k | 09:19 |
| doko | seb128, when will Mirv be back? | 09:20 |
| seb128 | doko, no idea, ask bzoltan | 09:21 |
| seb128 | he's in the sdk team, I didn't even know he was not around this week | 09:22 |
| doko | ahh, no desktop | 09:22 |
| seb128 | no :-) | 09:22 |
| seb128 | hum | 09:22 |
| seb128 | https://errors.ubuntu.com/problem/2e928d043cd548a5933dfc25b2ea162446c277ef | 09:22 |
| seb128 | how come we have so many wily users getting python3.5 as default | 09:22 |
| seb128 | are they using wily-proposed? | 09:22 |
| infinity | seb128: proposed still prefers 3.4 | 09:25 |
| seb128 | infinity, what would make 3.5 be preferred? | 09:25 |
| seb128 | I doubt that many users changed their default manually... | 09:25 |
| infinity | seb128: Other than changing the symlink, I can't imagine how people would get 3.5 as the default 3. | 09:26 |
| seb128 | weird | 09:26 |
| infinity | ProcCmdline | 09:26 |
| infinity | /usr/bin/python3.5 /usr/bin/onboard | 09:27 |
| infinity | Is onboard calling 3.5 directly? | 09:27 |
| infinity | Yes. Yes it is. | 09:27 |
| infinity | WTF. | 09:27 |
| infinity | onboard (1.1.1-0ubuntu2) wily; urgency=medium | 09:27 |
| infinity | * No-change rebuild for python3.5 transition | 09:27 |
| infinity | Apparently a no-change rebuild changed the interpreter. | 09:27 |
| infinity | Thanks, crappy build system. | 09:27 |
| seb128 | weird, it doesn't have a python3.5 depends and running "onboard" here works without error | 09:31 |
| infinity | seb128: Which version do you have installed? | 09:32 |
| seb128 | ii onboard 1.1.1-0ubuntu2 i386 Simple On-screen Keyboard | 09:32 |
| seb128 | maybe it's amd64 specific | 09:32 |
| infinity | seb128: 1.1.1-0ubuntu2 depends python3.5 here, and has a 3.5 shebang. | 09:32 |
| seb128 | my i386 binary has python3.4 | 09:32 |
| seb128 | yeah | 09:33 |
| seb128 | i386 built with 3.4 | 09:33 |
| infinity | seb128: More complicated than that, actually. | 09:33 |
| infinity | seb128: Looks like it's a race. It builds all supported versions, then installs them all to the same path. | 09:34 |
| infinity | seb128: Depending on which order that happens in make, you get 3.4 or 3.5 | 09:34 |
| seb128 | fun | 09:34 |
| infinity | seb128: Both are wrong, of course, it should just use a python3 shebang, otherwise building the modules for both versions is pointless. :P | 09:34 |
| infinity | I don't know enough about distutils and setup.py magic to know how to fix this braindeath. | 09:36 |
| infinity | The trivial fix would just be to re-install onboard and onboard-settings after setup.py install, since the versions in the source have the right shebang. | 09:37 |
| infinity | But if this shebang-mangling is a common setuptools thing, I wonder how many other packages are broken/breaking? | 09:39 |
| doko | seb128, working on wxwidgets. if you don't have time, maybe pitti could help with some packages? | 09:39 |
| seb128 | doko, yeah, that would be welcome | 09:40 |
| seb128 | I'm having a day off tomorrow and I'm trying to wrap up some other things today | 09:40 |
| doko | seb128, ok, then please could you attach the diffs to the open debian reports? | 09:40 |
| seb128 | doko, yes, going to do that today | 09:41 |
| infinity | doko: Is it a setuptools bug that build_scripts/install_scripts is setting the shebang to the exact python version instead of python3? | 09:42 |
| infinity | doko: That doesn't seem right, and I don't think this particular package is doing anything special to make it do that. | 09:42 |
| infinity | scripts = ['onboard', 'onboard-settings'], | 09:42 |
| infinity | It just has that in setup.py, and setuptools is doing the evil thing. | 09:42 |
| infinity | Err, distutils. | 09:43 |
| infinity | Not awake. | 09:43 |
| infinity | doko: distutils, I mean, not setuptools. 4am brain. | 09:43 |
| doko | infinity, which package? | 09:43 |
| infinity | doko: onboard | 09:44 |
| infinity | doko: It's getting a shebang of /usr/bin/python3.4 or python3.5, depending on what it's built with, and racy luck. | 09:44 |
| infinity | doko: Neither seem correct, I'd assume it should just by python3? | 09:44 |
| infinity | s/by/be/ | 09:44 |
| mgedmin | the "modern" way of installing python scripts is to use setup(entry_ponts={'console_scripts': ['foo=package.module:main_function', ...]}) | 09:45 |
| mgedmin | but I don't know what sort of shebang gets used in that case | 09:45 |
| doko | infinity, that's expected, afaik. the packaging should be aware of it. not sure if dh-python normalises the shebang | 09:46 |
| infinity | doko: It certainly doesn't seem to, or this bug wouldn't be in the binaries. | 09:47 |
| infinity | Though, the part where it has a --no-shebang-rewrite option sort of implies it tries to. Weird. | 09:50 |
| * infinity tests a fix. | 09:52 | |
| cjwatson | I remember having to take great care in the germinate packaging to avoid that problem | 09:53 |
| cjwatson | https://git.launchpad.net/germinate/tree/debian/rules | 09:53 |
| cjwatson | (Though that isn't using the new pybuild hotness) | 09:54 |
| infinity | cjwatson: I just applied a simple dh_python3 --shebang=/usr/bin/python3 hammer. | 09:59 |
| infinity | cjwatson: Seems to have done the trick. | 09:59 |
| * cjwatson nods | 10:01 | |
| cjwatson | That may not have existed when I was doing that | 10:01 |
| cjwatson | python 2.7.3-1, python3 3.2.3-1 - so quite probably not | 10:01 |
| pitti | seb128: which ones are you working on and want to pass on? | 10:04 |
| infinity | seb128: onboard fix uploaded. | 10:04 |
| pitti | seb128: (sorry, still getting into the gcc transition business, I don't know much about it yet) | 10:04 |
| pitti | infinity: FYI, Laney is converting existing logs, so e. g. http://autopkgtest.ubuntu.com/packages/d/d-conf/trusty/amd64/ are clickable too now | 10:04 |
| doko | pitti, forwarding you a list | 10:05 |
| doko | see, what already is built in 39 | 10:06 |
| infinity | pitti: Snazzy. | 10:06 |
| infinity | pitti: Glad you got it sorted. I almost typed "we", but all I did was run your test case and point out that it works. :P | 10:07 |
| pitti | doko: ok; so everything in silo-16 which needs a rename should go into silo-39? | 10:13 |
| doko | pitti, yes. I'm working now on tinyxml2 | 10:14 |
| pitti | doko: most packages from your list are already done, it seems? | 10:16 |
| doko | pitti, well, seb128 said around 10 would be missing | 10:16 |
| pitti | seb128: do you have a list of remaining ones? | 10:16 |
| pitti | .. which neither you or doko are working on? | 10:16 |
| doko | look what already is in 39 | 10:17 |
| pitti | otherwise, if that gets in teh way too much, I'll go on with checking the debian bugs | 10:17 |
| pitti | seb128, doko: ok, e. g. capnproto, cwidget, exiv2 aren't done; either of you working on those? | 10:19 |
| doko | no | 10:20 |
| pitti | so, I'll take exiv2, migrate it, and send the patch to Debian | 10:20 |
| doko | google-perftools too, wxwidgets, | 10:20 |
| doko | openbabel (not on the list) | 10:20 |
| doko | musicbrainz5 (take it from experimental). the last two are needed by kubuntu | 10:21 |
| infinity | doko: Debian imports seem vaguely happy now, python3.4 synced. | 10:28 |
| doko | just got the email, thanks | 10:29 |
| pitti | seb128: e. g. your cppunit change should go to debian bug 791013, right? | 10:30 |
| ubottu | Debian bug 791013 in src:cppunit "cppunit: library transition may be needed when GCC 5 is the default" [Important,Open] http://bugs.debian.org/791013 | 10:30 |
| pitti | or is there somethign about "our" transition which doesn't apply to Debian somehow? | 10:30 |
| cjwatson | infinity: oh good | 10:32 |
| doko | infinity, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7732860 | 10:33 |
| doko | is this 3.5 related? | 10:33 |
| infinity | doko: Hrm? | 10:35 |
| doko | wild guess, didn't see that one before | 10:36 |
| infinity | /«BUILDDIR»/unity-scopes-shell-0.5.4+15.10.20150707/src/scope-harness/matcher/category-list-matcher.cpp:121:54: error: call of overloaded 'move(unity::scopeharness::matcher::CategoryMatcher&)' is ambiguous | 10:36 |
| infinity | Just looks like a stricter compiler to me. | 10:36 |
| infinity | doko: Or did you paste the wrong URL? | 10:37 |
| doko | ohh, I was irritated by the ImportError: messages | 10:37 |
| infinity | doko: Oh, all the importerror stuff could indeed be python shebang badness somewhere. | 10:38 |
| pitti | doko, seb128: OK, so I still don't understand this -- cppunit got renamed, but nm -D from the old and renamed library look identical -- why did that need a rename? | 10:38 |
| pitti | I thought we only need to do that if the symbols don't match | 10:38 |
| doko | pitti, most likely I saw a build failure with the not renamed one, likely be triggered by template instantiations | 10:40 |
| doko | resulting in link failures | 10:40 |
| pitti | oh, nevermind -- I diffed 1.13.2-2build1 against 1.13.2-2ubuntu1~gcc5 | 10:41 |
| pitti | now I diffed 1.13.2 against 1.13.2-2ubuntu1~gcc5 and the syms are different | 10:41 |
| doko | heh | 10:41 |
| doko | so maybe start with exiv2, then strigi | 10:41 |
| pitti | i. e. the -build1 ones were no-change rebuilds which were then broken because they changed ABI | 10:41 |
| * pitti is still trying to understand this, having zero C++ knowledge | 10:42 | |
| pitti | ok, but that makes sense now | 10:42 |
| pitti | doko: yep | 10:42 |
| pitti | doko: i. e. upload exiv2, then upload no-change rebuilds of all reverse deps of it? | 10:42 |
| cjwatson | doko,infinity: https://rt.admin.canonical.com/Ticket/Display.html?id=83461 should avoid that mirroring failure mode in future | 10:43 |
| doko | pitti, no, no no-change rebuilds yet | 10:43 |
| infinity | cjwatson: Ta. | 10:43 |
| pitti | doko: ok | 10:43 |
| infinity | cjwatson: Did we ever revisit using incoming/debian-buildd to import faster? | 10:44 |
| cjwatson | no no no no no no no no no no no no no change rebuilds | 10:44 |
| pitti | doko: and is not forwarding the changes to the debian bugs a mere omission, or intended? | 10:44 |
| cjwatson | infinity: it's still buried somewhere in my mental to-do list; needs verification that things aren't going to melt if incoming rewinds | 10:44 |
| doko | pitti, the plan is to copy these renamed libs to -proposed, then have a first go rebuilding things. because we can't rebuild everything for each transition, so we'll start transitions first, then do a first test rebuild | 10:44 |
| doko | nowatson? | 10:45 |
| doko | pitti, my changes are forwarded. seb128 wants to do this today | 10:46 |
| pitti | doko: ack, so intended | 10:46 |
| infinity | cjwatson: Is UNACCEPT still a thing ftp-master considers a valid action? | 10:46 |
| cjwatson | We don't want to assume that it isn't. | 10:47 |
| cjwatson | I think it still occasionally happens once in a blue moon. | 10:47 |
| infinity | cjwatson: I suppose we could invent machinery to block something in proposed until it's "really" in unstable, and delete on unaccept, but that would be much tighter integration than we have today. And probably serious overengineering. | 10:49 |
| cjwatson | infinity: Oh, the concern was more just making sure that gina doesn't melt. | 10:51 |
| cjwatson | infinity: I wasn't thinking about auto-syncing from incoming. Just making it available for manual syncs in emergencies would generally be good enough, and doesn't require that kind of overengineering since if it's manual then somebody is responsible for it. | 10:52 |
| infinity | cjwatson: Ahh. | 10:52 |
| cjwatson | But I need to spend some time understanding gina enough to be comfortable with this ... | 10:52 |
| infinity | cjwatson: Yeah, if '-d incoming' worked, that would already be a huge win. | 10:52 |
| infinity | cjwatson: From dak's POV, incoming isn't actually a different suite, mind you, it's in unstable the moment it's accepted, but I guess since we're importing from Packages files, not the dak db, we can fudge it however we like. | 10:53 |
| cjwatson | We could stuff it into debian/sid, but I think that might be harder | 10:54 |
| infinity | A partial debian/incoming seems reasonable to me. (or $suite-incoming, if you want completeness) | 10:55 |
| infinity | Though, the latter sort of implies giving debian series' pockets, which I'm not sure we've ever bothered doing, have we? | 10:56 |
| infinity | I guess it doesn't have to imply that, sid-incoming can just be a whole new series. | 10:56 |
| cjwatson | Hm, it's true that it'd be a lot of series, and we don't have arbitrarily named pockets, the best we could do is stuff into unstable-proposed | 10:59 |
| cjwatson | Which might not be entirely terrible modelling | 10:59 |
| cjwatson | Err, debian/sid-proposed that is | 10:59 |
| cjwatson | There's also things like buildd-testing-proposed-updates though | 11:00 |
| infinity | Yeah, p-u is what would actually model to proposed, if we were being pedantic. | 11:00 |
| cjwatson | We don't import p-u right now | 11:01 |
| infinity | buildd/unstable really is a part of unstable, it's just unpublished on ftpmaster. | 11:01 |
| infinity | Bit it's unstable according to the DB. | 11:01 |
| cjwatson | We could merge them, that's not impossible | 11:01 |
| infinity | THat would more correctly match dak ls / rmadison's view of the world. | 11:02 |
| pitti | doko: forwarded to debian bug 791030 and reassigned to release.d.o (I trust that this is still the right thing to do -- seems a bit odd as the maintainer will stop seeing it?) | 11:19 |
| ubottu | Debian bug 791030 in release.debian.org "exiv2: library transition may be needed when GCC 5 is the default" [Important,Open] http://bugs.debian.org/791030 | 11:19 |
| === MacSlow is now known as MacSlow|lunch | ||
| doko | pitti, hmm ... anyway, I think most of these will be done by NMU's ... but maybe just attach the patch for now (but don't change it back) | 11:33 |
| pitti | doko: ok, I'll attach the patch for strigi then without reassigning (I don't have an opinion on that, I'm just thinking aloud to avoid errors on the first one that I do :) ) | 11:34 |
| doko | no, makes sense | 11:34 |
| doko | pitti, working myself on wxwidgets | 11:35 |
| pitti | but yeah, a big swamp of NMUs sounds easier than getting 200 maintainers to dput around the same time | 11:35 |
| StevenK | Synchronize watches ... okay, everyone hit enter on 3. 1 ... 2 ... 3! | 11:35 |
| cjwatson | reminds me of a vintage #debian-devel topic | 11:39 |
| cjwatson | OPN: more fun than a 200-user ytalk session on auric | 11:39 |
| seb128 | infinity, thanks | 11:39 |
| seb128 | pitti, no, not working on gcc5 things atm, I'm having tomorrow off and I'm trying to clean out some other things today before | 11:39 |
| pitti | seb128: ack | 11:40 |
| StevenK | Oh god, ytalk | 11:40 |
| seb128 | pitti, unsure what list doko gave you, but some don't need rename | 11:40 |
| seb128 | like poppler or syncevolution | 11:41 |
| seb128 | like if there are no changed symbols in the public abi there is no need for a rename | 11:41 |
| pitti | seb128: because they don't change public symbols | 11:41 |
| pitti | yep | 11:41 |
| seb128 | right | 11:41 |
| seb128 | pitti, you can look at logs in https://people.debian.org/~doko/logs/gcc5-20150701/ | 11:41 |
| pitti | W: libsearchclient0v5: package-name-doesnt-match-sonames libsearchclient0 | 11:41 |
| seb128 | pitti, if they have a C11XX symbols section | 11:41 |
| pitti | that's expected, right? | 11:41 |
| pitti | seb128: yep, got that | 11:41 |
| seb128 | pitti, yes | 11:41 |
| seb128 | the warning is normal I think | 11:42 |
| pitti | i. e. we don't want to fiddle with the soname because we have the Conflicts:/Replaces:? | 11:42 |
| seb128 | correct | 11:42 |
| seb128 | soname change are more complex and an upstream thing | 11:42 |
| * pitti uploads strigi and sends it to Debian | 11:43 | |
| doko | I should document that we can remove the conflict/replaces with the next soname bump | 11:44 |
| pitti | seb128: imagemagick (8:6.8.9.9-5build2) shoudl have been ubuntu1 I take it? | 11:52 |
| pitti | well, let's hope that the next debian upload will include this | 11:52 |
| seb128 | pitti, yes | 11:52 |
| pitti | seb128: do you have a list of packages which don't need to be converted? (like poppler, which I removed from my local one, but I'm sure there's more) | 11:53 |
| pitti | doko, seb128: so your list minus the ones in the PPA is http://pad.ubuntu.com/gcc-5-transition | 11:57 |
| pitti | that might have stuff that you already work on or which were already checked to not require a rename -- please update or put your name on what you work on? | 11:58 |
| pitti | grabbing capnproto then | 11:58 |
| seb128 | pitti, the list I pastebined you yesterday was that | 12:02 |
| seb128 | pitti, http://paste.ubuntu.com/11960809/ | 12:03 |
| seb128 | was the remaining from doko list | 12:03 |
| pitti | seb128: ah, those *do* need renames, all others don't? | 12:03 |
| seb128 | I should have noted the ones that don't need transition, let me clean out those on the etherpad | 12:03 |
| seb128 | pitti, correct | 12:03 |
| seb128 | pitti, well, those need transition or to be checked | 12:04 |
| pitti | ack, pad updated | 12:04 |
| seb128 | it's the initial list - the ones done - the ones that I checked and don't need to be done | 12:04 |
| seb128 | danke | 12:04 |
| * pitti grabs cwidget then | 12:05 | |
| doko | working on guichan | 12:05 |
| pitti | doko: marked on pad | 12:07 |
| === _salem is now known as salem_ | ||
| doko | pitti, the snappy package has nothing to do with snappy ;) | 12:25 |
| doko | working on jack2d | 12:25 |
| LocutusOfBorg1 | is there any reason for python-3to2 migration failure? I see from update_excuses "missing build on", but it is an arch:all package | 12:31 |
| LocutusOfBorg1 | or maybe I should just wait some little more | 12:31 |
| cjwatson | LocutusOfBorg1: You need to be more patient. | 12:32 |
| cjwatson | LocutusOfBorg1: That proposed-migration run started before the built binaries had published. | 12:34 |
| LocutusOfBorg1 | I'm wondering if the old python3-3to2 that belongs to a different package might be a problem | 12:40 |
| cjwatson | LocutusOfBorg1: Shouldn't be. | 12:42 |
| LocutusOfBorg1 | thanks | 12:43 |
| LocutusOfBorg1 | Unit193, ok to upload ext-pack on experimental? | 12:46 |
| pitti | doko: cwidget doesn't have a Debian bug report; shoudl I create one, or am I missing something and it shouldn't have? (aptitude is the only reverse dep) | 13:10 |
| doko | pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792681 | 13:12 |
| ubottu | Debian bug 792681 in src:cwidget "cwidget ftbfs with GCC 5" [Normal,Open] | 13:12 |
| pitti | doko: ah, thanks | 13:13 |
| === MacSlow|lunch is now known as MacSlow | ||
| seb128 | doko, pitti, should those bugs/patches be usertaged "origin-ubuntu wily ubuntu-patch"? | 13:25 |
| seb128 | or isn't that a thing anymore? | 13:25 |
| pitti | seb128: it still exists AFAIK, so can't hurt | 13:26 |
| doko | seb128, maybe, but you can't file new bugs with more than one user/usertag. that's why I usually omit those | 13:26 |
| pitti | oh? I thought I've done this several times | 13:26 |
| seb128 | doko, you can | 13:26 |
| seb128 | "Usertags: origin-ubuntu wily ubuntu-patch" works | 13:26 |
| seb128 | in mails sent to submit@b.d.o | 13:26 |
| pitti | like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777521 | 13:27 |
| ubottu | Debian bug 777521 in pgsql-asn1oid "pgsql-asn1oid: Test regression with PostgreSQL 9.4.1 due to invalid \set ECHO" [Normal,Open] | 13:27 |
| cjwatson | Right, but not more than one user/(list-of-usertags) pair | 13:27 |
| gema | do we have britney running on ubuntu packages? can anyone give me the link to it? | 13:27 |
| pitti | several User/Usertags: pairs | 13:27 |
| cjwatson | gema: http://people.canonical.com/~ubuntu-archive/proposed-migration/ | 13:27 |
| gema | cjwatson: thanks! | 13:27 |
| doko | maybe this works now, but I was bitten in the past by it not seeing my filed bug reports | 13:28 |
| cjwatson | pitti: I'm reasonably sure only some of those are parsed | 13:28 |
| pitti | maybe only the last one hten | 13:29 |
| cjwatson | my reading of http://git.donarmstrong.com/?p=debbugs.git;a=blob;f=scripts/process;h=4c38000121c02e388828aee0374672c5d0abe7a5;hb=HEAD#l686 suggests that you only get one | 13:29 |
| cjwatson | probably only the last, indeed | 13:29 |
| doko | seb128: hmm, not sure if Robert's "fix" to build everything in the gnome mm stack with -std=c++11 is the correct solution ... see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+build/7739358 | 13:42 |
| doko | seb128, pitti: do you have a list of packages which didn't need renaming? most likely they need a rebuild | 14:08 |
| pitti | doko: so far only libcaca from me (on the pad) | 14:09 |
| doko | ok, copying | 14:09 |
| pitti | and I know poppler and syncevolution from seb128, but he said he found more | 14:10 |
| pitti | I couldn't check libept yet, this is utterly broken | 14:10 |
| doko | Riddell, do you have updated kde4libs and phonon packages which I could use in my ppa? | 14:12 |
| doko | copied poppler | 14:12 |
| Riddell | doko: for gcc 5? I've not looked at that for kdelibs or phonon | 14:15 |
| * Riddell asks santa | 14:15 | |
| === JanC_ is now known as JanC | ||
| pitti | doko: http://paste.ubuntu.com/11966920/ is for libusermetricsinput1 -> this does not need a transition, right? (still need to check the other libs from libusermetrics, but checking that I understood it) | 14:23 |
| seb128 | doko, yeah, unsure either | 14:23 |
| doko | no, looks good. only references to libstdc++ | 14:25 |
| pitti | doko: ok, thanks; libusermetricsoutput1 is completely identical (except for offsets), so marking on pad | 14:25 |
| * pitti wonders why Debian BTS complains about "user/usertag" in Control: stanzas, but they work fine with "bts" | 14:30 | |
| cjwatson | pitti: because service is a bit more stateful than process | 14:36 |
| cjwatson | I mean that's not really a *reason*, but it's an excuse :) | 14:36 |
| pitti | cjwatson: oh, so Control: are handled by something *different* than -control@ mails? | 14:37 |
| seb128 | doko, pitti, sorry I didn't note down the ones that don't need transition, I just deleted them from my list. I think it was at least "packagekit poppler pulseaudio syncevolution" | 14:43 |
| pitti | seb128: noted these down in the pad | 14:43 |
| pitti | -T _ZN12osgAnimation10StatAction4initEPN3osg5StatsERKSsRKNS1_5Vec3fEffRKNS1_5Vec4fE | 14:44 |
| pitti | +T _ZN12osgAnimation10StatAction4initEPN3osg5StatsERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS1_5Vec3fEffRKNS1_5Vec4fE | 14:44 |
| pitti | hm, that is a symbol change, isn't it? | 14:44 |
| doko | yes | 14:44 |
| * pitti renames libopenscenegraph100 then; libopenthreads20 doesn't change symbols and thus can stay | 14:45 | |
| cjwatson | pitti: IIRC, but it has been a long time | 14:45 |
| doko | pitti, cwidget has a patch in the silo16 ppa | 14:49 |
| pitti | doko: ah, thanks | 14:49 |
| pitti | I'll finish openscenegraph, then it's meeting time anyway | 14:50 |
| pitti | wgrant: I just requested a full export on https://translations.launchpad.net/ubuntu/trusty/+language-packs ; could you please launch this manually so that infinity gets fresh trusty packs in time for the point release? | 15:26 |
| pitti | wgrant: or rather, I would request it if the page wouldn't keep timing out; but I'll keep trying | 15:27 |
| pitti | wgrant: hm, do you have some other magic to get a full export that circumvents the timeout? | 15:31 |
| pitti | wgrant: ah, I think I caught a lucky spot :) | 15:35 |
| === henrix_ is now known as henrix | ||
| doko | can I tell apt to skip downloading translation files? always get hashsum mismatches | 15:43 |
| pitti | echo "Acquire::Languages \"none\";" > "$root"/etc/apt/apt.conf.d/90nolanguages | 15:45 |
| pitti | doko: ^ | 15:45 |
| pitti | doko: ah, you probably don't need the $root bit | 15:45 |
| doko | thanks | 15:45 |
| bdmurray | infinity: are we discussing bug 1471903 here? | 15:55 |
| ubottu | bug 1471903 in livecd-rootfs (Ubuntu) "-updates, -security missing from apt lists" [High,In progress] https://launchpad.net/bugs/1471903 | 15:55 |
| infinity | bdmurray: Sure. | 15:56 |
| infinity | bdmurray: So, originally, the patch would have been about saving some image space from having useless data on it. | 15:56 |
| infinity | bdmurray: Clearly, the data is less useless to you than it was to us back then. | 15:57 |
| infinity | bdmurray: And images have grown in size. | 15:57 |
| infinity | bdmurray: So, it might be that this isn't even worth discussing and we should just revert the patch. | 15:57 |
| bdmurray | infinity: you'd also mentioned that apt-get update is running during the installer but that doesn't work in off-line installs... | 15:58 |
| infinity | bdmurray: It's run when not offline. | 15:59 |
| infinity | bdmurray: Heck, the installer is so clever it even replaces itself if a newer version exists. | 15:59 |
| infinity | bdmurray: So, yeah, that machinery would totally thwart your attempt to get valid origins for things on the livefs that have had SRUs since. Like, say, kernels. | 16:00 |
| bdmurray | infinity: So if there isn't a downside I think it is just worth reverting. | 16:01 |
| infinity | bdmurray: Anyhow, the updates lists are smallish, I'm fine with just including them. | 16:01 |
| infinity | bdmurray: No point in security being there, since updates carries all security updates as well. | 16:01 |
| infinity | bdmurray: And proposed should probably be there if it's in sources.list, but otherwise not. | 16:02 |
| infinity | bdmurray: I'll look at the current state of things. | 16:02 |
| bdmurray | infinity: okay, thanks! | 16:02 |
| doko | pitti, working on tagcoll2 | 16:08 |
| pitti | doko: do the errors in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/f/foolscap/20150728_124422@/log.gz tell anything to you? foolscap got broken by the new twisted | 16:18 |
| pitti | doko: (the new twisted accidentally migrated this morning) | 16:19 |
| pitti | doko: I can reupload the previous 0.14 twisted and re-upload 0.15 to wily-proposed to restore the previous situation, unless you have a better idea | 16:20 |
| doko | pitti, well, do we care about foolscap? look at their "twisted-compat" patches ... | 16:20 |
| doko | jtaylor, ^^^ | 16:21 |
| pitti | I'll run the test in Debian and report it there then; ci.debian.net didn't yet get around to running it with 0.15 | 16:22 |
| pitti | doko: ack, so ignore for now? | 16:22 |
| doko | https://github.com/warner/foolscap/commit/d09495f36ad77b26bf450efa0ca2ac025a7b43ba | 16:22 |
| pitti | doko: oh, cool! thanks | 16:23 |
| pitti | I'll test/cherry-pick that and send a patch to debian then | 16:23 |
| pitti | ... tomorrow, EOD now | 16:23 |
| doko | infinity, slangasek: could one of you merge dh-exec? | 16:41 |
| doko | $ dpkg -c ../libept1.4.12_1.0.13ubuntu1_amd64.deb |grep DEB | 16:41 |
| doko | lrwxrwxrwx root/root 0 2015-07-30 16:40 ./usr/lib/libept.so.1.0.5.4.16 -> ${DEB_HOST_MULTIARCH}/libept.so.1.aptpkg4.16 | 16:41 |
| infinity | doko: Merge it with what? | 16:42 |
| infinity | doko: The latest is in proposed. | 16:42 |
| doko | infinity, dep-wait | 16:43 |
| infinity | Evidently it wants a package we don't have for some reason... | 16:44 |
| infinity | Oh, it's FTBFS. | 16:45 |
| infinity | Hah. | 16:45 |
| cjwatson | and also will need an MIR | 16:46 |
| infinity | The MIR should be trivial, since it's a build tool. | 16:46 |
| infinity | But lol for a testsuite failing its own testsuite. | 16:46 |
| cjwatson | that looks like potentially something like a shell syntax difference | 16:46 |
| cjwatson | maybe? | 16:46 |
| slangasek | infinity: have a look at libtest-requiresinternet-perl :P | 16:46 |
| infinity | slangasek: I can infer what I'd see just from your instruction to look. | 16:47 |
| slangasek | pitti, infinity: moving discussion here. regarding the p-m event this morning, I don't think it's at all a given that these python3.5 rebuilds should have been let through. There were test failures higher up the stack in packages that did *not* require rebuilds for python3.5, and which are not shown in the list of tests associated to python3-defaults; and there were no-change rebuilds that I uplo | 16:49 |
| slangasek | aded, that were for pre-existing packages that ... | 16:49 |
| slangasek | ... nevertheless had outstanding test failures in -proposed. It may be too late to roll this back now, but I think there should be some deeper analysis of the skipped failures | 16:49 |
| slangasek | wow, hello split | 16:49 |
| infinity | cjwatson: Curious, it passes in a quick local attempt. | 16:49 |
| cjwatson | infinity: throw back against the wall? | 16:50 |
| infinity | cjwatson: It's been hitting the wall since vivid, last attempt three days ago. | 16:50 |
| infinity | cjwatson: I think I might need to dig deeper. :P | 16:50 |
| cjwatson | odd | 16:50 |
| infinity | slangasek: I didn't see the full list of copies from the fallout. I was trusting pitti's assertion that the failures he saw didn't seem to be particularly problematic, but I didn't do much/any investigation myself. | 16:52 |
| slangasek | infinity: sure. do we think it is too late to roll this back? | 16:53 |
| infinity | slangasek: I'd rather investigate than roll back. Unwinding everything that might depend on things we're rolling back doesn't sound fun. | 16:54 |
| infinity | slangasek: And unpromoting *everything* since the event would be the only way to really ensure that, which sounds kinda disruptive. | 16:54 |
| slangasek | infinity: right, so for the record I've been investigating said regressions for a week and was not to the bottom of them all yet | 16:55 |
| infinity | cjwatson: Huh. And works in a local sbuild too. Curiouser and curiouser. | 16:55 |
| infinity | slangasek: Is there a list of these? I can help go through some. | 16:55 |
| doko | infinity, updated libept in silo16. if you fix it, please in the silo. but it doesn't look critical | 16:56 |
| slangasek | infinity: http://people.canonical.com/~vorlon/excuses-broken-autopkgtest.html | 16:56 |
| infinity | slangasek: Also, did you see my onboard upload on top of your rebuild? That's a class of bug you might want to look out for in the python transition. :/ | 16:56 |
| slangasek | infinity: no; onboard is the source package name? | 16:56 |
| infinity | slangasek: Yeah. | 16:57 |
| slangasek | infinity: so far the only thing I *know* is a regression that snuck into wily here was ipython | 16:57 |
| infinity | slangasek: Do we have the matching output.txt from that run? "valid candidate" in excuses didn't necessarily mean it promoted. | 16:58 |
| slangasek | infinity: ehhh why is --shebang needed? isn't this supposed to be default behavior of dh_python3 for programs? | 16:58 |
| infinity | slangasek: If it's mean to be the default, it doesn't seem to be. | 16:58 |
| slangasek | infinity: it doesn't look like I do have it, unless it's archived on snakefruit somewhere. but you can cross-check the versions against the archive | 16:58 |
| infinity | slangasek: And what was super fun was that we got python3.4 on one arch and python3.5 on another. Both wrong, of course, but 3.5 blew up rather nicely. | 16:59 |
| slangasek | sqlite3 appears to have regressed r-cran-rsqlite | 16:59 |
| infinity | slangasek: Okay, so the good(ish) news on ipython is that it didn't regress on python3.4, it's only broken with 3.5, which might be because of the half-done transition, or might be because something's actually broken. | 17:03 |
| slangasek | infinity: it's because something's actually broken. | 17:03 |
| infinity | slangasek: But until python3-defaults points to 3.5, it's fine. | 17:03 |
| slangasek | infinity: and when python3-defaults points to 3.5, this will not block it | 17:04 |
| infinity | slangasek: And a python3-defaults upload will retrigger ipython tests, which would block it. | 17:04 |
| slangasek | infinity: nope; there already was a python3-defaults upload, ipython is not in the reverse-dep list | 17:04 |
| infinity | It... Sure is. | 17:05 |
| infinity | If the infrastructure is failing to parse that, that's a bug. | 17:05 |
| infinity | Maybe because it's a python3:any dep... | 17:06 |
| slangasek | ok | 17:06 |
| slangasek | pitti: ^^ can p-m be fixed to get ipython into the autopkgtest list for python3-defaults? :) | 17:06 |
| infinity | pitti: Or, more to the point, why isn't it? :P | 17:06 |
| infinity | pitti: I'm guessing a failure to parse :any deps. Maybe? | 17:07 |
| cjwatson | Probably because it's running on a system with a python-apt that predates :any | 17:08 |
| cjwatson | is my guess anyway | 17:08 |
| cjwatson | I'd suggest what I did for LP recently, that is, switch to using python-debian for parse_depends type things on the grounds that it's way easier to upgrade | 17:09 |
| cjwatson | although that may be tricky here since it's using apt.Cache | 17:10 |
| cjwatson | though ... apt_pkg.parse_depends("foo:any") seems to roughly DTRT on snakefruit so maybe I'm wrong | 17:11 |
| infinity | Perhaps there's somewhere in the pipe where one can just 's/:.*//' and be done with it? | 17:11 |
| cjwatson | you're gonna need to handle build profiles too | 17:11 |
| slangasek | pitti: I also have in my notes that python-numpy was blocked by a pyresample test regression... and pyresample is not shown as having been tested for python-numpy | 17:12 |
| cjwatson | which are a bit harder, just dumping <.* doesn't tend to go so well | 17:12 |
| infinity | Right, yet another argument for me getting to the apt/dpkg/python-apt trusty SRUs and precise-cat backports, I geuss. :/ | 17:12 |
| slangasek | and that one appears to be a straight binary dependency from python-resample on python-numpy, no :any handling involved | 17:12 |
| infinity | The lack of sorting in those lists is driving me mad. | 17:14 |
| infinity | slangasek: I don't see any successes in pyresample's history, so I'm not sure about regressions there... | 17:48 |
| infinity | slangasek: The new version just built, though, so maybe it'll be happy. | 17:48 |
| infinity | slangasek: Oh, was pyresample the one you were talking about magically starting to fail in wily when it was fine in vivid? | 17:49 |
| infinity | Ahh, indeed it was. | 17:49 |
| slangasek | infinity: yes, but regardless it's a problem that pyresample isn't showing as tested for python-numpy | 18:05 |
| infinity | slangasek: Indeed. | 18:08 |
| pitti | infinity, slangasek: foolscap is the one regression that I saw and that we moderately care about that was affected by letting twisted in | 18:23 |
| pitti | infinity, slangasek: http://people.canonical.com/~pitti/tmp/excuses.html was the run from this morning | 18:24 |
| pitti | :any deps> snakefruit runs precise, might indeed have a too old python-apt for :any; I'll create a bug to see if we can work around it | 18:25 |
| juliank | What is mvo doing? | 18:26 |
| juliank | Haven't seen him recently | 18:26 |
| pitti | bug 1479922 | 18:27 |
| ubottu | bug 1479922 in Auto Package Testing "doesn't consider :any reverse dependencies" [Undecided,New] https://launchpad.net/bugs/1479922 | 18:27 |
| pitti | juliank: I've heard he's on vacation | 18:27 |
| juliank | :( | 18:27 |
| slangasek | pitti: thanks. did you also see the comment above about pyresample not being tested for python-numpy? | 18:27 |
| juliank | but thanks, pitti | 18:28 |
| pitti | yep (reading backscroll from top to bottom) | 18:28 |
| pitti | slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pyresample looks like an ordinary FTBFS, same as this morning (http://people.canonical.com/~pitti/tmp/excuses.html#pyresample | 18:28 |
| pitti | slangasek: http://people.canonical.com/~pitti/tmp/excuses.html#python-numpy was blocked by pytables | 18:29 |
| slangasek | pitti: yes, but the set of *tested* packages is still wrong | 18:29 |
| slangasek | why was pyresample not tested? | 18:29 |
| slangasek | the fact that python-numpy /happened/ to get blocked by another failure is not comforting | 18:29 |
| === Pici` is now known as Pici | ||
| pitti | ah, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/wily/2015-07-30/00:12:32.html.gz had pyresample for numpy indeed | 18:32 |
| pitti | conversely, the old infra didn't test pyorbital, the new one does | 18:34 |
| pitti | tracked as bug 1479926 | 18:37 |
| ubottu | bug 1479926 in Auto Package Testing "python-numpy does not trigger pyresample" [Undecided,New] https://launchpad.net/bugs/1479926 | 18:37 |
| hallyn | infinity: having a duh moment. merging a release from debian. do i use debuild -S -sa -v<priori-ubuntu-version> to include the debian changelog entry in .changes? | 18:38 |
| pitti | hallyn: yes, please | 18:39 |
| hallyn | pitti: thanks. | 18:39 |
| bdmurray | jamespage_: is bug 1479496 supposed to be fixed in Wily and In Progress in Vivid? | 18:50 |
| ubottu | bug 1479496 in python-neutronclient (Ubuntu Wily) "[SRU] python-neutronclient 1:2.3.11 + long request URI's don't work with Kilo" [High,In progress] https://launchpad.net/bugs/1479496 | 18:50 |
| mitya57 | Can some archive admin please look at lp: #1465703? | 19:23 |
| ubottu | Launchpad bug 1465703 in unity-mail (Ubuntu) "Please remove unity-mail from the archive" [Undecided,New] https://launchpad.net/bugs/1465703 | 19:23 |
| mitya57 | Laney, thanks a lot for fixing ipython! :) | 19:38 |
| cjwatson | mitya57: done | 19:39 |
| mitya57 | cjwatson, thanks | 19:40 |
| mitya57 | jtaylor, unping because Iain fixed it | 19:42 |
| doko | infinity, could you have a look? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+sourcepub/5267655/+listing-archive-extra built fine before | 20:10 |
| doko | not that we would need that on ppc64el, but it fails with -O0, so maybe something wrong in qt5, or because it's built using -O3? | 20:11 |
| teward | stupid generic question, but where can I obtain a copy of the gcc5 stuff to testbuild packages via it, to determine if there's broken stuff in some of my code? | 22:09 |
| sarnold | teward: hopefully useful: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-July/001143.html -- do ko has already done rebuilds and published results :) | 22:12 |
| teward | sarnold: rebuilds of the entire repositories? | 22:13 |
| teward | or only things with direct depends | 22:13 |
| sarnold | teward: I think everything | 22:14 |
| teward | ack | 22:14 |
| teward | i think you know which packages i'm interested in xD | 22:15 |
| teward | and a few private nonpublished ones're also on my radar :P | 22:15 |
| kees | stgraber: say... I'm following instructions for unpriv lxc at https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-unpriv on vivid. I have some questions... if you have a moment? | 22:43 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!