| pitti | Good morning | 04:29 |
|---|---|---|
| === kitterma is now known as ScottK | ||
| 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:42 |
| pitti | doko: "Target POWER8 on ppc64el" -> that? | 05:45 |
| pitti | doko: I suppose wolfe is not that yet | 05:45 |
| 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? | 05:46 |
| dholbach | good morning | 06:28 |
| mgedmin | how come some -dbgsym packages are available only for i386? (e.g. gjs-dbgsym) | 06:43 |
| 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:45 |
| mgedmin | my apt does this: http://paste.ubuntu.com/12900653/ | 06:46 |
| seb128 | mgedmin, dpkg -l | grep gjs ? | 06:47 |
| mgedmin | http://paste.ubuntu.com/12900658/ | 06:47 |
| mgedmin | (amd64) | 06:47 |
| seb128 | hum, your issue seems more a multiarch one | 06:48 |
| seb128 | sudo apt-get install gjs-dbgsym:amd64 ? | 06:48 |
| 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:50 |
| 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:51 |
| 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:56 |
| 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/ | 06:57 |
| seb128 | mgedmin, I see, well ddebs with apport usually work fine, there is just an index/server issue there | 07:00 |
| === cpaelzer_ is now known as cpaelzer | ||
| === davidcalle_ is now known as davidcalle | ||
| doko | pitti, slangasek: better stop then ... until you get hardware. | 09:14 |
| === sletta_ is now known as sletta | ||
| 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:34 |
| dholbach | Mirv, how can I help? | 09:36 |
| seb128 | Mirv, it's on -announce | 09:40 |
| seb128 | Riddell, good luck for whatever you do next, I hope you have more fun that you had recently with all those discussions! | 09:42 |
| Riddell | thanks seb128 :) | 09:43 |
| cjwatson | pitti: I think you should be able to get access to bos01 scalingstack for autopkgtests. | 09:50 |
| Mirv | dholbach: oh, announce as mentioned, no problem :) | 09:56 |
| === oSoMoN_ is now known as oSoMoN | ||
| pitti | cjwatson: thanks; I pinged the RT again | 10:03 |
| === 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 | ||
| 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] | 11:06 |
| === hikiko|ln is now known as hikiko | ||
| 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:24 |
| pitti | sil2100: ack, tahnks | 11:25 |
| doko | pitti, apport autopkg test failures | 12:03 |
| === popey_ is now known as popey | ||
| pitti | doko: yep, known; fixed in trunk already | 12:14 |
| pitti | doko: for the current version the hint is still in place | 12:14 |
| === gonzzor_ is now known as gonzzor | ||
| === _salem is now known as salem_ | ||
| pitti | hm, quite some regressions due to uninstallability | 12:24 |
| pitti | doko, infinity ^ I'll retry them once the queue settled down | 12:25 |
| doko | pitti, need to build some python3.5 extensions for that. waiting for gcc-5 to be published | 12:26 |
| 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:28 |
| 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:29 |
| doko | xnox, which branch? | 12:30 |
| 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:33 | |
| doko | ta | 12:34 |
| xnox | doko: omg, that thing is a python2 script that connects to barry's spreadsheet.... | 12:34 |
| xnox | on google docs. I bet it's all wrong. | 12:35 |
| 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:36 |
| 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 | 12:37 |
| 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:16 |
| 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:17 |
| mapreri | cjwatson: can you unblacklist scribus from syncing now that wily is out and xenial is on its way? :) | 13:28 |
| 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:29 |
| 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:30 |
| mitya57 | Ok, I can take a look, not right now though | 13:31 |
| stokachu | @pilot in | 13:31 |
| === 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 | ||
| Odd_Bloke | wgrant: cjwatson: infinity: Which kernel package should I be using for powerpc? linux-image-powerpc-smp? | 13:47 |
| 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:52 |
| 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:53 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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) | 13:59 |
| seb128 | pitti, great, thanks | 14:00 |
| 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:04 |
| 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:05 |
| 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:06 |
| doko | without a dep on python3.4 | 14:07 |
| mitya57 | doko, you did rebuild pyqt5, right? | 14:07 |
| doko | mitya57, not yet | 14:07 |
| doko | mitya57, but then it will still have a python3.5 shebang without a dep on python3.5 | 14:08 |
| 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:13 |
| 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:14 | |
| * infinity adds xenial to rmadison. | 14:17 | |
| 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:33 |
| mitya57 | doko, thanks | 14:34 |
| mitya57 | Though I will place it in install-arch target | 14:35 |
| doko | sure | 14:36 |
| mitya57 | committed | 14:38 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| doko | barry, are you looking at python-coverage, or should I? | 14:56 |
| 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 | 14:58 |
| 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 | 15:00 |
| === gusnan_ is now known as gusnan | ||
| 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:18 |
| bfiller | doko: thanks for your help on that one, it's currently blocking one of our dual landings | 15:23 |
| 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:31 |
| seb128 | doko, unsure, but why shouldn't we follow Debian? I don't know exactly why robert reverted it previous cycle | 15:32 |
| 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:33 |
| doko | seb128, debian will have a compiler which defaults to c++14 in the end, xenial won't have this | 15:34 |
| seb128 | k, your call, I don't understand enough of what is involved to have an opinion | 15:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| seb128 | yeah, let's wait for that then | 15:39 |
| seb128 | no hurry in getting the new version | 15:39 |
| 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:50 |
| 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:51 |
| seb128 | let me check with Bjoern | 15:52 |
| 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 | 15:57 |
| 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:04 |
| 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:05 |
| 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:12 |
| 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:16 |
| jamespage | doko, so its the looping over py versions for install causing the problem right? | 16:37 |
| doko | jamespage, yes. pybuild has support to call the default version last as unversioned interp | 16:38 |
| mitya57 | doko, yes we can drop that coverage delta | 16:39 |
| doko | mitya57, now if that package would build ... | 16:42 |
| 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:46 |
| mitya57 | doko, let me check if it FTBFS in Debian too, if it does, I'll file a RC bug myself | 16:48 |
| doko | barry, I'm afk in 10min, will look at it tomorrow | 16:49 |
| barry | doko: ok thanks. | 16:50 |
| === 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 | ||
| 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 :) | 17:59 |
| smoser | slangasek, or pitti | 18:22 |
| smoser | either of you,. | 18:22 |
| mitya57 | Archive open \o/ | 18:29 |
| * mitya57 starts breaking it | 18:29 | |
| === fginther` is now known as fginther | ||
| stokachu | @pilot out | 19:34 |
| === 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 | ||
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| doko | zigo, see dh_python3(1) | 20:58 |
| zigo | doko: I'm not even overriding dh_python3, so if there's an issue, it really is with dh_python3 itself, no? | 20:59 |
| zigo | doko: I've just had a look in rtslib-fb, and indeed, I see a python3.5 shebang... | 21:00 |
| 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:01 |
| 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:02 |
| tumbleweed | (I assume, that's what the dh python_distutils plugin always did) | 21:03 |
| doko | zigo: this "only" costs people time. | 21:03 |
| 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:04 |
| doko | have the correct shebang, and I wouldn't even notice your build system ;-P | 21:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:11 |
| 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:13 |
| 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:14 |
| 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:23 |
| 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:24 |
| doko | well, python-rtslib-fb is a simple package | 21:27 |
| tumbleweed | zigo: examples of things you need to override? | 21:27 |
| 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:29 |
| 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:31 |
| 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. | 21:32 |
| === shadeslayer_ is now known as shadeslayer | ||
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| zigo | tumbleweed: Use the dh approach ! :) | 21:43 |
| zigo | tumbleweed: ie: small shell scripts in /usr/bin doing what's needed. | 21:43 |
| tumbleweed | it's a different type of problem, though | 21:44 |
| tumbleweed | it's doing the same thing multiple times, in different environments | 21:44 |
| zigo | doko: Is having "python3" in depends ok? Or it *must* be python3:any? | 21:57 |
| zigo | (only) | 21:57 |
| 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:58 |
| tumbleweed | yeah, that sounds correct | 21:59 |
| tumbleweed | I mean, it could simplify that to python3:any | 21:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| doko | zigo, this looks fine | 22:03 |
| zigo | Ok, I was just checking... :P | 22:03 |
| zigo | Thanks. | 22:03 |
| === wolsen_ is now known as wolsen | ||
| === salem_ is now known as _salem | ||
| zigo | doko: tumbleweed: I've done nearly half of the packages, I'll be done in 30 minutes for the other half... | 22:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!