[04:29] <pitti> Good morning
=== kitterma is now known as ScottK
[05:42] <pitti> doko: uh, does xenial's gcc-5 change anythihng significantly? I did a test libpng run on ppc64el, and it crashes with "cc1: internal compiler error: Illegal instruction"
[05:42] <pitti> (armhf is fine)
[05:45] <pitti> doko: "Target POWER8 on ppc64el" -> that?
[05:45] <pitti> doko: I suppose wolfe is not that yet
[05:46] <pitti> infinity, slangasek, doko: ^ so if this is deliberate (I suppose it is), is there some power8 hardware which we could use for running autopkgtests? or should we stop testing xenial on ppc64el for now?
[06:28] <dholbach> good morning
[06:43] <mgedmin> how come some -dbgsym packages are available only for i386?  (e.g. gjs-dbgsym)
[06:45] <seb128> mgedmin, what do you mean? https://launchpad.net/ubuntu/+source/gjs/1.43.3-2build1/+build/7778128/+files/gjs-dbgsym_1.43.3-2build1_amd64.ddeb
[06:45] <seb128> (https://launchpad.net/ubuntu/+source/gjs/1.43.3-2build1/+build/7778128)
[06:45] <mgedmin> huh
[06:46] <mgedmin> my apt does this: http://paste.ubuntu.com/12900653/
[06:47] <seb128> mgedmin, dpkg -l | grep gjs ?
[06:47] <mgedmin> http://paste.ubuntu.com/12900658/
[06:47] <mgedmin> (amd64)
[06:48] <seb128> hum, your issue seems more a multiarch one
[06:48] <seb128> sudo apt-get install gjs-dbgsym:amd64 ?
[06:50] <mgedmin> gjs-dbgsym doesn't appear in the Packages file for amd64: http://paste.ubuntu.com/12900661/
[06:50] <mgedmin> check http://ddebs.ubuntu.com/dists/wily/universe/binary-amd64/Packages
[06:50] <seb128> pitti, ^
[06:51] <mgedmin> libmozjs-24-0v5-dbgsym is another package with this issue
[06:51] <mgedmin> while libglib2.0-0-dbgsym can be installed with no problems
[06:56] <seb128> mgedmin, you can get the deb manually meanwhile
[06:56] <seb128> unsure what's the deal with ddeb nowadays
[06:56]  * mgedmin once again dreams about symbol servers
[06:56] <seb128> we have them in launchpad but unsure if there is an apt index there
[06:56] <pitti> hmm, no immediate idea; I'll put it on my todo list
[06:56] <seb128> symbol servers?
[06:56] <mgedmin> indexed by buildid's that are embedded in elf binaries
[06:57] <pitti> http://ddebs.ubuntu.com/pool/universe/g/gjs/ also has them
[06:57] <pitti> they are just missing in the index
[06:57] <mgedmin> seb128, https://randomascii.wordpress.com/2013/02/20/symbols-on-linux-part-three-linux-versus-windows/
[07:00] <seb128> mgedmin, I see, well ddebs with apport usually work fine, there is just an index/server issue there
=== cpaelzer_ is now known as cpaelzer
=== davidcalle_ is now known as davidcalle
[09:14] <doko> pitti, slangasek: better stop then ... until you get hardware.
=== sletta_ is now known as sletta
[09:34] <pitti> doko: I'll re-ask on the RT ticket for getting ppc64el in scalingstack
[09:34] <Mirv> dholbach: hmm, I'm not seeing any UOS calls on ubuntu-devel lists other than September's proposed dates
[09:36] <dholbach> Mirv, how can I help?
[09:40] <seb128> Mirv, it's on -announce
[09:42] <seb128> Riddell, good luck for whatever you do next, I hope you have more fun that you had recently with all those discussions!
[09:43] <Riddell> thanks seb128 :)
[09:50] <cjwatson> pitti: I think you should be able to get access to bos01 scalingstack for autopkgtests.
[09:56] <Mirv> dholbach: oh, announce as mentioned, no problem :)
=== oSoMoN_ is now known as oSoMoN
[10:03] <pitti> cjwatson: thanks; I pinged the RT again
=== lan3y is now known as Laney
=== ming is now known as Guest66148
=== balkamos_ is now known as balkamos
=== rsalveti_ is now known as rsalveti
=== mchro- is now known as mchro
=== plars_ is now known as plars
=== broder_ is now known as broder
=== \b is now known as benonsoftware
=== hikiko is now known as hikiko|ln
=== _fortis_ is now known as _fortis
=== tjaalton_ is now known as tjaalton
=== s1aden is now known as sladen
=== davmor2_ is now known as davmor2
[11:06] <doko> jamespage, tyhicks:  https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1363356  looks more like an openssl update issue, seen for openstack too
[11:06] <ubottu> Launchpad bug 1363356 in python-defaults (Ubuntu) "ssl.SSLEOFError: EOF occurred in violation of protocol" [Undecided,Confirmed]
=== hikiko|ln is now known as hikiko
[11:24] <pitti> sil2100: is rtm 14.09 still a thing? i. e. do I need to keep running http://ddebs.ubuntu.com/ubuntu-rtm/, or can it be mothballed?
[11:24] <sil2100> pitti: hey! I think the grace period for ubuntu-rtm/14.09 has now passed
[11:24] <sil2100> I don't think there's any reason to keep that
[11:25] <pitti> sil2100: ack, tahnks
[12:03] <doko> pitti, apport autopkg test failures
=== popey_ is now known as popey
[12:14] <pitti> doko: yep,  known; fixed in trunk already
[12:14] <pitti> doko: for the current version the hint is still in place
=== gonzzor_ is now known as gonzzor
=== _salem is now known as salem_
[12:24] <pitti> hm, quite some regressions due to uninstallability
[12:25] <pitti> doko, infinity ^ I'll retry them once the queue settled down
[12:26] <doko> pitti, need to build some python3.5 extensions for that. waiting for gcc-5 to be published
[12:28] <doko> barry, xnox: looking at http://people.canonical.com/~ubuntu-archive/transitions/html/onlypy3oncd.html  how up to date is this? e.g. libreoffice looks fine?
[12:29] <xnox> doko: it is a manually updated list.
[12:29] <xnox> doko: there is a script in the branch to regenerate said tracker....
[12:29] <xnox> cause the seeds move often, and it's just a static list/table really.
[12:30] <doko> xnox, which branch?
[12:33] <xnox> doko: well the code lists it =)
[12:33] <xnox> http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/view/head:/monitor/ongoing/onlypy3oncd.ben
[12:33] <xnox> title = "Python3 only on CDs (xnox, barry, see lp:~dmitrij.ledkov/+junk/onlypy3oncd)";
[12:33] <xnox> no idea if that is actually still usable though, may have bit rotted
[12:33] <doko> ahh
[12:33] <xnox> and that's not my lp id any more....
[12:33] <xnox> so lp:~xnox/+junk/onlypy3oncd
[12:33]  * xnox goes to try it.
[12:34] <doko> ta
[12:34] <xnox> doko: omg, that thing is a python2 script that connects to barry's spreadsheet....
[12:35] <xnox> on google docs. I bet it's all wrong.
[12:36] <doko> heh
[12:36] <xnox> i bet what i should have done is download a binary package list, map them to source packages and validate none depend on python3.
[12:36] <xnox> or rather none depend on python2 exclusively.
[12:36] <xnox> doko: we don't have a current oustanding list is the short answer =)
[12:37] <doko> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3 is the one I am tracking
[12:37] <doko> so maybe better remove this tracker
[13:16] <doko> barry, looks like python-coverage needs a new upstream. somehow important, because a lot of things are uninstallable until this gets fixed
[13:16] <Mirv> doko: can you look at bug #1509356 , jgdx can't build on xenial because of that
[13:16] <ubottu> bug 1509356 in pep8 (Ubuntu) "pep8 depends on python3-pep, not python3-pep8" [Undecided,New] https://launchpad.net/bugs/1509356
[13:17] <doko> Mirv, mehh, typo ...
[13:17] <pitti> ah, I saw quite some test failures due to that too, I think
[13:17] <doko> fixing
[13:17] <pitti> danke!
[13:17] <Mirv> +1!
[13:28] <mapreri> cjwatson: can you unblacklist scribus from syncing now that wily is out and xenial is on its way? :)
[13:29] <doko> mitya57, https://launchpadlibrarian.net/222306433/buildlog_ubuntu-xenial-amd64.relational_2.1-1_BUILDING.txt.gz   the shebang really should be the unversioned python3 interp
[13:29] <cjwatson> mapreri: done
[13:30] <mitya57> doko, why me? I don't know what relational is
[13:30] <mapreri> cjwatson: ♥
[13:30] <doko> mitya57, but you are suspicious about pyqt ;p
[13:30] <doko> or better, the suspect
[13:31] <mitya57> Ok, I can take a look, not right now though
[13:31] <stokachu> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stokachu
[13:47] <Odd_Bloke> wgrant: cjwatson: infinity: Which kernel package should I be using for powerpc?  linux-image-powerpc-smp?
[13:52] <cjwatson> Odd_Bloke: The stock images have powerpc-smp and powerpc64-smp installed.  But for cloud images I'd have thought powerpc64-smp would be a better choice.
[13:53] <cjwatson> Odd_Bloke: That's what the current LP builders are using.
[13:53] <cjwatson> And surely anything you might want to run a cloud on has 64-bit support ...
[13:55] <pitti> mgedmin, darkxst, seb128: ddeb indexes should be okay now, gjs and libmozjs* are at least there
[13:55] <cjwatson> (You could tell lb to install both, but I don't know if it's worth the effort.
[13:55] <cjwatson> )
[13:56] <infinity> Odd_Bloke: Should just be powerpc64-smp
[13:56] <Odd_Bloke> cjwatson: Ah, I think I must be labouring under a misapprehension.  I'm assuming that powerpc is to ppc64el as i386 is to amd64; have I got the wrong end of the stick?
[13:56] <infinity> Odd_Bloke: That's the only one that will work the way we'll be booting in openstack.
[13:57] <infinity> Odd_Bloke: powerpc *userspace* is 32-bit, but the vast majority of machines (including the KVM instances) are 64-bit, hence the 64-bit kernel.
[13:57] <Odd_Bloke> Aha, right.
[13:57] <cjwatson> (The analogy there also doesn't quite work because of the endian flip, but that's not relevant here.)
[13:58] <infinity> It's entirely possible that the only person in the world who uses the 32-bit kernel is me. :P
[13:58] <cjwatson> It was relevant on some pretty old hardware, indeed.
[13:59] <infinity> Odd_Bloke: Anyhow, all you need to know is powerpc64-smp, boots in qemu-system-ppc64, same as ppc64el images do.
[13:59] <infinity> (Even on x86, though the emulation isn't desperately fast)
[14:00] <seb128> pitti, great, thanks
[14:04] <mitya57> doko, bug for relational: debian #802781
[14:04] <ubottu> Debian bug 802781 in relational "relational: Please fix X-Python3-Version value" [Important,Open] http://bugs.debian.org/802781
[14:05] <infinity> doko: That openjdk-9 in wily-proposed, is that meant to become an SRU, or should it be moved to xenial-proposed?  (or just deleted, since it's FTBFS on armhf?)
[14:05] <doko> mitya57, yep, this one too. still looking at pyqt5
[14:05] <infinity> doko: Hrm, I guess it was NEW, hard to see how that could be an SRU.
[14:06] <mitya57> What's wrong with pyqt5?
[14:06] <doko> infinity, no, just remove it. already uploaded to xenial for the giflib soname bump
[14:06] <infinity> doko: Alright.
[14:06] <Odd_Bloke> infinity: cjwatson: Thanks for the explanation, very clear. :)
[14:06] <doko> mitya57, /usr/bin/pyuic5: 2: exec: /usr/bin/python3.4: not found
[14:07] <doko> without a dep on python3.4
[14:07] <mitya57> doko, you did rebuild pyqt5, right?
[14:07] <doko> mitya57, not yet
[14:08] <doko> mitya57, but then it will still have a python3.5 shebang without a dep on python3.5
[14:13] <mitya57> doko, I see, will commit a fix soon
[14:13] <doko> mitya57, ta, then it will be good for to just do a rebuild =)
[14:13] <doko> for me, even
[14:14] <mitya57> Yes, and then I'll sync the new version from Debian when it's ready
[14:14]  * doko tries to figure out the cantor ftbfs ...
[14:17]  * infinity adds xenial to rmadison.
[14:33] <doko> mitya57, http://launchpadlibrarian.net/222321211/pyqt5_5.4.2%2Bdfsg-1build3_5.4.2%2Bdfsg-1ubuntu1.diff.gz
[14:33] <doko> calling dh_python3 with --shebang won't help
[14:34] <mitya57> doko, thanks
[14:35] <mitya57> Though I will place it in install-arch target
[14:36] <doko> sure
[14:38] <mitya57> committed
=== salem_ is now known as _salem
=== _salem is now known as salem_
[14:56] <doko> barry, are you looking at python-coverage, or should I?
[14:58] <barry> doko: i am not yet.  i'm still trying to fix a very problematic debian bug to unblock a bunch of other things
[14:58] <doko> ok
[15:00] <doko> mitya57, I assume we can drop the preinst delta now?  https://patches.ubuntu.com/p/python-coverage/python-coverage_3.7.1+dfsg.1-1ubuntu3.patch
=== gusnan_ is now known as gusnan
[15:18] <Kaleo> doko, just filed https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1509396
[15:18] <ubottu> Launchpad bug 1509396 in python-flake8 (Ubuntu) "Missing dependency on python-setuptools" [Undecided,New]
[15:18] <Kaleo> broken by http://launchpadlibrarian.net/222126620/pep8_1.6.2-0.1_1.6.2-0.1ubuntu1.diff.gz
[15:23] <bfiller> doko: thanks for your help on that one, it's currently blocking one of our dual landings
[15:31] <doko> seb128, are you sure about the glibmm2.4 sync? mbiebl was asking me why we reverted that version. I'd like to reject it
[15:31] <doko> bfiller, ???
[15:31] <bfiller> doko: https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1509396
[15:31] <ubottu> Launchpad bug 1509396 in python-flake8 (Ubuntu) "Missing dependency on python-setuptools" [High,New]
[15:32] <seb128> doko, unsure, but why shouldn't we follow Debian? I don't know exactly why robert reverted it previous cycle
[15:33] <seb128> and why are xenial uploads manually approved?
[15:33] <doko> seb128, because it assumes c++11 in its header files, and you'll have to fix every reverse build dependency explicitly
[15:33] <doko> still trying to get the toolchain into -release
[15:33] <seb128> well, if Debian does that and we go the other way, does it mean we have to diverge on things they "fix"?
[15:34] <doko> seb128, debian will have a compiler which defaults to c++14 in the end, xenial won't have this
[15:35] <seb128> k, your call, I don't understand enough of what is involved to have an opinion
[15:36] <doko> seb128, lets wait for the decision in debian; I think mbiebl_ is still unsure about it
[15:36] <seb128> doko, note that the new gtkmm got synced in wily
[15:36] <seb128> unsure if that's on the same line
[15:37] <seb128> doko, ok
[15:37] <doko> seb128, I don't know, in wily only glibmm had the c++11 header files
[15:37] <seb128> k
[15:38] <doko> I mean, it is fixable, but if debian doesn't do it because it gets "fixed" by a new compiler default, we have to do it
[15:39] <seb128> yeah, let's wait for that then
[15:39] <seb128> no hurry  in getting the new version
[15:50] <seb128> doko, we have a pending libreoffice change to upload, it's a bit of a waste of builders to do a non change rebuild :-/
[15:51] <doko> seb128, didn't see one in the queue =)
[15:51] <doko> feel free to cancel and upload the new one
[15:51] <seb128> doko, yeah, it's waiting sponsoring
[15:52] <seb128> let me check with Bjoern
[15:57] <doko> jamespage, zigo: please could you discard your openstack packaging rules, and just use plain pybuild for the future? this home grown template adds a lot of issues ... https://launchpadlibrarian.net/222329745/buildlog_ubuntu-xenial-amd64.python-json-patch_1.3-5build1_BUILDING.txt.gz
[16:04] <jamespage> doko, sorry being dumb - what's the specific problem?
[16:04] <jamespage> the openstack packaging rules don't do much with regards to actually building a py package from memory
[16:05] <doko> jamespage, the problem (wily, and x) is that you always have a dependency on a versioned python3 interpreter
[16:05] <doko> because the shebang is the versioned interpreter name
[16:12] <jamespage> doko, please can you raise a bug - I'll discuss face-to-face with zigo next week in tokyo
[16:12] <jamespage> I'm sure we can sort out a better way forward
[16:16] <doko> jamespage, https://bugs.launchpad.net/ubuntu/+source/python-rtslib-fb/+bug/1509422
[16:16] <ubottu> Launchpad bug 1509422 in python-rtslib-fb (Ubuntu) "package uses versioned shebangs" [Undecided,New]
[16:37] <jamespage> doko, so its the looping over py versions for install causing the problem right?
[16:38] <doko> jamespage, yes. pybuild has support to call the default version last as unversioned interp
[16:39] <mitya57> doko, yes we can drop that coverage delta
[16:42] <doko> mitya57, now if that package would build ...
[16:46] <mitya57> doko, it's pybuild automatic tests running thing that broke it. I think you can export PYBUILD_DISABLE=test and file a Debian bug for Ben so that he can look at that
[16:46] <barry> doko: can you take a look at debian bug #802792?  i'd really like to get that patch into python-setuptools so i can start to unwind all the crappy broken workarounds in packages that are blocking other people
[16:46] <ubottu> Debian bug 802792 in python-setuptools "Prune Debian artifact directories from SOURCES.txt" [Normal,Open] http://bugs.debian.org/802792
[16:48] <mitya57> doko, let me check if it FTBFS in Debian too, if it does, I'll file a RC bug myself
[16:49] <doko> barry, I'm afk in 10min, will look at it tomorrow
[16:50] <barry> doko: ok thanks.
=== infinity changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stokachu
[17:59] <slangasek> pitti: the hardware is in scalingstack, you should be able to cut over to doing the tests on there
[17:59] <slangasek> pitti: ... which is an answer you already got, ok :)
[18:22] <smoser> slangasek, or pitti
[18:22] <smoser> either of you,.
[18:29] <mitya57> Archive open \o/
[18:29]  * mitya57 starts breaking it
=== fginther` is now known as fginther
[19:34] <stokachu> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== adrian is now known as alvesadrian
[20:54] <zigo> doko: What exactly is the problem with the type of debian/rules I'm using?
[20:54] <zigo> doko: It's been the way to do it for years, in order to support multiple versions of Python.
[20:54] <zigo> doko: Like, when there was Python 2.6 and 2.7.
[20:55] <zigo> doko: I'm always for improvements, so I'd be happy to read your advices, though I don't really want to use Pybuild.
[20:55] <tumbleweed> and there are now much better ways?
[20:55] <bdrung> is xenial open for upload?
[20:56] <doko> zigo, you are hard-coding a specific python3.X version, generating a python3.y dependency. see LP: #1509422
[20:56] <ubottu> Launchpad bug 1509422 in python-rtslib-fb (Ubuntu) "package uses versioned shebangs" [Undecided,New] https://launchpad.net/bugs/1509422
[20:56] <doko> zigo people are then touch your packages twice for a transition, compared to not touching them using a python3 shebang
[20:56] <zigo> doko: I still don't understand where the hardcoding is.
[20:57] <doko> zigo, do you see that you end up with a python3.x dependency?
[20:57] <zigo> doko: Isn't dh_python3 supposed to fix the shebang?
[20:58] <doko> zigo, see dh_python3(1)
[20:59] <zigo> doko: I'm not even overriding dh_python3, so if there's an issue, it really is with dh_python3 itself, no?
[21:00] <zigo> doko: I've just had a look in rtslib-fb, and indeed, I see a python3.5 shebang...
[21:01] <doko> dh_python3 doesn't override the shebang by default
[21:01] <zigo> doko: Don't you think it should?
[21:01] <zigo> doko: If the issue is to ask dh_python3 to do so, then I can do that...
[21:02] <zigo> doko: That's "only" a few dozen of uploads, I'm not scared of that, if that helps you to do the transition.
[21:02] <zigo> doko: Do I understand well that the issue is "only" the shebang?
[21:02] <tumbleweed> zigo: why not use pybuild? It calls the default python3 as python3, not python3.X, so the shebang would be right in the first place
[21:03] <tumbleweed> (I assume, that's what the dh python_distutils plugin always did)
[21:03] <doko> zigo: this "only" costs people time.
[21:04] <zigo> tumbleweed: Looking at the rtslib-fb package which we took as example, I'm simply using "dh $@ --buildsystem=python_distutils --with python2,python3", so nothing fancy.
[21:04] <tumbleweed> zigo: you're overriding the build rules with your own loops
[21:04] <zigo> doko: It is my time that we're talking about here, so the concern is only for me.
[21:04] <doko> zigo: wrong, this time for people handling transitions, both in Debian and Ubuntu
[21:04] <zigo> Sorry to hear that... :/
[21:05] <doko> have the correct shebang, and I wouldn't even notice your build system ;-P
[21:06] <zigo> doko: Is there a way to list all of the "broken" packages that I have, IE, all what's in the OpenStack PKG group with stuff in /usr/bin?
[21:06] <doko> bdrung, don't break it ;p
[21:06] <tumbleweed> also, zigo, (unrelated) if you pass --buildsystem=python_distutils to dh, you don't have to pass it to every dh_command in every override. It sets an environment variable to do that
[21:06] <zigo> tumbleweed: Ah, thanks for the tip.
[21:06] <doko> zigo: every binary package with a python2.Y or python3.Y dependency should be considered broken. there might be some exceptions
[21:07] <doko> for python2.7 nobody cares anymore
[21:07] <tumbleweed> hrm, we should probably have lintian rules for this
[21:07] <bdrung> doko, i break enough stuff at my day job. so no need to break xenial at night ;)
[21:07] <zigo> doko: I had a look in rtslib-fb, and the dependency really is python3:any, so I don't think there's an issue with dependency.
[21:07] <tumbleweed> zigo: that's not the only dependency
[21:08] <zigo> tumbleweed: What do you mean?
[21:08] <tumbleweed> zigo: Depends: python-rtslib-fb, python3:any (>= 3.3.2-2~), python3.4
[21:08] <doko> zigo: in sid:
[21:08] <doko> $ apt-cache show python3-rtslib-fb|grep Depends
[21:08] <doko> Depends: python-rtslib-fb, python3-six, python3.5, python3:any (>= 3.3.2-2~)
[21:08] <zigo> Ah, right... :/
[21:09] <doko> so you even pull in 3.5, even if it is not yet the default
[21:09] <zigo> Well, that's because of the shebang, no?
[21:09] <doko> yes
[21:09] <zigo> Ok.
[21:09] <zigo> I'll have a look asap.
[21:09] <zigo> My little girl is crying, I have to take care of her now... :(
[21:11] <doko> zigo, have a look with jamespage  next week ...
[21:11] <tumbleweed> zigo: grep-aptavail -F Maintainer openstack | grep-dctrl -s Package,Depends -F Depends -r 'python[23]\.[0-9]'
[21:13] <doko> tumbleweed, care to do that for all modules and following-up to debian-python?
[21:13] <zigo> doko: The simple fix is to add an override of dh_python3 within openstack-pkg-tools and do a rebuild, but I'd need to list all of my packages that have py3 support and something in /usr/bin...
[21:14] <tumbleweed> zigo: run that command
[21:14] <doko> in debian, not ubuntu
[21:14] <tumbleweed> doko: sure
[21:14] <tumbleweed> you may want to change it to -s Source, and pipe through a sort -u
[21:23] <zigo> tumbleweed: doko: That's 39 packages to fix. I'll do it.
[21:23] <doko> zigo, please do it right, using pybuild. maybe do one package first, and get it reviewed?
[21:24] <zigo> doko: Thanks, but I don't want to use Pybuild unless there's a good enough documentation.
[21:24] <doko> well, docs are an issue
[21:24] <zigo> I've read the wiki, and I can't override things which I wanted.
[21:24] <zigo> Pybuild is fine for simple cases where you don't need to understand it.
[21:27] <doko> well, python-rtslib-fb is a simple package
[21:27] <tumbleweed> zigo: examples of things you need to override?
[21:29] <zigo> tumbleweed: auto_clean, auto_build, dh_sphinxdoc, dh_installman, dh_auto_install, dh_install, dh_auto_test, dh_fixperms, dh_python{2,3} are things I often have to override.
[21:29] <tumbleweed> zigo: I'm asking why more than what
[21:29] <tumbleweed> I mean, an example of where you can't figure out howto get pybulid to do what you need
[21:31] <zigo> tumbleweed: dh_auto_test to run unit tests in a custom way, dh_sphinxdoc to install the doc directly in the folder I need to in a reproducible way, etc.
[21:31] <zigo> tumbleweed: The issue isn't for *me*, everyone who may touch the packages I work on should be able to understand without reading Pybuild internal code.
[21:31] <zigo> As of right now, there's no good enough docs in pybuild to make that possible.
[21:32] <zigo> I've tried.
[21:32] <zigo> Failed... :(
[21:32] <zigo> Then gave up.
[21:32] <tumbleweed> I will admit that I've had to read pybulid source to do some things
[21:32] <tumbleweed> but when you've done them, the result is fairly understandable to others
[21:32] <zigo> tumbleweed: It's a CDBS-like approach.
=== shadeslayer_ is now known as shadeslayer
[21:33] <zigo> ie: black-magic commands which aren't auto-documented.
[21:33] <zigo> I'm not saying I have a better approach to advise...
[21:34] <zigo> (I don't...)
[21:34] <tumbleweed> I don't find it that bad
[21:34] <tumbleweed> really, come to #debian-python if you have problems with pybuild and people will help. esp piotr
[21:34] <zigo> Not what I said! :)
[21:34] <doko> only if you are on the common path, but it's underdocumented for common cases
[21:35] <doko> and it's missing a test suite
[21:35] <zigo> tumbleweed: Well, that's the other issue with Pybuild. I have to ask Piotr, and from the start, as you know, my relation with him hasn't been best.
[21:36] <zigo> Also, just saying "ask the only and single author" is neither satisfying or scalable.
[21:36] <tumbleweed> with all its problems, it's still way nicer than having those loops everywhere
[21:36] <tumbleweed> he's not the only one who uses it, we're all gaining experience
[21:36] <zigo> tumbleweed: I've been thinking about pushing some of that within openstack-pkg-tools itself.
[21:36] <zigo> It wouldn't be hard to do so.
[21:36] <tumbleweed> but it makes your packages even less like everything else in the archive
[21:36] <zigo> What made me not do it is because I don't want to hide what the package does.
[21:37] <zigo> tumbleweed: I don't agree with this.
[21:37] <zigo> tumbleweed: The loops which I've been using are there because I saw it in many other packages.
[21:37] <tumbleweed> right, and those are being replaced by pybuild
[21:38] <zigo> tumbleweed: I'm convince that what you've seen in my packages, you'll see it elsewhere too...
[21:38] <doko> then why do you use the dh sequencer at all? it has hidden anything how to call the upstream build system, for a long time
[21:38] <tumbleweed> when I said "it makes your packages even less like everything else in the archive" I was replying to "pushing some of that within openstack-pkg-tools"
[21:39] <zigo> doko: It took me a *very* long time to switch to the sequencer, and the only reason I use it is to make it more "new standard" that others like... :P
[21:39]  * tumbleweed sees a pattern here :)
[21:39] <zigo> tumbleweed: I'm ok to make the effort to switch to Pybuild at some point.
[21:40] <zigo> Though I don't think pybuild has issues that must be fixed first, the first of which is documentation.
[21:40] <zigo> sorry, badly phrased ... :)
[21:40] <zigo> redoing it ...
[21:41] <zigo> When there's going to be a good enough doc for pybuild, I'll reconsider.
[21:41] <zigo> Otherwise, I'm too scared to use something which I don't understand fully.
[21:42] <tumbleweed> sure
[21:42] <tumbleweed> and yes, it is rather CDBS-like. But I don't know how one avoids that when doing what it does
[21:43] <zigo> tumbleweed: Use the dh approach ! :)
[21:43] <zigo> tumbleweed: ie: small shell scripts in /usr/bin doing what's needed.
[21:44] <tumbleweed> it's a different type of problem, though
[21:44] <tumbleweed> it's doing the same thing multiple times, in different environments
[21:57] <zigo> doko: Is having "python3" in depends ok? Or it *must* be python3:any?
[21:57] <zigo> (only)
[21:58] <zigo> If i do:
[21:58] <zigo> override_dh_python3:
[21:58] <zigo> 	dh_python3 --shebang=/usr/bin/python3
[21:58] <zigo> Then I get: Depends: python3, python3:any (>= 3.3.....)
[21:58] <zigo> tumbleweed: Is this correct?
[21:59] <tumbleweed> yeah, that sounds correct
[21:59] <tumbleweed> I mean, it could simplify that to python3:any
[22:00] <tumbleweed> but that's presumably dh_python3's problem
[22:00] <doko> zigo: the qualifier doesn't matter. but if you want to build (and test) using all python3 versions, you have to b-d on python3-all
[22:00] <zigo> doko: All of my packages already b-d on python3-all.
[22:01] <zigo> That's well understood ... :P
[22:01] <doko> well, your question was about: Is having "python3" in depends ok? Or it *must* be python3:any?
[22:02] <zigo> doko: The *resulting* .deb has python3, python3:any (>= 3.3.....)
[22:02] <zigo> doko: "Is this fine? or must it be only python3:any (>= 3.3....)?" was my question, o
[22:03] <doko> zigo, this looks fine
[22:03] <zigo> Ok, I was just checking... :P
[22:03] <zigo> Thanks.
=== wolsen_ is now known as wolsen
=== salem_ is now known as _salem
[22:40] <zigo> doko: tumbleweed: I've done nearly half of the packages, I'll be done in 30 minutes for the other half...