[00:46] ^- first test of new upload scheme [00:46] (I was in a bit too much of a rush the first time and beat the rollout to pepo, hence the reject) [00:47] g [00:48] please accept: libguestfs x-kit for python3.3 fixes [01:05] x-kit's fine [01:06] libguestfs (a) has a typo ("CPPCFLAGS") and (b) ignores test failures without explanation [01:09] So rejected - I've mailed doko with an explanation [01:10] xnox: ^- [01:10] (Plus, next upload will magically go to -proposed) [01:13] I've modified the queue client to look in -proposed by default, seeing as most things will be there now [01:18] cjwatson: ack. thanks for the review. [04:26] ^^^ would be nice to get in before the general opening because there is a small chance packages might misbuild if it's not. [04:32] ScottK: Sure. [04:32] Thanks. [04:34] I should probably nap. I think eglibc's done, but it might help to look it over when my eyes aren't close to being glued shut. [04:54] That means my local hack to avoid including the entire package changelog in the sync request worked ... [07:05] ScottK: oh, yeah, perhaps I ought to have mentioned that in my -devel-announce post - the "entire changelog" bug is one tumbleweed fixed in ubuntu-dev-tools bzr === doko_ is now known as doko [09:19] cjwatson: how long does it usually take for a package to migrate from -proposed to -release [09:21] doko: That depends on a number of things; the SRU default policy is 7-days, plus all bugs marked as tested. [09:21] RAOF, ahh, no, for raring [09:21] Hah! [09:21] ECONTEXT [09:22] doko: there is no migration delay; it should be in the next publisher cycle after it's built everywhere, typically [09:22] doko: see http://people.canonical.com/~ubuntu-archive/proposed-migration/ [09:22] thanks [09:23] ohh, so we are blocking on the slowest arch [09:23] Yes [09:24] I *may* decide to weaken some of the constraints at some point, but I want to see how we do with these first [09:24] I'd prefer to start accurate rather than assuming failure [09:25] You can also look at it as "ensuring that multiarch systems combining fast and slow architectures don't fail" [09:25] Since they often require that versions are in sync [09:33] doko: BTW, packages in -proposed still build against -proposed, so this doesn't need to block build chains or anything [09:34] right [09:35] doko: and the py3.3 rebuild ppa builds against raring-proposed as well ;-) [09:39] hmm, the onboard ftbfs looks interesting [09:57] cjwatson: at the current moment nose is already deleted from -proposed, but not yet published in -release [09:57] ah it's pending in release [09:57] bah, the setup.py overwriting locale.getpreferredencoding [10:12] xnox: that ordering can happen because it does Archive.copyPackage (creates async job processed maybe a minute or so later) then SPPH.requestDeletion (immediate) [10:13] But there's no risk of it actually getting lost AFAIK - worst case you get really unlucky and it vanishes for one publisher cycle [10:13] I think timings are such as to render that implausible at the moment, though [10:15] cjwatson: ok, i'm not sure if it ever managed to be published/available from -proposed or I have missed it with rmadison. [10:15] obviously it was published enough for britney to find it.... === yofel_ is now known as yofel [10:51] xnox: britney works off published Packages/Sources files, so it must have been fully published and available [10:56] ok. === seb128_ is now known as seb128 [13:36] prodded proposed-migration a bit - the conditions for running it weren't quite right [13:36] should sort itself out next publisher cycle [13:37] (specifically, it wasn't running when raring-proposed changed, only when raring changed) [13:37] can we see the scripts and the britney modifications? [13:40] * Laney finds promote-to-release [14:39] ^ isn't that supposed to be blocked to start with? or is that how it's being handled (lands in queue then something rejects automatically)? [14:46] stgraber: let me try that again [14:46] that exim4 update is a security update [14:46] sure, but you shouldn't be able to copy to raring, only to raring-proposed [14:46] I'm just surprised it even showed up in the queue, I thought it'd be rejected at copy time, not when hitting the queue [14:46] stgraber: even as an AA? [14:46] stgraber: AAs should be able to copy to the release pocket still AIUI [14:46] only if using the auto-accept flag [14:47] I'll happily put it in -proposed [14:47] stgraber: AAs can copy directly, with autoapprove=True or whatever it is. [14:47] Ahh, you beat me there. [14:48] ok, I was unaware of --auto-approve [14:48] actually, I was not, I just haven't used it in a while [14:49] that ^ will be rejected [14:49] then the next one was with --auto-approve [14:50] * jdstrand wonders if --auto-approve shows up here [14:50] it shouldn't as it won't hit the queue [14:50] ah, makes sense [14:53] jdstrand: is it just LP being a bit slow or did you get an error with the --auto-approve copy? I'm not seeing 1.1 on the publishing page for exim4 in raring [14:53] stgraber: I did not get an error. I assume it is slow [14:54] I never can remember how long it takes. 5 minutes, 10 minutes, 30 minutes... [14:56] not 5 it seems :) [14:59] I did unembargo 8 openjdks [14:59] so maybe that has something to do with it [15:06] doko: Can I get pykde4 building with 3.3 before we switch the default? [15:07] ScottK, is this on the images? [15:07] Yes. [15:07] * ScottK double checks. [15:07] see -devel, we wanted to make it the default now [15:08] how difficult is this? like qscintilla2? [15:08] It requires CMake to know about the alternate include directory. [15:08] I have a test build of a dirty hack in progress. [15:08] * xnox already did 3-4 CMake's [15:09] blender morse-simulator hivex by memory [15:10] Does PYTHON_INCLUDE_DIRS include both? [15:10] It may just be then that I need to use that instead of PYTHON_INCLUDE_PATH [15:10] ScottK: no, it doesn't. But you need to add both into it and make sure all cmakelists use PYTHON_INCLUDE_DIRS [15:11] pykde4 still uses the older PYTHON_INCLUDE_PATH, but that's an easy enough change. [15:11] here I cheated: used pkg_config to populate PYTHON_INCLUDE_DIRS http://launchpadlibrarian.net/121099621/morse-simulator_0.6~alpha-1~exp1_0.6~alpha-1~exp1ubuntu1.diff.gz [15:12] hivex is actually autoconf. [15:15] ScottK, sip: /scratch/packages/tmp/pykde4-4.9.2/sip/kdecore/typedefs.sip:955: Mapped type has already been defined in another module [15:16] make[5]: *** [sip/kterminal/sipkterminalpart0.cpp] Error 1 [15:16] make[5]: Leaving directory `/scratch/packages/tmp/pykde4-4.9.2/builddir-2.7' [15:16] make[4]: *** [CMakeFiles/python_module_PyKDE4_kterminal.dir/all] Error 2 [15:16] make[4]: Leaving directory `/scratch/packages/tmp/pykde4-4.9.2/builddir-2.7' [15:16] make[3]: *** [all] Error 2 [15:16] fails already in 2.7 :-/ or is this known? [15:16] That's known. [15:16] There's an upstream patch for that. [15:17] doko: https://projects.kde.org/projects/kde/kdebindings/pykde4/repository/revisions/fd30259903ad693b86476b6e8c280b93d0102223 [15:17] just wanted to check for the so name renaming. ScottK: pointer? [15:17] There you go. [15:26] make[5]: *** No rule to make target `/usr/lib/libpython3.3mu.so', needed by `lib/pykde/akonadi.so'. Stop. [15:29] My horrible hack attempt is just about to get to that point. [15:30] Laney: lp:~ubuntu-archive/britney/britney{1,2}-ubuntu [15:32] stgraber,jdstrand: while people with queue admin privileges on the release pocket *can* copy directly to it (and it'll land in the queue if we're frozen and you don't use auto_approve), please do not do so. This is intended only for the sake of the automatic scripts themselves [15:33] doko: I'm stuck on "/usr/include/python3.3m/Python.h:8:22: fatal error: pyconfig.h: No such file or directory" [15:33] ScottK, I have a fix. but how do a re-run a configure step just for 3.3? [15:33] I don't know. I just failed at that myself. [15:33] ScottK, didn't xnox's hint help? [15:33] We should probably talk at UDS about exceptions, since there'll no doubt be some, but I don't really want AAs/release-team-members copying into release just because we can ... [15:33] That one is still building. [15:34] It's 1/4 of the way through python3.2 [15:34] ScottK: well I look at the cmakes output's first to see if they make sence and have the paths, before launching the build ;-) [15:34] That would have been one way to do it. [15:39] if an SRU team member has a minute, the bridge-utils I just uploaded to precise-proposed fixes a boot time hang that quite a few people have been nagging me about on IRC over the past few days. It's a 3 lines change to a script so should be trivial to review and matches what we've had in quantal for months, so pretty safe. [15:39] -DPYTHON_LIBRARY=/usr/lib/libpython${v}$(shell python$(i) -c "import sys; print(sys.abiflags)").so \ [15:39] ScottK, ^^^ [15:39] doko: Thanks. [15:40] and I see it prefers python2 as the default python version. maybe change that for raring (not now)? [15:41] It has to. [15:41] The one part of the build that that affects hasn't been ported yet. [15:42] hrm, that's not enough ... [15:45] It would be a more general solution, I think, to change FindPythonLibs.cmake in CMake itself so that PYTHON_INCLUDE_DIRS has both directories in it. [15:51] I hate debhelper sequencer ... [15:52] If we do that, it's a one line change (I think) in pykde4 to use PYTHON_INCLUDE_DIRS instead of PYTHON_INCLUDE_PATH [15:54] slangasek: there are a bunch of patches for -proposed waits to get accepted (vlc, culmus, fonts-nanum-coding) [15:59] ScottK, please do if it's quick. I have a patch for the rest of the renaming [16:00] doko: Go ahead and do PYTHON_INCLUDE_DIRS in your pykde4 as that'll work regardless. Let me look at CMake again. [16:03] ^-- Shouldn't natty be EOLish? [16:05] ScottK, xnox: pkg_check_modules(PYTHON3 python3) how would that be patched to look for the python version used for the build (and not python3)? [16:05] I setup a blueprint for the SRU team at https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-sru-queue-velocity [16:06] doko: I think python${_CURRENT_VERSION} [16:06] That's what FinePythonLibs uses [16:06] cjwatson: so, exim4 never made it to raring. should I use raring-proposed? [16:06] that may be internal to it though. [16:07] Yes, it is. [16:08] debfx: ^^^ Do you know the answer to doko's question? [16:10] infinity, scheduled for 10/28 - will send out the email then. [16:16] bdrung: I'm aware of the SRU queue and will be plowing through them today. Please make sure that all SRU bugs have the required SRU information before I get there, otherwise they'll go to the back of the queue again ;) [16:21] infinity: thanks. I poked a couple of the reporters on IRC so bridge-utils should be all tested before it reaches the 7 days mark. [16:22] stgraber: Alrighty. [16:22] stgraber: (Wait, how did you know it was me?) [16:22] infinity: sru-accept comments in the bug ;) [16:23] stgraber: Oh, duh. Right. [16:23] stgraber: I thought someone had finally implemented queue auditing when I wasn't looking. [16:23] (no, we still don't have queue audit...) [16:23] right :) [16:55] doko: I'm lost in a maze of twisty turny cmake passage, all look alike. [16:57] ScottK, I think I have something ... [16:57] Great. [16:57] slangasek: done. please note that vlc has a preliminary MRE [16:58] It did, however, lead me to find a mistake I'd made in my hack to deal with multiple pyqtconfig.py files in the same directory for python3 in PyQt (thus the upload) [16:58] So getting lost wasn't time wasted. [17:01] cjwatson, ^^^ hmm, copies from ppa's including binaries don't seem to work [17:01] jdstrand: Please do, although I would like to investigate what happened to your previous copy when I'm not in an airport. [17:01] doko: see above comment :) [17:02] yeah, seen python3-defaults too [17:04] cjwatson: ack [17:04] (and done) [17:12] doko: Thanks. [17:12] doko: Would you mind accepting the python-qt4 one as well? [17:12] ScottK, is it really needed? arm builders are busy ... [17:13] Without it pyqtconfig isn't going to work in python3. Not sure how important that is. [17:14] I got an accept from somebody. Thanks. [17:17] meh [17:19] mdeslaur: seems that copies from ppas including binaries doesn't work atm, so the exim4 update was rejected (both to release and -proposed). the same thing happened to openjdk-6 and openjdk-7. cjwatson is aware, but will look at it late [17:19] later* [17:19] jdstrand: ok, thanks [17:21] ScottK, any idea about https://launchpadlibrarian.net/121171710/buildlog_ubuntu-raring-amd64.pykde4_4%3A4.9.2-0ubuntu3_FAILEDTOBUILD.txt.gz ? [17:22] did build here locally [17:36] doko: No idea why it'd work locally and not on the buildd, but "sip: Unable to find file "QtCore/QtCoremod.sip"" gives me some thought that a retry after the PyQt upload build is done might work. [18:03] doko this is some ^^^^ [18:03] there will be more vvvvv [18:06] doko ^^^^ [18:08] xnox, why python-numpy again? [18:08] doko: not sure. reject for now and I'll double check my set. [18:09] xnox, because I know this has the extensions for both 3.x versions [18:13] doko: ok, it was in my set because it has hard dependency on python3.2 via /usr/bin/f2py3.2 [18:13] which will be dropped, when we drop py3.2 support. [18:13] so reject is correct. [18:26] doko: cjwatson: barry: shiboken is shibroken & hence I cannot rebuild pyside and therefore britney is holding back python3-defaults [18:26] * xnox decides to fix all of this. [18:27] do we not have support for overriding britney here? [18:27] because we shouldn't block on shiborken [18:28] xnox: slangasek is correct. if you *must* fix shiboken, my suggestion is to essentially no-op the tests that crash the interpreter. [18:28] xnox: sucks because it hides a real bug (imho, in shiboken) but there you have it [18:28] if britney is set up right, I could probably force it by manually copying python3-defaults over :P [18:29] (and then let britney clean everything up afterwards) [18:29] but, er, I haven't gotten a briefing yet on where the britney instance is doing its thing [18:29] infinity: ^^ can you give me a pointer? [18:29] (preferably a non-null one) [18:29] slangasek: I'm going to do the right way, and do "anything possible without touching britney" to migrate packages. [18:30] yeah on https://launchpad.net/ubuntu/+source/gcc-4.7/4.7.2-5ubuntu3/+build/3928872/+files/buildlog_ubuntu-raring-armel.gcc-4.7_4.7.2-5ubuntu3_FAILEDTOBUILD.txt.gz [18:30] xnox: I don't think disabling a test suite to make a known-broken package build is "the right way" :) [18:31] slangasek: it's bug 1070772 [18:31] Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [Undecided,Confirmed] https://launchpad.net/bugs/1070772 [18:31] I think ignoring the test failure is ok provided you keep a bug report open and come to it back later [18:31] xnox: and any more-correct fix for sheboygan is going to take much longer to implement, and really shouldn't be allowed to block here [18:31] and I don't know if it's bug in shiboken, the unit test, or our pythons. [18:31] slangasek: i don't either :) just sayin' if there's no other way, that's how i'd work around it [18:32] xnox: i strongly suspect shiboken or some other related extension module [18:32] xnox: i tried to report it upstream, but the qt bug tracker hates me [18:32] slangasek: shiboken is known fail to build from source in quantal. So can britney wave those? [18:33] slangasek: should shiboken binaries & pyside binaries be removed from the archive then? [18:33] is that a right fix? [18:33] doko: ^^ would you agree with removing the binaries? [18:33] they'd be uninstallable anyway, right? [18:34] generally yes, if there are no r-deps [18:34] afk now [18:35] slangasek: we are talking about removing pyside - python qt4 LGPL bindings here. (pyqt4 is gpl) [18:35] the rdep chain is shiboken->pyside/pyside-tools->ipython3-qtconsole [18:36] ScottK might have some input here, if he's around [18:37] xnox: actually, I was only planning to remove shiboken; pyside could be left as-is until shiboken itself is fixed [18:37] but "as-is" would be "uninstallable" [18:37] slangasek: python3-defaults will not migrate. britney is holding on pyside not shiboken. [18:37] anyway, the set of revdeps on pyside is small, which is why I think this is reasonable [18:37] oh [18:37] xnox: where are you seeing the britney output? [18:37] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt [18:38] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [18:38] * xnox *grins* [18:38] perfect, thanks [18:38] * xnox also has no clue what britney is trying to tell me [18:38] * xnox is troubleshooting pycrypto in the mean time [18:38] xnox: it tells you that updating python3-defaults results in those packages becoming newly-uninstallable [18:39] pyside isn't the only package in the list though [18:39] morse-simulator, python3-crypto-dbg? what do we know about this? [18:40] xnox: pulling the shiboken binary will definitely unblock britney [18:40] because then pyside is *already* uninstallable in raring, so britney ignores it [18:40] sorry, I mean it'll unblock britney wrt pyside [18:40] slangasek: morse-simulator is building, python3-crypto-dbg <--- working on it. [18:41] slangasek: also having python3-defaults generate uninstallable defaults packages doesn't help either. [18:41] * xnox goes to fix python3-defaults first. [18:41] where do you see this? [18:41] slangasek: when trying to rebuild python-crypto in raring-proposed chroot. [18:42] hmm [18:42] but britney doesn't notice? [18:42] $ rmadison -S -s raring python3.3 [18:42] $ rmadison -S -s raring-proposed python3-defaults [18:43] I don't follow [18:43] defaults are at 3.3.0-0ubuntu1, while real one is at 3.3.0-2 [18:43] why is that a problem? [18:43] they're different sources, there shouldn't be any lockstep versioned dependency [18:44] hmmm.... [18:45] https://launchpad.net/ubuntu/raring/i386/python3-minimal/3.3.0-0ubuntu1 [18:45] shiboken binaries shibounced [18:45] slangasek: thanks. [18:47] fwiw if someone (ScottK?) considers not having pyside installable a problem and feels that it's better to have shiboken skipping the test suite and building with a known bug, I don't object [18:47] I just don't think we should do that as non-users of the package [18:48] slangasek: you won't mind if i subscribe ScottK to the bug and paste your comment there? [18:48] there == bug 1070772 [18:48] Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [High,Confirmed] https://launchpad.net/bugs/1070772 [18:49] no, that's between you and him ;) [18:49] :) [18:50] slangasek: he and i are on the same flight to cph so maybe we'll chat about it [18:52] slangasek: ok. I had a dirty chroot. [18:53] * xnox continues to debug python-crypto [18:54] slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt now looks very interesting [18:54] are there any hints and trying to understand that output? [19:01] xnox: it's more interesting now because there were more candidates; my binary removals hadn't taken effect yet, it's nothing different due to that [19:02] why python3-defaults is "tried" twice [19:03] ah.... if other candidates migrate (all: changes) will the skipped packages migrate together or not. [19:03] hmm.... clever but hard to read =) [19:03] xnox: so each block beginning with "trying:" is a single source package that's a candidate for copying; 'ori' is the count of uninstallable packages, per architecture, at the beginning of the britney run; pre: is at the current point in the run before adding this candidate; now: is the result after trying to add the candidate [19:03] xnox: correct [19:05] and the got bit? [19:05] got: 180+0: i-180 [19:15] xnox: that says something about the increase in uninstallability... I forget exactly what, sorry [19:16] I believe it's "there are now 180 packages uninstallable on i386, which is an increase" (from 164) [19:20] I can see how circular dependencies may confuse britney. [19:21] they don't really confuse britney, they just make it slower due to NP-completeness :) [19:21] actually, I would expect us to be using auto-hinting for -proposed and it doesn't look like we are [19:24] slangasek: can it please also do demotions/removals? it would be nice to ask britney to try to demote python3.2 and it tell me which packages I should fix =) [19:24] although we have transition trackers for that, britney is more robust. [19:25] xnox: checkrdepends is probably better for that [19:25] ok. [19:30] ah, seems the auto-hinting doesn't generate output anymore [19:31] that does mean you can't use the output to track the progress of a related set of packages that are not-quite-ready [19:32] ^ above rebuilds makes python3-crypto-dbg to be Depends: python3 (>= 3.2.0) instead of Depends: python3 (>= 3.2.0), python3 (<< 3.3) [19:33] and then we will just have to wait for powerpc builds to finish =( [20:58] barry/slangasek: pyside isn't on my list of things I care about. [21:00] ScottK: cool [21:04] infinity: eglibc breaks boost [21:05] * xnox wishes I uploaded boost-mpi-source1.49 before your eglibc upload. [21:05] infinity: time.h now defines TIME_UTC, which boost used to be using. [21:05] in boost 1.50 they renamed it to TIME_UTC_ [21:06] Then boost needs to stop. [21:06] well there is patch https://svn.boost.org/trac/boost/changeset/78802 [21:06] Sounds like you know what patch you need to apply then ... [21:06] but will that break abi/api/compat if I do it in boost1.49 [21:07] https://svn.boost.org/trac/boost/changeset/78802/trunk/boost/thread/xtime.hpp [21:08] it's part of enum xtime_clock_types [21:08] * xnox so does not want to have boost transition :`( [21:14] xnox: I'm inclined to say that boost is broken, not glibc. [21:15] xnox: But I'm happy to help with a boost transition during UDS. [21:15] xnox: Is 1.50 GA, or still in devel? [21:15] xnox: If it's GA, we should just switch, IMO. [21:16] infinity: released August 20th, 2012 23:00 GMT [21:17] infinity: well, that macro is part of C11 standard [21:17] xnox: Yeah, we should just transition and be done with it, then. [21:17] Unfortunately, on Linux, this is a problem in any C++ code. g++ implicitly defines _GNU_SOURCE, which in turn causes _ISOC11_SOURCE to be defined, regardless of what C++ standard is actually used. But regardless of this gcc feature, the boost interfaces are broken if I want to use C11 interfaces from C++ code. [21:17] quote from https://svn.boost.org/trac/boost/ticket/6940 [21:17] I'm not sure *who* is defining _ISOC11_SOURCE [21:21] Anyhow, I'm pretty deep in the gin right now, so if that's the only major fallout of glibc 2.16 so far, we're doing well. [21:27] infinity: I think I will apply patch to boost1.49 and if rdeps break then we will move to boost1.50 [21:31] infinity: no, we need to move to boost1.50 then because there is stuff that uses boost::TIME_UTC which is now invalid [21:32] xnox: If we're breaking ABI, we may as well just bump it correctly instead of fudging it. [21:33] infinity: yes. So for the currently stuck package in britney I can just port that one to boost1.50 (this should then allow python3-defaults to migrate) [21:33] and then we can do the boost transition [22:18] xnox: why is it not sufficient to #undef TIME_UTC in the boost headers? [22:18] (as a non-ABI-changing workaround) [22:41] slangasek: it should be. Why did fedora not do this when they hit it? [22:41] They first applied: http://pkgs.fedoraproject.org/cgit/boost.git/commit/?h=f18&id=f68c4dd92574829a34324290c15e360d0fedf643 [22:41] drop enclosed enum and "embrace" TIME_UTC macro [22:45] and now transitioning to boost 1.50.... [22:46] xnox: Probably safer to apply just the patch to 1.49 and do some rebuilds. [22:46] ScottK: patch which does (i) undef TIME_UTC or (ii) s/boost::TIME_UTC/boost::TIME_UTC_/ [22:47] The latter. [22:59] I am doing a test build of slangasek 's simple solution, as I can't think of any reason why it wouldn't work. [22:59] eglibc 2.16 is new and nothing should be relying on TIME_UTC. [23:00] If something does conditionally rely on it & boost xtime.hpp at the same time it would only do so with boost1.50 which we have available. [23:00] I really don't want to have boost1.49.ubuntu1 abi =) [23:06] OK. [23:07] slangasek: autohinter did the magic to transition python3-defaults \0/ [23:08] perfect [23:11] and your boost fix works as well http://paste.ubuntu.com/1308399/ === Ursinha is now known as Ursinha-afk [23:43] Boost insanity is curable for once. [23:45] xnox: Good to hear. === Ursinha-afk is now known as Ursinha