[00:46] <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:47] <xnox> g
[00:48] <xnox> please accept: libguestfs    x-kit    for python3.3 fixes
[01:05] <cjwatson> x-kit's fine
[01:06] <cjwatson> libguestfs (a) has a typo ("CPPCFLAGS") and (b) ignores test failures without explanation
[01:09] <cjwatson> So rejected - I've mailed doko with an explanation
[01:10] <cjwatson> xnox: ^-
[01:10] <cjwatson> (Plus, next upload will magically go to -proposed)
[01:13] <cjwatson> I've modified the queue client to look in -proposed by default, seeing as most things will be there now
[01:18] <xnox> cjwatson: ack. thanks for the review.
[04:26] <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:32] <infinity> ScottK: Sure.
[04:32] <ScottK> Thanks.
[04:34] <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:54] <ScottK> That means my local hack to avoid including the entire package changelog in the sync request worked ...
[07:05] <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
[09:19] <doko> cjwatson: how long does it usually take for a package to migrate from -proposed to -release
[09:21] <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:22] <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:23] <doko> ohh, so we are blocking on the slowest arch
[09:23] <cjwatson> Yes
[09:24] <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:25] <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:33] <cjwatson> doko: BTW, packages in -proposed still build against -proposed, so this doesn't need to block build chains or anything
[09:34] <doko> right
[09:35] <xnox> doko: and the py3.3 rebuild ppa builds against raring-proposed as well ;-)
[09:39] <doko> hmm, the onboard ftbfs looks interesting
[09:57] <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
[10:12] <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:13] <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:15] <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:51] <cjwatson> xnox: britney works off published Packages/Sources files, so it must have been fully published and available
[10:56] <xnox> ok.
[13:36] <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:37] <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:40]  * Laney finds promote-to-release
[14:39] <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:46] <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:47] <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:48] <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:49] <jdstrand> that ^ will be rejected
[14:49] <jdstrand> then the next one was with --auto-approve
[14:50]  * 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:53] <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:54] <jdstrand> I never can remember how long it takes. 5 minutes, 10 minutes, 30 minutes...
[14:56] <jdstrand> not 5 it seems :)
[14:59] <jdstrand> I did unembargo 8 openjdks
[14:59] <jdstrand> so maybe that has something to do with it
[15:06] <ScottK> doko: Can I get pykde4 building with 3.3 before we switch the default?
[15:07] <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:08] <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:09] <xnox> blender morse-simulator hivex by memory
[15:10] <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:11] <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:12] <xnox> hivex is actually autoconf.
[15:15] <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:16] <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:17] <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:26] <doko> make[5]: *** No rule to make target `/usr/lib/libpython3.3mu.so', needed by `lib/pykde/akonadi.so'.  Stop.
[15:29] <ScottK> My horrible hack attempt is just about to get to that point.
[15:30] <cjwatson> Laney: lp:~ubuntu-archive/britney/britney{1,2}-ubuntu
[15:32] <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:33] <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:34] <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:39] <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:40] <doko> and I see it prefers python2 as the default python version. maybe change that for raring (not now)?
[15:41] <ScottK> It has to.
[15:41] <ScottK> The one part of the build that that affects hasn't been ported yet.
[15:42] <doko> hrm, that's not enough ...
[15:45] <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:51] <doko> I hate debhelper sequencer ...
[15:52] <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:54] <bdrung> slangasek: there are a bunch of patches for -proposed waits to get accepted (vlc, culmus, fonts-nanum-coding)
[15:59] <doko> ScottK, please do if it's quick. I have a patch for the rest of the renaming
[16:00] <ScottK> doko: Go ahead and do PYTHON_INCLUDE_DIRS in your pykde4 as that'll work regardless.  Let me look at CMake again.
[16:03] <infinity> ^-- Shouldn't natty be EOLish?
[16:05] <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:06] <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:07] <ScottK> Yes, it is.
[16:08] <ScottK> debfx: ^^^ Do you know the answer to doko's question?
[16:10] <skaet> infinity,  scheduled for 10/28 - will send out the email then.
[16:16] <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:21] <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:22] <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:23] <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:55] <ScottK> doko: I'm lost in a maze of twisty turny cmake passage, all look alike.
[16:57] <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:58] <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.
[17:01] <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:02] <doko> yeah, seen python3-defaults too
[17:04] <jdstrand> cjwatson: ack
[17:04] <jdstrand> (and done)
[17:12] <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:13] <ScottK> Without it pyqtconfig isn't going to work in python3.  Not sure how important that is.
[17:14] <ScottK> I got an accept from somebody.  Thanks.
[17:17] <jdstrand> meh
[17:19] <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:21] <doko> ScottK, any idea about https://launchpadlibrarian.net/121171710/buildlog_ubuntu-raring-amd64.pykde4_4%3A4.9.2-0ubuntu3_FAILEDTOBUILD.txt.gz ?
[17:22] <doko> did build here locally
[17:36] <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.
[18:03] <xnox> doko this is some ^^^^
[18:03] <xnox> there will be more vvvvv
[18:06] <xnox> doko ^^^^
[18:08] <doko> xnox, why python-numpy again?
[18:08] <xnox> doko: not sure. reject for now and I'll double check my set.
[18:09] <doko> xnox, because I know this has the extensions for both 3.x versions
[18:13] <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:26] <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:27] <slangasek> do we not have support for overriding britney here?
[18:27] <slangasek> because we shouldn't block on shiborken
[18:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <doko> generally yes, if there are no r-deps
[18:34] <doko> afk now
[18:35] <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:36] <barry> ScottK might have some input here, if he's around
[18:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <xnox> hmmm....
[18:45] <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:47] <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:48] <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:49] <slangasek> no, that's between you and him ;)
[18:49] <barry> :)
[18:50] <barry> slangasek: he and i are on the same flight to cph so maybe we'll chat about it
[18:52] <xnox> slangasek: ok. I had a dirty chroot.
[18:53]  * xnox continues to debug python-crypto
[18:54] <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?
[19:01] <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:02] <xnox> why python3-defaults is "tried" twice
[19:03] <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:05] <xnox> and the got bit?
[19:05] <xnox> got: 180+0: i-180
[19:15] <slangasek> xnox: that says something about the increase in uninstallability... I forget exactly what, sorry
[19:16] <slangasek> I believe it's "there are now 180 packages uninstallable on i386, which is an increase" (from 164)
[19:20] <xnox> I can see how circular dependencies may  confuse britney.
[19:21] <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:24] <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:25] <slangasek> xnox: checkrdepends is probably better for that
[19:25] <xnox> ok.
[19:30] <slangasek> ah, seems the auto-hinting doesn't generate output anymore
[19:31] <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:32] <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:33] <xnox> and then we will just have to wait for powerpc builds to finish =(
[20:58] <ScottK> barry/slangasek: pyside isn't on my list of things I care about.
[21:00] <barry> ScottK: cool
[21:04] <xnox> infinity: eglibc breaks boost
[21:05]  * 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:06] <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:07] <xnox> https://svn.boost.org/trac/boost/changeset/78802/trunk/boost/thread/xtime.hpp
[21:08] <xnox> it's part of enum xtime_clock_types
[21:08]  * xnox so does not want to have boost transition :`(
[21:14] <infinity> xnox: I'm inclined to say that boost is broken, not glibc.
[21:15] <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:16] <xnox> infinity: released August 20th, 2012 23:00 GMT
[21:17] <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:21] <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:27] <xnox> infinity: I think I will apply patch to boost1.49 and if rdeps break then we will move to boost1.50
[21:31] <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:32] <infinity> xnox: If we're breaking ABI, we may as well just bump it correctly instead of fudging it.
[21:33] <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
[22:18] <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:41] <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:45] <xnox> and now transitioning to boost 1.50....
[22:46] <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:47] <ScottK> The latter.
[22:59] <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.
[23:00] <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:06] <ScottK> OK.
[23:07] <xnox> slangasek: autohinter did the magic to transition python3-defaults \0/
[23:08] <slangasek> perfect
[23:11] <xnox> and your boost fix works as well http://paste.ubuntu.com/1308399/
[23:43] <ScottK> Boost insanity is curable for once.
[23:45] <infinity> xnox: Good to hear.