[00:00] Yeah! It was during an automatic upgrade, too. [00:00] So everything was working, and then the keyboard and mouse stopped responding to anything. [00:00] RAOF_hates_all_c: Maybe it upgraded the PS/2 driver and blew up on rescan. [00:00] RAOF_hates_all_c: If so, the USB keyboard trick might work. [00:00] That's my current theory, yes. [00:00] *handwavy* [00:01] Alternatively, I can wait for it to drop from suspend to hibernate and then boot from USB. [00:01] But maybe I can be bothered to find a USB keyboard... [00:01] So much effort, though! [00:02] Much more enjoyable to bitch on IRC using $BACKUP_LAPTOP [00:02] Hah. [00:02] USB mouse might be easier? :P [00:02] I'm not sure I could find one of those, actually. [00:02] rdp? [00:02] Either one should get you to a reboot button. [00:02] any chance you've got an sshd running on it? [00:02] mwhudson: rdp implies either (a) it's always open (I'd assume not) or (b) he has input devices to turn it on. [00:03] 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] true [00:03] 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] lifeless wins! [00:04] \o/ [00:04] thank you, thank you, I take requests. [00:04] RAOF_hates_all_c: Next step: uninstall Windows. [00:04] mwhudson: wiki login in suspiciously slow but worked [00:05] mwhudson: just had to be awesomely patient, if you mean w.u.c [00:05] lifeless: yeah i think something got restarted, i'm in now [00:48] Woot! [00:48] The laptop boots *much* better when a kernel is installed. [00:50] RAOF_hates_all_c: Kernels are overrated. [06:11] Good morning [06:54] good morning [07:01] seb128: so it seems you already fixed all the FTBFS in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+packages ? [07:26] hi folks, what happened to the Debian automatic import? [07:26] I see many packages that hasn't been syncd [07:29] 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] pitti: Can I get you to look at the apt SRU in trusty? It's point-release crticial. [07:29] infinity: yup [07:30] pitti: Explanation of the patch can be gotten from reading between the lines in the referenced Debian bug. Ish. [07:30] infinity, thanks, I saw the breakage right now [07:30] pitti: It's tested here and works. [07:30] 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] http://metadata.ftp-master.debian.org/changelogs/main/p/python-3to2/python-3to2_1.1.1-1_changelog [07:30] this seems to be the right link now [07:30] infinity: ah, not fixed for wily yet either? [07:31] 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] infinity: ack [07:34] 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] can anybody please kick of python3-3to2 from the archive? [07:34] 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] the new binary in python-3to2 has that binary now [07:35] pitti: Hopefully (until David decides to rewrite the whole autoremove feature), this is the last fix. :P [07:35] infinity: famous last words [07:35] pitti: Yeah, seriously. [07:35] pitti: I'm beginning to wish I hadn't reported the first bug that started this all. [07:39] 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:40] Fingers crossed. [07:46] pitti, wfm [07:55] wgrant: argh, I screwed up! [07:55] 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] wgrant: but have test failures [07:56] wgrant: I'll start investigating, but it might be that we need some Launchpad magic for reverting this :/ [07:56] pitti: When did this happen? [07:56] Do you have an example package? [07:56] wgrant: some 20 mins ago [07:56] wgrant: the first one on the page, for example [07:56] for most it's probably okay, as we have a couple of broken tests [07:57] wgrant: I'll go through the "valid candidate"s now and compile a list of stuff that we need to revert/handle [07:57] cjwatson: ^^ fyi [07:57] pitti: This shouldn't require any particular LP magic, though. [07:57] pitti: Reverting packages is possible, I think there might even be a script to do it. [07:57] wgrant: yeah, hopefully; just a warning [07:57] It is ugly, though. [07:58] It's possible, but please don't unless absolutely necessary. [07:58] It would be easier if they weren't published. [07:58] Which they're not, it seems [07:58] 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] 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] e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pycurl [07:58] this is again a case where the migration was premature, but harmless [07:59] pitti: Go through the list of premature promotions and make some value judgements. [07:59] infinity: it doesn't migrate uninstallable/FTBFS stuff, just test regressions, so it shoudln't cause new uninstallability [07:59] pitti: In most cases, I think we'll probably just want to live with it. [07:59] infinity: yep, that's what I'm doing now [07:59] right [07:59] pitti: No, I meant that reverting could cause breakage. :P [07:59] in particular, python3-defaults has not been promoted yet (adding 3.5 as supported version) [08:00] 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] pitti: I assume you've reverted or fixed your britney oops? [08:00] infinity: I reverted britney, yes [08:01] pitti: that sounds *so* wrong [08:01] 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] .me nods. [08:01] * infinity too. [08:01] sorry about the mess -- here's to writing tests that don't prevent breakage :/ [08:01] * lifeless raises the glass [08:01] *clink* [08:02] pitti: It's the classic QA governance dilemma, who tests the testsuite? [08:04] Riddell: see ^ -- a lot of KDE 5.10 -> 5.12 just landed in wily because the kdelibs4support test regression got ignored [08:04] Riddell: where on a scale of "intended -- okay -- OMGrevert" is that? [08:05] (the kdelibs4support test regression happenend much earlier, FTR, in 5.10 already) [08:05] mm, I've not made any changes recently [08:06] pitti: which ignore is that? [08:06] Riddell: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html e. g. the topmost entry [08:06] Riddell: or solid, kitemviews, etc. [08:07] infinity: the test test suite suite [08:07] infinity: actually more seriously, depends on known unknowns or unknown unknowns. [08:07] that was definitively an unknown unknown [08:08] 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:09] pitti, the list is fine, maybe give those packages in main priority [08:09] doko: ack, good idea (will continue after the britney SNAFU) [08:09] pitti: Also, still no browser-friendly content headers before switching to the new shiny? :( [08:09] Riddell: my main question to you is whether you are fine with 5.12 landing in wily now [08:10] pitti: yes I'm all for it [08:10] infinity: I spent like an hour on that, there's no effing way to do that :( [08:10] (I sent a summary to bug 1474271) [08:10] bug 1474271 in Auto Package Testing "fix MIME type of log.gz" [Medium,Triaged] https://launchpad.net/bugs/1474271 [08:10] Riddell: ok, thanks [08:11] pitti: Humor me, what happens if you serve/link it as foo.txt.gz? [08:11] pitti: Depending on the httpd in play, it might decide to do all the right things for you at that point. [08:12] infinity: I actually tried all combinations of *.txt.gz, *.gz, Content-Type:, and Content-Encoding: [08:12] pitti: Hrmph. Kay. [08:12] infinity: the httpd is swift in this case [08:12] we could store the logs uncompressed, but they'll get quite a bit larger then [08:12] 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:13] yeah, the bug is still on my list, but less important -- opening in gedit works okayish [08:14] pitti: Hm, Content-Encoding: gzip should work fine [08:14] pitti: We totally don't do this in Launchpad: [08:14] if filename.endswith('txt.gz'): [08:14] encoding = 'gzip' [08:14] pitti: FWIW, LP's correctly-behaving logs are Content-Encoding: x-gzip [08:14] mimetype = 'text/plain; charset=utf-8' [08:14] Hahahahaha "correctly-behaving" [08:14] 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] wgrant: Correct, per my browser. ;) [08:14] wgrant: yes, I did set Content-Encoding:, but swift doesn't send it or the browser doesn't take it into account [08:15] wgrant: Curious that you push encoding=gzip, but twisted insisted in x-ifying it. [08:15] wgrant: see https://bugs.launchpad.net/auto-package-testing/+bug/1474271/comments/1 [08:15] Launchpad bug 1474271 in Auto Package Testing "fix MIME type of log.gz" [Medium,Triaged] [08:15] so with "Content-Type: text/plain; charset=UTF-8" and the ignored COntent-Encoding, you see the gzipped garbage inline [08:16] pitti: Ah, I guess Swift could well realise that what you're doing is completely wrong. [08:17] 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:18] Oh, I assume you'd have no control yourself, since it seems to be a shared prodstack resource. Hrm. [08:18] pitti: Did you revert the attempt to set Content-Type, etc? [08:23] 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] consider those as "always failed" [08:23] so I think by and large we are okay [08:23] *phew* [08:24] curiously test regressions are holding up *some* package updates, but not most of them; I'll chase that bug now [08:24] wgrant, cjwatson: ^ panic mode off [08:25] 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] infinity: I never rolled this out as it didn't work [08:25] slangasek, infinity: pretty much the only "questionable" promotion that I found is https://launchpad.net/ubuntu/+source/python-setuptools/18.0.1-1 [08:26] pitti: Browser's don't ignore content-encoding though... [08:26] pitti: So, I'd be curious to see the bits you tried, or play myself a bit. [08:26] that or python3-defualts broke tox, python-html2text, and ipython; but I suspect that it's the py3.5 transition, checking logs [08:27] pitti: Seems a bit broken if setuptools was breaking as-installed tests. Would be more likely to cause build failures, no? [08:28] pitti: Odds are it wasn't to blame. [08:28] yeah, the logs of those look like it was py3.5, not setuptools [08:28] so, I think by and large I was lucky in my screwup [08:28] Yay luck. [08:28] * pitti exhales and lowers blood pressure again [08:32] python3.5 broke some gl stuff [08:33] http://paste.ubuntu.com/11965059/ [08:33] can anbody please englight me for this? [08:33] from OpenGL.GL import * works on python3 but not on python3.5 [08:33] leading to a build failure for python-pyqtgraph [08:34] I would like to help for the transition if possible [08:37] presumably it needs a rebuild to build against 3.4 and 3.5 [08:37] ah sorry, no -- looks like this actually needs to be fixed in source [08:48] pitti, who needs to be fixed? [08:49] OpenGL.GL apparently [08:49] mmm ok, that was my though [08:49] thanks [08:49] python-qt4 (4.11.4+dfsg-1build2) wily; urgency=medium [08:49] * No-change rebuild to fix damaged filename caused by dh-python3 bug [08:50] Laney, ^^^ is that fixing my issue? [09:12] LocutusOfBorg1: I doubt it [09:14] me too :( [09:19] seb128, now working on double-conversion [09:19] doko, k [09:20] seb128, when will Mirv be back? [09:21] doko, no idea, ask bzoltan [09:22] he's in the sdk team, I didn't even know he was not around this week [09:22] ahh, no desktop [09:22] no :-) [09:22] hum [09:22] https://errors.ubuntu.com/problem/2e928d043cd548a5933dfc25b2ea162446c277ef [09:22] how come we have so many wily users getting python3.5 as default [09:22] are they using wily-proposed? [09:25] seb128: proposed still prefers 3.4 [09:25] infinity, what would make 3.5 be preferred? [09:25] I doubt that many users changed their default manually... [09:26] seb128: Other than changing the symlink, I can't imagine how people would get 3.5 as the default 3. [09:26] weird [09:26] ProcCmdline [09:27] /usr/bin/python3.5 /usr/bin/onboard [09:27] Is onboard calling 3.5 directly? [09:27] Yes. Yes it is. [09:27] WTF. [09:27] onboard (1.1.1-0ubuntu2) wily; urgency=medium [09:27] * No-change rebuild for python3.5 transition [09:27] Apparently a no-change rebuild changed the interpreter. [09:27] Thanks, crappy build system. [09:31] weird, it doesn't have a python3.5 depends and running "onboard" here works without error [09:32] seb128: Which version do you have installed? [09:32] ii onboard 1.1.1-0ubuntu2 i386 Simple On-screen Keyboard [09:32] maybe it's amd64 specific [09:32] seb128: 1.1.1-0ubuntu2 depends python3.5 here, and has a 3.5 shebang. [09:32] my i386 binary has python3.4 [09:33] yeah [09:33] i386 built with 3.4 [09:33] seb128: More complicated than that, actually. [09:34] seb128: Looks like it's a race. It builds all supported versions, then installs them all to the same path. [09:34] seb128: Depending on which order that happens in make, you get 3.4 or 3.5 [09:34] fun [09:34] seb128: Both are wrong, of course, it should just use a python3 shebang, otherwise building the modules for both versions is pointless. :P [09:36] I don't know enough about distutils and setup.py magic to know how to fix this braindeath. [09:37] 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:39] But if this shebang-mangling is a common setuptools thing, I wonder how many other packages are broken/breaking? [09:39] seb128, working on wxwidgets. if you don't have time, maybe pitti could help with some packages? [09:40] doko, yeah, that would be welcome [09:40] I'm having a day off tomorrow and I'm trying to wrap up some other things today [09:40] seb128, ok, then please could you attach the diffs to the open debian reports? [09:41] doko, yes, going to do that today [09:42] 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] 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] scripts = ['onboard', 'onboard-settings'], [09:42] It just has that in setup.py, and setuptools is doing the evil thing. [09:43] Err, distutils. [09:43] Not awake. [09:43] doko: distutils, I mean, not setuptools. 4am brain. [09:43] infinity, which package? [09:44] doko: onboard [09:44] 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] doko: Neither seem correct, I'd assume it should just by python3? [09:44] s/by/be/ [09:45] the "modern" way of installing python scripts is to use setup(entry_ponts={'console_scripts': ['foo=package.module:main_function', ...]}) [09:45] but I don't know what sort of shebang gets used in that case [09:46] infinity, that's expected, afaik. the packaging should be aware of it. not sure if dh-python normalises the shebang [09:47] doko: It certainly doesn't seem to, or this bug wouldn't be in the binaries. [09:50] Though, the part where it has a --no-shebang-rewrite option sort of implies it tries to. Weird. [09:52] * infinity tests a fix. [09:53] I remember having to take great care in the germinate packaging to avoid that problem [09:53] https://git.launchpad.net/germinate/tree/debian/rules [09:54] (Though that isn't using the new pybuild hotness) [09:59] cjwatson: I just applied a simple dh_python3 --shebang=/usr/bin/python3 hammer. [09:59] cjwatson: Seems to have done the trick. [10:01] * cjwatson nods [10:01] That may not have existed when I was doing that [10:01] python 2.7.3-1, python3 3.2.3-1 - so quite probably not [10:04] seb128: which ones are you working on and want to pass on? [10:04] seb128: onboard fix uploaded. [10:04] seb128: (sorry, still getting into the gcc transition business, I don't know much about it yet) [10:04] 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:05] pitti, forwarding you a list [10:06] see, what already is built in 39 [10:06] pitti: Snazzy. [10:07] 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:13] doko: ok; so everything in silo-16 which needs a rename should go into silo-39? [10:14] pitti, yes. I'm working now on tinyxml2 [10:16] doko: most packages from your list are already done, it seems? [10:16] pitti, well, seb128 said around 10 would be missing [10:16] seb128: do you have a list of remaining ones? [10:16] .. which neither you or doko are working on? [10:17] look what already is in 39 [10:17] otherwise, if that gets in teh way too much, I'll go on with checking the debian bugs [10:19] seb128, doko: ok, e. g. capnproto, cwidget, exiv2 aren't done; either of you working on those? [10:20] no [10:20] so, I'll take exiv2, migrate it, and send the patch to Debian [10:20] google-perftools too, wxwidgets, [10:20] openbabel (not on the list) [10:21] musicbrainz5 (take it from experimental). the last two are needed by kubuntu [10:28] doko: Debian imports seem vaguely happy now, python3.4 synced. [10:29] just got the email, thanks [10:30] seb128: e. g. your cppunit change should go to debian bug 791013, right? [10:30] 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] or is there somethign about "our" transition which doesn't apply to Debian somehow? [10:32] infinity: oh good [10:33] infinity, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7732860 [10:33] is this 3.5 related? [10:35] doko: Hrm? [10:36] wild guess, didn't see that one before [10:36] /«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] Just looks like a stricter compiler to me. [10:37] doko: Or did you paste the wrong URL? [10:37] ohh, I was irritated by the ImportError: messages [10:38] doko: Oh, all the importerror stuff could indeed be python shebang badness somewhere. [10:38] 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] I thought we only need to do that if the symbols don't match [10:40] pitti, most likely I saw a build failure with the not renamed one, likely be triggered by template instantiations [10:40] resulting in link failures [10:41] oh, nevermind -- I diffed 1.13.2-2build1 against 1.13.2-2ubuntu1~gcc5 [10:41] now I diffed 1.13.2 against 1.13.2-2ubuntu1~gcc5 and the syms are different [10:41] heh [10:41] so maybe start with exiv2, then strigi [10:41] i. e. the -build1 ones were no-change rebuilds which were then broken because they changed ABI [10:42] * pitti is still trying to understand this, having zero C++ knowledge [10:42] ok, but that makes sense now [10:42] doko: yep [10:42] doko: i. e. upload exiv2, then upload no-change rebuilds of all reverse deps of it? [10:43] doko,infinity: https://rt.admin.canonical.com/Ticket/Display.html?id=83461 should avoid that mirroring failure mode in future [10:43] pitti, no, no no-change rebuilds yet [10:43] cjwatson: Ta. [10:43] doko: ok [10:44] cjwatson: Did we ever revisit using incoming/debian-buildd to import faster? [10:44] no no no no no no no no no no no no no change rebuilds [10:44] doko: and is not forwarding the changes to the debian bugs a mere omission, or intended? [10:44] 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] 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:45] nowatson? [10:46] pitti, my changes are forwarded. seb128 wants to do this today [10:46] doko: ack, so intended [10:46] cjwatson: Is UNACCEPT still a thing ftp-master considers a valid action? [10:47] We don't want to assume that it isn't. [10:47] I think it still occasionally happens once in a blue moon. [10:49] 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:51] infinity: Oh, the concern was more just making sure that gina doesn't melt. [10:52] 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] cjwatson: Ahh. [10:52] But I need to spend some time understanding gina enough to be comfortable with this ... [10:52] cjwatson: Yeah, if '-d incoming' worked, that would already be a huge win. [10:53] 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:54] We could stuff it into debian/sid, but I think that might be harder [10:55] A partial debian/incoming seems reasonable to me. (or $suite-incoming, if you want completeness) [10:56] Though, the latter sort of implies giving debian series' pockets, which I'm not sure we've ever bothered doing, have we? [10:56] I guess it doesn't have to imply that, sid-incoming can just be a whole new series. [10:59] 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] Which might not be entirely terrible modelling [10:59] Err, debian/sid-proposed that is [11:00] There's also things like buildd-testing-proposed-updates though [11:00] Yeah, p-u is what would actually model to proposed, if we were being pedantic. [11:01] We don't import p-u right now [11:01] buildd/unstable really is a part of unstable, it's just unpublished on ftpmaster. [11:01] Bit it's unstable according to the DB. [11:01] We could merge them, that's not impossible [11:02] THat would more correctly match dak ls / rmadison's view of the world. [11:19] 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] 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 === MacSlow is now known as MacSlow|lunch [11:33] 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:34] 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] no, makes sense [11:35] pitti, working myself on wxwidgets [11:35] but yeah, a big swamp of NMUs sounds easier than getting 200 maintainers to dput around the same time [11:35] Synchronize watches ... okay, everyone hit enter on 3. 1 ... 2 ... 3! [11:39] reminds me of a vintage #debian-devel topic [11:39] OPN: more fun than a 200-user ytalk session on auric [11:39] infinity, thanks [11:39] 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:40] seb128: ack [11:40] Oh god, ytalk [11:40] pitti, unsure what list doko gave you, but some don't need rename [11:41] like poppler or syncevolution [11:41] like if there are no changed symbols in the public abi there is no need for a rename [11:41] seb128: because they don't change public symbols [11:41] yep [11:41] right [11:41] pitti, you can look at logs in https://people.debian.org/~doko/logs/gcc5-20150701/ [11:41] W: libsearchclient0v5: package-name-doesnt-match-sonames libsearchclient0 [11:41] pitti, if they have a C11XX symbols section [11:41] that's expected, right? [11:41] seb128: yep, got that [11:41] pitti, yes [11:42] the warning is normal I think [11:42] i. e. we don't want to fiddle with the soname because we have the Conflicts:/Replaces:? [11:42] correct [11:42] soname change are more complex and an upstream thing [11:43] * pitti uploads strigi and sends it to Debian [11:44] I should document that we can remove the conflict/replaces with the next soname bump [11:52] seb128: imagemagick (8:6.8.9.9-5build2) shoudl have been ubuntu1 I take it? [11:52] well, let's hope that the next debian upload will include this [11:52] pitti, yes [11:53] 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:57] doko, seb128: so your list minus the ones in the PPA is http://pad.ubuntu.com/gcc-5-transition [11:58] 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] grabbing capnproto then [12:02] pitti, the list I pastebined you yesterday was that [12:03] pitti, http://paste.ubuntu.com/11960809/ [12:03] was the remaining from doko list [12:03] seb128: ah, those *do* need renames, all others don't? [12:03] I should have noted the ones that don't need transition, let me clean out those on the etherpad [12:03] pitti, correct [12:04] pitti, well, those need transition or to be checked [12:04] ack, pad updated [12:04] it's the initial list - the ones done - the ones that I checked and don't need to be done [12:04] danke [12:05] * pitti grabs cwidget then [12:05] working on guichan [12:07] doko: marked on pad === _salem is now known as salem_ [12:25] pitti, the snappy package has nothing to do with snappy ;) [12:25] working on jack2d [12:31] 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] or maybe I should just wait some little more [12:32] LocutusOfBorg1: You need to be more patient. [12:34] LocutusOfBorg1: That proposed-migration run started before the built binaries had published. [12:40] I'm wondering if the old python3-3to2 that belongs to a different package might be a problem [12:42] LocutusOfBorg1: Shouldn't be. [12:43] thanks [12:46] Unit193, ok to upload ext-pack on experimental? [13:10] 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:12] pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792681 [13:12] Debian bug 792681 in src:cwidget "cwidget ftbfs with GCC 5" [Normal,Open] [13:13] doko: ah, thanks === MacSlow|lunch is now known as MacSlow [13:25] doko, pitti, should those bugs/patches be usertaged "origin-ubuntu wily ubuntu-patch"? [13:25] or isn't that a thing anymore? [13:26] seb128: it still exists AFAIK, so can't hurt [13:26] seb128, maybe, but you can't file new bugs with more than one user/usertag. that's why I usually omit those [13:26] oh? I thought I've done this several times [13:26]