[00:03] <infinity> barry: Can you SRU bug #938869 to precise as well?
[00:03] <infinity> barry: From my reading of it, it's just as buggy there, it's just that we haven't (yet) seen a a crazy upstream package that, say, sets a py3.2 PYTHONHOME and breaks python2.7.
[00:04] <infinity> barry: (Of course, the realisation that every other python script in /usr/(s)bin is wrong is a bit scary, but lsb_release does seem to be called an awful lot in these sorts of scenarios)
[00:09] <barry> infinity: indeed about the scary bit ;).  let me just verify that i can break it in precise and i'll sru it there to if necessary
[00:12] <infinity> barry: http://paste.ubuntu.com/1301515/
[00:13] <barry> infinity: cool
[00:14] <infinity> barry: Do I smell an ammendment to Debian Python Policy and a mass bug filing in the future?
[00:14] <barry> infinity: probably so.  i will be out tomorrow giving my talk, but i plan on at least bringing it up on the d-p list asap
[00:15] <infinity> barry: I'm not sure if it's sheer luck that this hasn't broken more often, or just proof that most of the python stuff in /usr/bin is useless. :P
[00:15] <barry> :-D
[00:15] <infinity> I have always wondered why lsb_release isn't a shell script.
[00:16] <infinity> Other than language flavor-of-the-month-ism.
[00:16] <infinity> Which is probably the reason.
[00:16]  * barry licks python
[00:16] <barry> er
[00:16]  * barry likes python
[00:17] <infinity> *snicker*
[00:17] <infinity> I can take it or leave it, but I could frame it differently.  I really like Perl, but I still think lsb_release should be a shell script.
[00:17] <infinity> Cause it does, well.  Nothing.  And hardly needs the massive memory footprint and load time to do all that nothing.
[00:18] <slangasek> infinity: why would you expect this to be common breakage?
[00:18] <slangasek> setting PYTHONHOME and then invoking system utilities seems crackful
[00:18] <slangasek> the only case I'm aware of that we've seen so far is with vmware
[00:19] <barry> slangasek: and what vmware is doing is crackful
[00:19] <slangasek> yep
[00:19] <infinity> slangasek: I'd expect it to be common if more of those system utilities were actually called by crackful third parties.  Luckily, most of the crack they call is likely all binaries.
[00:19] <barry> slangasek: -s makes some sense too, but i bet few users are putting anything in their user site directory
[00:20] <infinity> slangasek: I didn't claim the crack should happen more often, just that I suspect it probably does happen more often, and those people just don't call python binaries in the midst of their crack.
[00:20] <barry> slangasek: i'd say: it's an important thing to do when writing system scripts, but we needn't freak out about it
[00:20] <slangasek> right, exactly
[00:20] <infinity> And yeah, I agree that it's not worth a crazy freak out.  But a transition to -Es over time doesn't sound like the worst idea.
[00:22] <infinity> Anyhow, this all just came about from my "if we're fixing it in Q and R, we should fix it in P" thing, that's all.  Since we have 4.5 more years of P, I'm sure VMWare will at some point start shipping a bundled python3 that breaks P the way their bundled python2 breaks Q. :P
[00:22] <infinity> I'm such an optimist.
[00:26] <barry> infinity: sru'd and uploaded
[00:26]  * barry -> eod
[00:30] <infinity> barry: Thanks.
[00:30]  * infinity processes those and EODs himself.
[02:02] <hyperair> RAOF: turns out turning off semaphores really improved matters, and it's seeing something like 40-70% RC6pp residency now.
[02:02] <hyperair> RAOF: i'm suspecting that the semaphores were also causing the random hangcheck messages i was getting.
[02:05] <RAOF> Cool.
[02:43] <vibhav> Does anybody know how to setup a raring pbuilder chroot?
[02:45] <tsimpson> vibhav: create a precise chroot, change the sources.list to raring, and do a dist-upgrade
[02:45] <vibhav> ah, I thought there was another way to do that
[02:45] <tsimpson> erm, quantal, not precise
[02:46] <tsimpson> there are always other ways, you're using linux after all ;)
[02:47] <tsimpson> as a quick hack, sudo ln -s /usr/share/debootstrap/scripts/quantal /usr/share/debootstrap/scripts/raring
[02:47] <tsimpson> then just create a raring builder as you would a quantal one
[02:50] <vibhav> tsimpson: clever :)
[02:51] <tsimpson> vibhav: it's not that clever, once you realize that every release after gutsy only adds another symlink :)
[03:01] <tsimpson> vibhav: try here please
[03:06] <vibhav> !ping
[03:44] <pitti> Good morning
[03:45] <vibhav> hey pitti
[03:46] <vibhav> or rather, guten Morgen :)
[03:49] <pitti> vibhav: hehe :)
[03:53] <vibhav> :)
[04:07] <sarnold> pitti: another early morning? :)
[04:10] <pitti> sarnold: yeah; it's actually kind of my normal time now, depending on wether/how long I manage to sleep again after my wife gets up
[04:10] <sarnold> pitti: oof :) too early for me, by a long shot... but if it gives you an afternoon to yourself, hooray :)
[04:11] <pitti> right, that's the nice thing about it, and we have had stuff planned for pretty much every afternoon this week
[04:19] <sarnold> :)
[06:45] <DktrKranz> jelmer: huh? I really don't remember me behaving "confrontational"
[06:46] <DktrKranz> jelmer: I proposed some solutions, neither of those worked for Thomas, and I had better things to do than fighting
[06:47] <DktrKranz> jelmer: if you can get him convinced, feel free to reintroduce waf anytime
[06:48] <DktrKranz> .oO(then you'll have to fight with the software with ports, but that's another story)
[06:49] <lifeless> DktrKranz: you saw jelmers next line right? : 11:14 < jelmer> ScottK: actually, I retract that. The tone from several Debian developers towards waf upstream was very confrontational, rather than constructive.
[06:55] <dholbach> good morning
[06:56] <seb128> dholbach, salut
[07:29] <doko> barry, slangasek: maybe -E, but not -s for all scripts. call it the unix way to have user and local stuff precedence about system stuff
[07:47] <vibhav> Is it true that new uploads will go to raring-proposed?
[07:48] <pitti> vibhav: yes, https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036043.html
[07:50] <doko> xnox, I can understand --includes, but why --ldflags?
[07:50] <vibhav> ah, I was not aware of that. That idea sounds good too, nevertheless
[07:51] <vibhav> thanks pitti
[07:51] <pitti> vibhav: no, it doesn't sound good
[07:51] <pitti> it sounds OMGWANTTHISNOWGREAT! :-)
[07:52] <vibhav> heh
[07:52] <pitti> aka "never break dist-upgrades due to arch skew again"
[07:52] <pitti> and breaking ubiquity with a new glib, pygobject, etc.
[07:53] <vibhav> yeah, archive skews are something fearfull
[08:08] <vibhav> /win 9
[08:09] <mlankhorst>  /alias 9 win 9
[08:54] <ailo-w> apw: Hi. Just wanted to ping you about -lowlatency. I'm the kernel team guy in Ubuntu Studio, and the one who posted about it in the kernel mail list last month
[08:55] <apw> ailo-w, good timing ... i have just finished redoing the P one and uploaded it to the kernel team PPA
[08:57] <apw> ailo-w, we could do with some help confirming it works ok; if it is then the trees are both in a similar state and 'ready'
[09:07] <xnox> doko: to get the multiarch -L path. Unless I am doing something wrong and compiler is finding it anyway =)
[09:09] <doko> xnox, I think this would be wrong, although you should search for libpython3.3m.so
[09:09] <xnox> doko: ok.
[10:35] <jml> How stupid would it be to write code that assumes Contents-amd64.gz is alpha-sorted by FILE field?
[10:42] <mlankhorst> depends how easy it is to avoid that assumption :P
[10:45] <cjwatson> jml: I believe it's reasonably well guaranteed to be in strcmp() order by file
[10:45] <jml> cjwatson: thanks.
[10:46] <cjwatson> If you can avoid that assumption, do, but I appreciate that that file is large
[10:53] <jml> cjwatson: will do. I'll muck around a bit to see whether I get any significant speed gains by that assumption, and then make a completely irrational assessment as to whether they are worth it.
[10:53] <sawrub> hello all developers, i just installed 12.10 and i'm facing the long seen problem with the Atheros AR9485 WiFi under UBUNTU. Is there any fix on the way. the people at Fedora seems to have fixed the issue long back in July https://bugzilla.redhat.com/show_bug.cgi?id=736435#c8
[10:54] <cjwatson> sawrub: #ubuntu-kernel perhaps better
[10:54] <sawrub> but i'mm still facing the lockdown issue
[10:55] <sawrub> i'm not able to enjoy the wifi.
[10:56] <cjwatson> Sure, I'm just directing you to an IRC channel that's more specialised
[10:56] <sawrub> the only solution that i can find on the net is to use compact wireless
[10:56] <sawrub> http://ubuntuforums.org/showpost.php?p=11347273&postcount=63
[10:56] <sawrub> and what will that be
[10:57] <cjwatson> 11:54 <cjwatson> sawrub: #ubuntu-kernel perhaps better
[10:57] <sawrub> ok...let me ask there..thanks
[10:59] <ion> EXT4 Data Corruption Bug Hits Stable Linux Kernels http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ
[11:00] <mlankhorst> please don't link phoronix :(
[11:01] <ion> Please don’t “please don’t link phoronix”.
[11:02] <mlankhorst> :D
[11:29] <OdyX> xnox: about PySide, I welcome co-maintainers and try to avoid any distro diff as much as possible. The version currently in experimental is the latest upstream.
[11:30] <xnox> OdyX: ack. Well shiboken currently fails to build from source in quantal & raring. with any python.
[11:30] <xnox> OdyX: no 3.3 shiboken, no 3.3 PySide =(
[11:30] <xnox> bug 1070772
[11:31] <xnox> the bug is interesting, the unit test passes but upon clean up python interpreter itself segfaults after/during cleaning up floats. Maybe barry or doko can look into it ^^^^
[11:32]  * xnox is rebuilding in debian at the moment to see if debian is affected as well or not.
[11:36] <xnox> OdyX: in debian shiboken builds fine....
[11:53] <OdyX> xnox: eh :) It looks like a ubuntu python bug to me
[11:53] <doko> xnox, hmm, mpi4py had someting similiar, was fixed in http://launchpadlibrarian.net/120852567/mpi4py_1.3%2Bhg20120611-1_1.3%2Bhg20120611-2.diff.gz
[11:59] <xnox> doko: I'd agree with you, but the unit test passes in shiboken case (no asserts about ref-counts) it's just python segfaults after the unit-test has passed and said so.
[11:59] <xnox> and it segfaults all pythons after passing the unit test in Ubuntu, but everything is ok in Debian.
[12:00] <xnox> e.g. 2.7, 3.2 and 3.3 segfault on ubuntu, but 2.7 & 3.2 on debian does not.
[12:15] <barry> xnox: interesting.  i won't have time to look at this before i head to the conference today tho
[12:16] <xnox> barry: ack =) have fun
[12:27] <cjwatson> xnox: refcounting bugs are like malloc arena corruption - the crash is often well after the cause.  I wouldn't rule out a bug in the extension just yet if I were you.
[12:29] <xnox> cjwatson: thanks for explanation. ok.
[12:33] <cjwatson> valgrind might help a bit, though probably won't tell you what got the refcount wrong, only what acted on it (if it is indeed a refcounting bug)
[12:39] <barry> xnox: also, try it with a debug python
[12:42] <doko> dpkg: error: triggers ci file contains unknown directive ``time''
[12:42] <doko> E: Sub-process /usr/bin/dpkg returned an error code (2)
[12:42] <doko> never seen that
[12:57] <philballew>  ubuntu open week starts in #ubuntu-classroom in 5 minutes
[13:03] <xnox> stgraber: thanks for trianging to ibus. Do you think there should be "keyboard-inputs-indicator" which combines keyboars & input methods?
[13:05] <stgraber> xnox: I guess having ibus merged into the main keyboard configuration dialog and indicator would make sense, though there's the problem that they are separate projects and very likely aren't talking to each other...
[13:07] <xnox> stgraber: you'd think keyboard layout people would have a common interest in like keyboards.... =)
[13:17] <doko> barry, xnox: well, it's interesting that shiboken ignores the return values of the -dbg test runs, so it looks like the maintainer didn't care about failing test cases ...
[14:28] <ScottK> mitya57: A diff against Ubuntu for python-defualts isn't very helpful.  I'd really need to see the diff against current Debian.
[14:29] <mitya57> ScottK: bzr diff -r 56
[14:29] <mitya57> that's why I used Debian branch as a base :)
[14:29] <ScottK> OK.
[14:29] <ScottK> It'll have to wait until I have enough brain power to figure out using bzr for a review.
[14:30]  * ScottK virtually never does that.
[14:30] <infinity> slangasek: Are we meeting today?
[14:30] <slangasek> infinity: yes
[14:31] <infinity> slangasek: Mmkay.
[14:46] <sconklin> @pilot out
[14:58] <ScottK> What's the equivalent of getattr(sys, "pydebug") for python3?
[14:58] <ScottK> (that's still False in the python3.2-dbg interpreter)
[14:58] <ScottK> barry: ^^^
[15:00] <cjwatson> ScottK: "d" in sys.abiflags, possibly
[15:00] <cjwatson> ?
[15:00] <ScottK> Thanks.
[15:02] <ScottK> sys.abiflags[0] == 'd' works, but feels ugly.
[15:06] <cjwatson> ScottK: is it a good idea to depend on the order?
[15:07] <ScottK> Probably not.
[15:07] <ScottK> I guess 'd' in sys.abiflags[0] is less ugly.
[15:07] <cjwatson> Why [0]?
[15:07] <ScottK> err without the [0]
[15:07] <cjwatson> Right :)
[15:09] <ScottK> The lack of sys.pydebug in python3 seems odd, but I guess I'll move on.
[15:25] <doko> ScottK, hmm, I didn't re-add it for 3.3
[15:27] <ScottK> 'd' in sys.abiflags works, so I'm not stressed about it.
[15:34] <alexbligh> If I am packaging an program which contains shared libraries, Lintian is warning me that "non-dev-pkg-with-shlib-symlink", which I'm guessing means the shared library symlinks should not exist in the package. I can remove them, but what is it that runs ldconfig on install?
[15:35] <cjwatson> Those are two unconnected questions ...
[15:36] <cjwatson> The point is that .so links should generally go in a -dev package, not in the runtime package, because the only thing that needs the .so links (as opposed to .so.N) is the linker (ld) when building other packages against this library, not the runtime linker (ld.so)
[15:37] <cjwatson> ldconfig calls are inserted into your package's maintainer scripts by dh_makeshlibs
[15:37] <cjwatson> Incidentally, you don't need to guess what lintian messages mean; you can use lintian-info.
[15:38] <alexbligh> cjwatson, ah. So if this is a not a -dev package I can simply delete all symlinks in /usr/lib in the dist directory that the makefile for the undebianised things builds?
[15:38] <cjwatson> The details of exactly how to arrange it for any given build system vary.
[15:39] <cjwatson> Generally you install it into debian/tmp/ rather than debian/your-package-name/ (which dh_auto_install will do by default if you have multiple binary packages, as you should in this case) and then have dh_install pick the right files to put in each binary package.
[15:40] <alexbligh> actually, per the lintian-info thing, I think this is harmless
[15:40] <alexbligh> yes, it's actually a copy of the dist directory.
[15:40] <cjwatson> It is not the worst lintian error you could have, but it *is* generally wrong and should be fixed.
[15:40] <cjwatson> People expect shared library packages to be done in broadly the same way as all other shared library packages.
[15:41] <alexbligh> cjwatson, there are are LOT of things wrong with this package - I'm sort of looking for a quick and dirty hack and repackaging xen.
[15:41] <cjwatson> The exception is if it's a private library that isn't intended to be exposed outside this program, in which case you should put it in a private subdirectory of /usr/lib, not in /usr/lib itself.
[15:41] <cjwatson> Yeah, I'm not going to advise you on how to do things wrong, though :-)
[15:42] <alexbligh> cjwatson, I appreciate that :-)
[15:43] <alexbligh> dh_shlibdeps seems to complain if I start deleting symlinks.
[15:43] <alexbligh> so I'll guess I'll leave it in horrible hacked state for now.
[15:46] <cjwatson> Eh, the point isn't to delete symlinks
[15:46] <cjwatson> The point is to put them in the right binary packages
[15:50] <alexbligh> cjwatson, sure; what I'm saying is that if it's permissible for a 'small package', it isn't the worst sin in the world to do it on a larger package. Given the other horrors I have to contend with, I'm putting this in the 'mostly harmless' box :-)
[15:50] <alexbligh> (permissible per the lintian-info notes)
[15:51] <cjwatson> Yeah, I read those notes after I said that and I think they're far too lenienet.
[15:51] <cjwatson> Or misphrased.
[15:51] <cjwatson> I have a 50KB library package which does it right.  Can't get much smaller.
[15:52] <alexbligh> after all, xen4.2 is a really small package (cough cough)
[17:18] <xnox> doko: my python3-defaults package may be slightly wrong, as I have a broken symlink
[17:18] <xnox> /usr/lib/pkgconfig/python3.pc -> python-3.3.pc
[17:18] <xnox> it should be
[17:19] <xnox> /usr/lib/pkgconfig/python3.pc -> ../../$(arch)/pkgconfig/python-3.3.pc
[17:19] <xnox> or better for python3.pc symlink to be in /usr/lib/$(arch)/pkgconfig/
[17:26] <xnox> ScottK: in CMake pkg_check_modules(PYTHON python-3.3) actually does the right thing.... if packages build using PYTHON_INCLUDE_DIRS
[17:27] <xnox> the FindPythonLibs.cmake included with cmake itself kind of assumes there will be a single non-abi qualified include dir, which is not the case for the multiarched 3.3
[17:28] <ScottK> A quick grep of the PyKDE4 source suggests it does not.
[17:28] <ScottK> sip4 will DTRT with multiple include dirs, but I had to patch python-qt4 configure to take advantage of that.
[17:36] <xnox> ScottK: sorry, do you say that FindPythonLibs.cmake is correct, and it's just that my package is doing something odd?! Where is yout python-qt4 ?
[17:37] <ScottK> No, I said sip4 handles it.
[17:37] <xnox> ok.
[17:37] <ScottK> I didn't look at cmake
[17:37] <ScottK> python-qt4 is ~done.
[17:37] <xnox> ack.
[17:38] <ScottK> Here's the configure patch: http://www.riverbankcomputing.com/pipermail/pyqt/2012-October/032049.html
[17:38] <ScottK> In case you were wondering.
[17:39] <xnox> Ah, I see what you did there =)
[17:39] <xnox> nifty
[18:10] <doko> xnox, meh, yes, but it's an arch indep package ...
[18:12] <doko> would be nice if pkgconfig had a predefined multiarch macro when called as <triplet>-pkgconfig
[18:12] <jdstrand> barry: hi! do you think that you could poke someone on http://bugs.python.org/issue13512? (CVE-2011-4944) the last comment is that it will be ported to 3.2 soon, but nothing happened with it. I fixed this in py3.2 in quantal with 3.2.3-6ubuntu3.1, but raring 3.3 and 3.2 need it
[18:14] <jdstrand> barry: it isn't a big deal, but it would be nice to get it applied upstream
[18:15] <xnox> doko: last time this was brought up by wookey ( i think ) the "meta-packages" to select the default arch:any packages should also be arch:any.
[18:15] <xnox> Otherwise multi-arch will not be able to do it's multiarch magic.
[18:16] <xnox> cause it will not know how to do an M-A jump arch:all -> arch:any dep.
[18:16] <doko> yeah, at least the libpythonX.Y-foo packages have to
[18:16] <xnox> doko: where foo is dev ?
[18:16] <xnox> =)
[18:17] <doko> as dev, stdlib, etc
[18:17] <xnox> well all of them to be honest.
[18:17] <doko> haven't to be all, I think. why the packages with the binary symlinks?
[18:19] <xnox> because otherwise I will not be able to do build-dep python3:any
[18:21] <doko> hmm, maybe
[18:21] <doko> ohh I hate this multiarch stuff now
[18:22] <doko> xnox, should fixed packages be uploaded to the ppa, and then copied to the distro?
[18:22] <xnox> doko: I am not sure =) but for one package I uploaded into both.
[18:23] <xnox> doko: plus this round of uploads has slightly wrong changelog entries (i didn't pass --nomultimaint to dch, while my ~/.devscripts was setting it)
[18:23] <xnox> so currently there are [ Joe Bloggs ] * Rebuild for python3.3 -- Dmitrijs Ledkovs
[18:23] <xnox> entries =/
[18:24] <xnox> doko: are you fixing up python3-defaults?
[18:24] <doko> well, fixing will be splitting the packages ...
[18:24]  * xnox haven't worked out how to bump the version in debian/changelog yet still have packages matching in version number with the real pythonX.Y default version number.
[18:25] <xnox> doko: create .pc symlink at postinst? =)))))
[18:25]  * xnox hopes slangasek doesn't notice this suggestion.
[18:26] <doko> well, as a quick fix I consider adding this link into the libpython3.3-dev package
[18:26] <doko> and removing it from the python-defaults package
[18:27] <xnox> doko: but how would libpython3.3-dev know it's the default?
[18:27] <slangasek> good way to avoid me noticing
[18:27] <slangasek> since I have /hilight and /ignore confused
[18:27] <doko> xnox, because it will be in the ppa
[18:28] <xnox> doko: ok. what about the real fix.
[18:28] <slangasek> what .pc files are you talking about?
[18:28] <doko> later, not before uds
[18:28] <slangasek> why would a .pc file not be shipped in the per-arch directory?
[18:28] <xnox> slangasek: python3-dev ships symlink python3.pc -> python3.X.pc
[18:29] <slangasek> ok, so if it wasn't already clear, python3-dev needs to be Arch: any
[18:29] <xnox> slangasek: currenlty python3-dev is arch:all package, but since 3.3 is multiarched, the meta-packages should be "multi-arched" as well, which for really means arch:all -> arch:any
[18:29] <slangasek> I have filed bugs in the past about this - python(3)-defaults need to be made arch: any
[18:30] <slangasek> doko: ^^ you understand this, right?  We need to be able to specify the needed architecture of python3-dev for cross-building
[18:30] <xnox> slangasek: all packages it builds? I looks like -doc can stay as arch:all, not sure about idle3 (it has python3 = ${binary:version} so probably arch:all as well)
[18:31] <doko> slangasek, I do understand that it's not needed to make 3.3 the default. that's the priority for now
[18:31] <slangasek> xnox: yes, sorry, was being overly brief there
[18:31] <xnox> doko: the boost-defaults builds all packages as arch:any
[18:31] <slangasek> doko: true
[18:31] <xnox> ack.
[18:31] <slangasek> xnox: AFAIK the only one we care about is -dev
[18:32] <slangasek> doko: it's not the immediate priority, but it does need to be solved this cycle; I filed a bug about this about a year ago, and it blocks cross-bootstrapping
[18:32] <doko> so, I'll prepare an python3.3 upload for the ppa
[18:32] <xnox> slangasek: I thought we equally care a lot about "Build-Dep: python3:any"
[18:32] <xnox> doko: thanks.
[18:33] <slangasek> xnox: you only build-depend on python3 (instead of python3-dev) when you aren't building C extensions; therefore you don't care about the architecture of python3 being installed; so it can be Arch: all and rely on arch-all build-deps being implicitly Multi-Arch: foreign
[18:33] <doko> slangasek, there will be so many python cross build failures ... none of the various python build systems supports cross building
[18:34] <slangasek> doko: that's beside the point.  Not having Arch: any python3-dev is *blocking* fixing those things.
[18:36] <doko> slangasek, you didn't, at least not for python3-defaults
[18:36] <slangasek> doko: possibly the bug was only filed against python-defaults.  I can open a new task :)
[18:37]  * xnox slangasek's bugs outlive python2
[18:39] <doko> slangasek, better file a new one, your memory seems to be corrupted ;-)
[18:39] <slangasek> doko: bug #934593, which you closed and didn't reopen after you reverted the change! :)
[18:40] <slangasek> (bug reopened)
[18:41] <doko> ahh, that one
[18:43] <xnox> So to fix the bug correctly: python3-dev should be arch:any package with symlink /usr/lib/$(arch)/pkgconfig/python3.pc -> python-3.X.pc
[18:43] <slangasek> yes
[18:43]  * xnox off to have dinner and will poke python3-defaults after that.
[19:22] <doko> xnox, how do you track the packages which you fix for the test rebuild?
[19:23] <doko> http://people.canonical.com/~xnox/py3.2/python3.2.html doesn't show any progress
[19:25] <doko> slangasek, xnox: the proper fix is to split out libpython3-{stdlib,dev,dbg} packages *and* make all of these arch any
[19:26] <slangasek> doko: what's the purpose of python3-dev, that would make it different from libpython3-dev/
[19:28] <doko> slangasek, having the python3.3-config binary
[19:29] <slangasek> doko: and is it really useful to split the python3-dev package just for python3.3-config?
[19:29] <slangasek> it seems obvious to me that making python3-dev Arch: any is much simpler
[19:30] <doko> probably simpler, but how do you install a host interpreter, plus a target python-dev?
[19:31] <doko> most python build systems do use python as implementation for the build system
[19:33] <slangasek> python3-dev Arch: any Depends: python3.3-dev Arch: any Depends python3.3:any, with python3.3 as Multi-Arch: allowed?  (Or Depends python3.3 with python3.3 as Multi-Arch: foreign, whichever is correct)
[19:37] <doko> why should it be allowed, and not same?
[19:38] <slangasek> assuming you mean foreign rather than same (since same is definitely wrong for an interpreter package): "allowed" would be correct if it contains libraries as well as the interpreter, otherwise "foreign"
[19:39] <doko> well, libpython3.3-dev is m-a same, as libpython3-dev would be too
[19:39] <slangasek> if libpython3.3 is M-A: same, and all the library bits are in libpython3.3, then python3.3 can probably be M-A: foreign
[19:43] <doko> right, libpython3-{stdlib,dev,dbg} would be m-a same, and python3{,dev,-dbg} would be m-a foreign
[19:44] <slangasek> doko: er, except then you're changing the policy for python build-dependencies
[19:45] <doko> but then how do I build not using the "target" interpreter?
[19:45] <slangasek> doko: right now, packages that build extensions build-depend on python3-dev.  Splitting libpython3-dev out of python3-dev, and making python3-dev M-A: foreign, means packages would have to build-depend on libpython3-dev to be cross-buildable
[19:46] <slangasek> doko: apt will prefer to install the host version of any package that's marked Multi-Arch: foreign
[19:46] <doko> yes, this was my intention
[19:46] <slangasek> oh, I think I see the issue now
[19:47] <slangasek> /usr/bin/python3-config is not the same on all architectures, right?
[19:47] <slangasek> so it can't be in a M-A: same package
[19:47] <doko> yes
[19:47] <slangasek> ok
[19:48] <doko> currently it's meaningless because it's written in python, but it will be replaced by a shell script again
[19:48] <slangasek> so actually, I'm not sure it matters to have python3-dev as M-A: same... if it's M-A: none, it should still work
[19:48] <slangasek> then when cross-building, Build-Depends: python3-dev gets you the target arch version of python3-dev and the host-arch version of python3
[19:48] <doko> and python3.3-dev depends on python3.3, with  a different binary too
[19:49] <slangasek> you can't install more than one copy of python3-dev side-by-side, but for a first pass I don't think that's required
[19:49] <doko> ok, then let's delay the split of the python3-defaults packages for now
[19:49] <slangasek> "python3.3-dev depends on python3.3" but that's ok, isn't it?  You should be able to use python3.3-dev:target + python3.3:host
[19:50] <doko> no
[19:50] <slangasek> why not?
[19:50] <doko> I can't see how this would be right
[19:51] <doko> if the build uses information from the sys or sysconfig modules, then these will come from the host, not the target
[19:51] <slangasek> if I'm not mistaken, it's right because python3.3 is *just* the interpreter, and python3.3-dev depends on the interpreter (which is Multi-Arch: foreign) + the lib (which is Multi-Arch: same)
[19:51] <slangasek> ok
[19:51] <slangasek> but that's a problem with the build system not being cross-build-safe
[19:52] <slangasek> I don't think there's any rearrangement of the interpreter packages that we can do to fix that
[19:52] <slangasek> installing the target-arch python3.3 doesn't solve the problem for a true cross-compile situation where you don't have qemu
[19:52] <slangasek> (such as, to pick a random example, aarch64)
[19:52] <doko> yes, known
[19:53] <slangasek> So I think python3.3-dev:target + libpython3.3:target + python3.3:host is still correct, and we just have to defer the fact that many build systems aren't cross-compile safe
[19:54] <doko> the trick for distutils I am using is to set an env var to use the host python with the target standard library
[19:54] <slangasek> but in the base system, there are a lot of *non*-python build systems being used which are cross-build-safe, they just need the right libpython available
[19:54] <doko> which works ok, as long as I'm only relying on sysconfig, not on the builtin sys module
[19:54] <slangasek> right
[19:55] <doko> indeed, and my idea was to have these packages now build-depend on libpython3-dev
[19:58] <slangasek> I still think it's better to keep everything build-depending on python3-dev; that way it doesn't require changing python policy or changing build-dependencies, and that change doesn't help cross-compile without qemu anyway so I think we should take our time to look for a better solution for those
[20:02] <ScottK> Help.
[20:02] <ScottK> In debian/rules for python-qt4, I have: configure: $(PYTHONS:%=pyqtconfig-%) $(PYTHONS:%=build-%/configure-stamp) $(PYTHONS:%=dbg-build-%/configure-stamp)
[20:03] <ScottK> I've added the $(PYTHONS:%=pyqtconfig-%) rule.
[20:03] <ScottK> If I run make -f debian/rules configure, then the pyqtconfig rule runs.
[20:04] <ScottK> But when I build the package, it does not (even though the build/dbg-build rules do)
[20:04] <ScottK> Any suggestions?
[20:04] <doko> slangasek, well, that would be brainstorming session for uds. I don't think that it will require a change to the python policy, as everything still builds, and python policy doesn't touch multiarch. and the b-d change ... how many packages are cross-buildable out of the box anyway
[20:04] <slangasek> ScottK: are you cleaning in between?
[20:04] <slangasek> doko: python policy says what build-dependencies are supposed to be
[20:04] <ScottK> No.
[20:04] <slangasek> ScottK: is pyqtconfig-$ver a real file?
[20:04] <slangasek> (pointer to source?)
[20:04] <ScottK> No.
[20:05] <ScottK> Let me publish this somewhere.
[20:06] <doko> slangasek, so yes, keep it unchanged, change it where it's needed for m-a
[20:06] <slangasek> doko: ok.  in the meantime, will we still get Arch: any python3-dev?
[20:07] <slangasek> because that's still a blocker
[20:07] <doko> yeah, for the first milestone
[20:07] <slangasek> great, thanks :)
[20:09] <ScottK> slangasek: http://kitterman.com/kubuntu/python-qt4_4.9.5-1ubuntu1.dsc should be dget'able.
[20:10] <slangasek> dgotten
[20:10] <ScottK> Thanks for having a look.
[20:10]  * ScottK needs to get up off the keyboard.
[20:10] <slangasek> do I need raring in order to build this, or should it be quantal-compatible?
[20:10] <ScottK> off/from
[20:10] <ScottK> You need raring.
[20:11] <slangasek> ok
[20:11]  * slangasek gets his raring chroot set up while looking
[20:11] <ScottK> Actually, or my PPA.
[20:11] <doko> ScottK, any quick idea where to fix the missing python include in boost?
[20:11] <ScottK> doko: None.
[20:11] <ScottK> ajmitch loves boost though.  Maybe he does.
[20:13] <ajmitch> you're always trying to drop me in it
[20:13]  * doko looks if he succeeds ...
[20:14] <slangasek> ajmitch: doesn't knowing that you're wanted give a boost to your self-esteem?
[20:14] <ajmitch> slangasek: that pun certainly causes tears
[20:14] <slangasek> you're welcome
[20:18] <xnox> doko: that page is *static* :-D
[20:19] <Laney> xnox: I have a cool idea about ben
[20:19] <Laney> it's in the skunkworks atm
[20:21] <xnox> Laney: what processing ~/transitions/ ? Or scp'ing ben.native? =)
[20:24] <jcastro_> Riddell: heya, you going to be @ UDS for the flavors plenary? I sent a mail to kubuntu-devel.
[21:05] <cjwatson> doko: cross-buildable out of the box> possibly more than you'd think, at least as of quantal (or even precise); it's not great, but it's not completely hopeless either
[21:06] <xnox> Laney: is ben backported to 12.04?
[21:06] <doko> cjwatson, I'm just having my doubts with python related cross builds ...
[21:06] <cjwatson> I think we had half the build system cross-building?
[21:06] <cjwatson> er base system
[21:07] <cjwatson> sure, I expect python's ecosystem will take a while :)
[21:07] <doko> now trying to understand jam, to fix boost ...
[21:10] <ScottK> At least I saved you dealing with sip.
[21:15] <doko> ScottK, sip4 builds did finish, didn't see the python-qt4 upload ;-P
[21:16] <ScottK> Not quite there yet.
[21:25] <slangasek> ScottK: well, one thing is that you define a target for pyqtconfig-3.% but are patterning over $(PYTHONS) which includes python2
[21:26] <slangasek> oh, but you have an explicit pyqtconfg-2.7 below
[21:26] <ScottK> Yes.
[21:26] <slangasek> so I suppose that should work
[21:26] <ScottK> Running configure directly failed without that.
[21:27] <ScottK> Switching to like I had it in sip4 doesn't help either.
[21:27] <ScottK> configure: $(PYTHONS:%=build-%/configure-stamp) $(PYTHONS:%=dbg-build-%/configure-stamp)
[21:27] <ScottK> build-%/configure-stamp: $(PYTHON3S:%=sipconfig-%)
[21:28] <slangasek> +install-arch-3.%: pyqtconfig-%
[21:28] <slangasek> that seems wrong?
[21:28] <slangasek> (but is probably not relevant)
[21:29] <slangasek> ScottK: oh; when I asked if these were real files you said they weren't
[21:30] <slangasek> ScottK: but you're clearly touching them
[21:30] <ScottK> They are real after I touch them.
[21:30] <slangasek> so if you don't clean between builds, they won't be remade
[21:30] <ScottK> Right, I remove them in clean.
[21:30] <slangasek> ok
[21:30] <ScottK> The problem is they never get touched at all, so I know the rule never ran.
[21:30] <xnox> ScottK: or make sure the target ends in -stamp, then it will be auto-removed for you.
[21:31] <xnox> with dh_clean.
[21:31] <xnox> hm..
[21:31] <ScottK> xnox: More automagic after it works.
[21:31] <xnox> =))))))))))
[21:31] <xnox> mvo are you about?
[21:31] <ScottK> The install-arch thing is a leftover of a previous attempt.
[21:32] <slangasek> ScottK: ah.  Nothing actually depends on your configure rule.
[21:32] <ScottK> Hmmm.
[21:32] <ScottK> That would do it.
[21:33] <slangasek> the configure target depends on the configure-stamp targets; it should normally be the other way around...
[21:33] <slangasek> er, no
[21:33] <slangasek> that part is right - but then things should depend on configure instead of directly on the stamps
[21:34] <slangasek> probably simplest to make the build-arch target depend on configure
[21:34] <ScottK> OK.
[21:34]  * slangasek tests
[21:34] <slangasek> looks good-ish so far
[21:34] <ScottK> I need to leave for the evening, so if you make it work, feel free to upload, although I'm not sure all the pushing stuff around in install-arch related to pyqtconfig is right (since I didn't ever test it yet)
[21:36] <slangasek> gah, now you're going to make me review the whole diff :P
[21:37] <ScottK> That or pm me yours and I'll finish it later.
[22:20] <xnox> python3, arch:all package only needs to be built once with 'python3' interpreter with correct forward looking X-Python3-Version tag. Because pycompile does the rest at install time and there are no python3.X specific files/paths generated.
[22:20] <xnox> True or False?
[22:32] <Riddell> jcastro_: yeah I got that, no immediate volunteers from the community so sign up my name
[22:38] <slangasek> xnox: TTBOMK that's correct
[22:39] <xnox> slangasek: good.
[22:49] <doko> xnox, I still would build for all supported versions to check for incompatibilities
[22:50] <doko> an issue which currently not addressed is how to detect any diff
[22:51] <xnox> doko: ok. but Build-Dep: python3 && building against py3versions -s is wrong =)
[22:53] <doko> sure
[23:07] <wookey> if this doesn't work: from util import get_fh_out
[23:07] <wookey> what package am I missing?
[23:14] <slangasek> wookey: that doesn't appear to be a standard python module.  What's the context?
[23:15] <wookey> running 'multiarchify.py from johannes' bootstrap tools
[23:15] <wookey> Ah OK, maybe that's why I can;t find it - must be in the rest of his code somewhere
[23:15] <slangasek> must be
[23:15] <wookey> I assumed there was some standard module
[23:16] <wookey> ah yes - found it
[23:17] <wookey> that script munges a packages file to make everything arch:all, M-A:none into M-A: foreign, which should woork round difference between ubuntu apt and libdose
[23:17] <wookey> attempting to check this...
[23:19] <xnox> doko: if you really want to build arch:all against all supported py3s then reject auto-upgrade-testing and feedparser and I will reupload fixing the build-deps to be python3-all, instead of building with python3 only.
[23:22] <doko> xnox, rejected
[23:22] <xnox> ack.
[23:27] <xnox> doko: hmm... did you reject my proposal to reject those packages and hence accepted them. Or did you accept by mistake?
[23:27]  * xnox is confused
[23:52] <xnox> I just wanted to point out that drinking decaf coffee is great after 9pm =)
[23:53] <chrisccoulson> xnox, drinking fully caffeinated coffee after 9pm is even better :)
[23:53] <slangasek> nah; after 9pm you're just supposed to add whiskey to it to balance it out
[23:54] <mwhudson> one of the pitfalls of uds is that it's easy for _everything_ you drink to contain alcohol or caffeine
[23:54] <slangasek> mwhudson: I don't understand
[23:54] <slangasek> how is this a pitfall? ;)
[23:54] <mwhudson> (or, occasionally, both)
[23:55] <mwhudson> slangasek: dehydration isn't a barrel of laughs :-p
[23:55] <xnox> mwhudson: but one barrel whiskey is :-P
[23:55] <barry> slangasek: hopefully you're not going to propose a foundations vs kernel team drinkoff
[23:55] <slangasek> mwhudson: I prefer to think of it as distilling my inner geek
[23:55] <StevenK> barry: That could end up with a large trip to the hospital
[23:55] <mwhudson> xnox: i dread to think how much decent whisky is going to cost in the hotel bar
[23:56] <barry> StevenK: i suppose i better pack my portable stomach pump
[23:56] <StevenK> barry: Haha
[23:58] <xnox> mwhudson: well, we are suppose to judge everything by mobile metrics now. So surely smaller in size, higher value and better kick is on the right path ;-)