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