=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
=== Ursinha-afk is now known as Ursinha
acincatbus1: ping04:43
pittiGood morning06:21
=== work_alkisg is now known as alkisg
=== iahmad is now known as iahmad|afk
dholbachgood morning08:48
=== coalwate1 is now known as coalwater
=== freeflying is now known as freeflying_away
=== iahmad|afk is now known as iahmad
pittilamont: just found yet another wipefs bug in our ancient util-linux.. any chance we'll get a newer version at some point?09:27
pittilamont: I guess nobody else is able to touch/update that package with the single big debian.diff.gz :/09:29
=== doko_ is now known as doko
pittislangasek: btw, I set you as reviewer for https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming, is that ok?09:40
pittislangasek: s/reviewer/approver/09:40
xnoxpitti: there is a git repo for util-linux.09:42
xnoxbut yeah, new util-linux would be nice. At least for /etc/fstab.d/ which would be very nice.09:43
=== freeflying_away is now known as freeflying
pittiis that just me, or does software-center hang/crash at startup for other people, too?09:53
pittisome DBInvalidArgError in /usr/share/software-center/softwarecenter/backend/reviews/__init__.py09:53
xnoxpitti: did my db transition gone wrong?09:54
pittisoftwarecenter.backend.reviews - WARNING - error creating bsddb: '(22, 'Das Argument ist ung\xc3\xbcltig -- BDB0054 illegal flag combination specified to DB_ENV->open')' (corrupted?)09:54
pitticould very well be a corrupted local BDB database09:54
LaneyI see that, but it doesn't crash it for me09:54
xnoxpitti: everything switched to new db simultaniously. (lenses & software-centre). But does the db's in use actually need upgrade? (or removal on upgrade from old db)09:55
pittiand eventually it crashes with  a BadDrawable X window error09:55
pittixnox: usually not; so far, every BDB update only changed the on-disk format for transactions09:55
xnox(there was a window when db versions of software centre and the lense were different)09:55
pittibut almost all software only uses in-memory transactions09:55
Laneycrash> probably https://bugs.webkit.org/show_bug.cgi?id=12348009:55
ubottubugs.webkit.org bug 123480 in WebKit Gtk "ubuntu software center hits _XReadEvents() error" [Normal,Unconfirmed]09:55
pittiLaney: ah, so it runs, but doesn't crash with the drawable?09:55
* ogra_ has it too 09:56
Laneyit's pretty common, but I never managed to get it09:56
dholbachseb128, didrocks, lool: http://developer.ubuntu.com/packaging/ (check what's new on there :-))09:56
xnoxsoftware centre freezes here up into a dark window09:56
pittixnox, Laney: I get the freeze in a guest session too, so not related to DB migration09:57
Laneyno, it's old09:57
pittithe "invalid db->open argument' still looks scary, though09:57
ogra_its webkit09:57
pittiogra_: ok, thanks09:58
Laneymaybe someone who gets it could ping on that bug09:58
ogra_bug 121188709:59
ubottubug 1211887 in software-center (Ubuntu) "software-center crashed with signal 5 in _XReadEvents()" [High,Confirmed] https://launchpad.net/bugs/121188709:59
ogra_looks like 47 people did already :)10:00
seb128pitti, s-c and webkit don't like each others :/10:00
seb128but not easy to debug10:00
seb128and nobody upstream replied to the report yet10:00
pitti/usr/share/software-center/softwarecenter/backend/ubuntusso.py verify_token_sync() looks relatively isolated10:01
seb128dholbach, I never looked at that yet, not sure what is new ... it's not in french though10:01
dholbachseb128, there should be french on there!10:01
seb128dholbach, lol, is there any other try at getting translators to do their job? ;-)10:01
dholbachseb128, the French translation is done 100% now10:02
seb128dholbach, \o/10:02
alkisgIn ltsp we're using init=/sbin/init-ltsp, and that script supports an "ltsp.break" kernel parameter to spawn a shell directly at init. This used to work fine until 12.04, but now plymouth doesn't open vt1 anymore, even without "quiet splash vt.handoff=7"?10:07
alkisgThe end result is that I can run commands and see their output in the screen, but I can't see the keys that I type. If I run openvt there, it's ok, so I assume it's a vt issue... Should I file a bug report against plymouth?10:07
xnoxbreak=bottom, would get one a shell at the end of initramfs, or booting into friendly recovery would get one shell at init as well (friendly recovery subverts normal boot procedure)10:10
xnoxwhat does init-ltsp do? and why use that, instead of changing startup event that upstart emits to start the boot procedure? (same trick that friendly recovery does)10:11
didrocksseb128: completely english for me though! ;)10:15
seb128didrocks, same here, tell dholbach!10:15
didrocksseb128: even not German for you?10:15
* didrocks runs10:16
* seb128 slaps didrocks10:16
dholbachseb128, translations are linked from there, you hippies!10:16
alkisgxnox: it's about the same as init=/bin/bash, although plymouth does allocate a vt in that case10:16
seb128dholbach, where?10:17
* seb128 can't see it10:17
dholbachseb128, http://developer.ubuntu.com/packaging/ - search for "French"?10:17
alkisgxnox: In previous versions, plymouth special-cased anything that started from /sbin/init*, maybe they changed their special casing to only include /bin/bash?10:17
seb128dholbach, no match10:18
dholbachseb128, argh10:18
alkisgxnox: we want early breaks to troubleshoot stuff before upstart or other service have a chance to run, but after the initramfs10:18
dholbachseb128, sorry, something's wrong - I could just see it, because I was the admin of the page in WP - nevermind10:18
seb128dholbach, ;-)10:18
seb128dholbach, you hippie!10:18
dholbachdidrocks, seb128, http://developer.ubuntu.com/packaging/fr/html/10:18
seb128dholbach, c'est mieux10:18
xnoxalkisg: well, i'd recommend for you to try friendly recovery and if anything is missing that "init-ltsp" does. That's exactly what it does, e.g. nothing is started and a menu pops which lets user to manual enable networking, mount rootfs RW, drop into root shell, reboot, shutdown, continue normal boot.10:19
didrocksdholbach: ah, le packaging guide est *enfin* fixé ;) (just have to push it to default url now :p)10:19
xnoxalkisg: that's what ubuntu boot into, if previous boot fails.10:19
dholbachdidrocks, yeah, we're going to move it to packaging.ubuntu.com and have rewrite rules - it's a bit of a pain to maintain it together with the wordpress instance10:19
xnoxalkisg: there should be a boot entry marked "... (recovery mode)"10:19
didrocksdholbach: ahah, in fact, I meant put the French page as default of course :)10:20
dholbachdidrocks, haha10:20
alkisgxnox: the frienly recovery can't break inbetween our init-time ltsp scripts... I'm not looking for an alternative, I was just trying to see if anyone already knows about that plymouth bug...10:21
xnoxalkisg: =/ all i can suggest is to integrate into friendly recovery, as that does correctly bring up vt when needed etc. and it is guaranteed to be kept working with any changes that happen. not sure what you mean by "that plymouth bug" once plymouth starts it own all vts, and doesn't let one easily switch. one programatically show hide/stop plymouth.10:24
alkisgxnox: plymouth does support init=/bin/bash, i.e. it allows bash to have a vt10:25
alkisgBut I think that if I rename it, it doesn't10:26
alkisgIt did in 12.04, it doesn't in 14.0410:26
xnoxalkisg: not sure what you mean..... if there is no plymouth in the initramfs, than plymouth is started by init & with init=/bin/bash it will not be started.10:26
alkisgxnox: plymouth is in the initramfs though, isn't it?10:27
xnoxalkisg: if there is plymouth in the initramfs, and it was started from there, it will need to be stopped someway.10:27
alkisgPlymouth has code that reads the kernel command line for that specific case... at least it did when I looked in 12.0410:28
xnoxalkisg: not always. at the moment we pull in plymouth in the initramfs via hooks, e.g. if cryptsetup is installed & rootfs is LUKS encrypted.10:28
alkisgAnd now that part of its code no longer works...10:28
alkisgxnox: ah, that's good to know. Until 12.04 stgraber pulled plymouth in the initramfs from the ltsp package10:28
alkisg(it's still in effect in 14.04),10:28
alkisg...so if we remove it, it will solve the vt problem...10:29
xnoxi don't think that's what you want.10:29
xnoxcheck the code and file a bug.10:29
alkisgYou're right about that. Thanks, /me apt-get source's plymouth...10:30
xnoxbzr branch lp:ubuntu/plymouth might be better.10:30
tseliotpitti: I know that packages in main cannot depend on packages in universe but they can still recommend them, can't they?10:31
pittitseliot: no, only suggests10:31
tseliotpitti: ok, I guess I have a problem then, as the new release of nvidia prime (main) will need bbswitch (universe)10:32
tseliotpitti: is a MIR the only solution?10:33
xnoxtseliot: recommends are also considered for main inclusion. suggests are not.10:33
pittitseliot: if the kernel team and/or you is fine with maintaining that additional kernel driver, sure10:33
xnox(build-depends, depends, recommends) are all pulled into main.10:33
pittitseliot: i. e. the question is whether we want to support nvidia prime10:34
tseliotpitti: oh, I can definitely maintain it10:34
alkisgxnox: yeah, strstr (state->kernel_command_line, " init=") != NULL; ==> that was removed... /me looks deeper before filing a bug report, thanks for your assistance10:34
tseliotxnox: right10:34
* xnox 's irc is lagging today.10:34
tseliotpitti: yes, I think we (oem) do10:35
alkisgxnox: at 12.04 they were checking if it started with init, now this patch: ./.pc/tty1-after-boot.patch/src/main.c checks if it ends with "sh" :(10:36
alkisgSo we'll need to rename our custom init to "init-ltsp-sh" :(10:36
alkisgstgraber: ^10:37
xnoxalkisg: alternatively your script can ping plymouth to check if it is up and stop it yourself.10:37
alkisgxnox: do you have those commands handy?10:37
alkisg(good idea, thank you!)10:37
xnoxalkisg: check plymouth --help; and try them out. Also see testing at https://wiki.ubuntu.com/Plymouth10:38
alkisgThanks a lot10:38
alkisgOuch, plymouth quit at that point produces some more udev messages and then hangs the system. /me tries renaming init-ltsp...10:41
alkisgHaha, "init=/sbin/init-sh init=/sbin/init-ltsp" did the trick. The first one tricked plymouth, the second one was the actual init.10:48
* alkisg checks if the plymouth patch is ubuntu specific, to request a change there...10:49
=== sraue_ is now known as sraue
=== _salem is now known as salem_
=== MacSlow is now known as MacSlow|lunch
=== alkisg is now known as work_alkisg
pittidoko, barry: FYI, autopkgtest notifications have been broken since the lab move, so playing email relay: python{2.7,3.3,3.4} autopkgtests currently fail13:29
dokopitti, please ignore those for 3.413:30
pittidoko: ack13:30
pittidoko: (there are some str vs. bytes confusion)13:30
dokopitti, url for the others?13:30
pittilatest is https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python3.3/9/ARCH=i386,label=adt/13:31
pittidoko: that seems to have similar str vs bytes issues ("TypeError: gdbm key must be bytes, not str", and others)13:31
=== MacSlow|lunch is now known as MacSlow
pittidoko: ah, actually no; that's the only test on 3.3 that fails13:32
dokopitti, so for 2.7, it's the uuid test again, but this succeeds when it is repeated, and it did succeed on the buildd ...13:35
dokoon i38613:35
zygahey, are recommends installed during clean package builds?13:51
zygaI guess not, correct?13:51
zygagreat :)13:52
pittidoko: is that something which might need lots of entropy? i. e. could the test perhaps run out of /dev/random bits?13:53
* pitti runs it locally13:53
zygapitti: shove a random generator hw dongle into the test host to solve the problem :)13:55
pittiwell, installing haveged might already help13:55
pittizyga: well, it's a VM -- you need virtual hw :)14:00
zygapitti: you can plug the usb dongle into the vm I guees, or shove randomness somehow from the hos14:01
=== Sweetsha1k is now known as Sweetshark
dokopitti, the dbm test failures in 3.3 seem to be introduced when switch to db5.3.  barry, xnox, do you want to have a look?14:13
smoseranyone able to ack (or review and reject) plymouth-disabler (https://launchpad.net/ubuntu/trusty/+queue?queue_state=0&queue_text=)14:18
xnoxsmoser: is it really a 2.8KiB package? can we not instead merge it / build it from plymouth source package?14:19
smoserxnox, slangasek was fairly strongly opposed to that.14:20
xnoxoh really =) interesting.14:20
ubottuUbuntu bug 1235231 in plymouth (Ubuntu) "plymouth loses output to /dev/console (such as ci-info: messages)" [High,Confirmed]14:20
smoser(although i don't have his response to that specifically in that bug)14:20
xnoxsmoser: sounds like something that make sense to ship in ubuntu's cloud-init src package & generate a binary plymouth-disabler. It's really quite a big overhead to introduce a new src package just for this.14:22
smoserit has nothing to do with cloud-init14:22
smoserplymouth has a dataloss bug14:22
smoserthis is completely unrelated to cloud-init14:22
xnox(maybe not cloud-init upstream, not sure about cloud-init debian pkg)14:22
xnoxsure I understand there.14:23
xnoxsmoser: people rarely notice which src package a particular binary package is build from =)14:23
smosermy primary objection to cloud-init is that it would further cloud-init from debian. and eventually i'd like to have that be a straight sync.  currently cloud-init builds another unrelated package (grub-legacy-ec2) that has been split to another separate package in debian.14:24
smoseri'd like to reduce delta not increase it.14:25
xnoxok. try pinging slangasek about it again (although he is away on holiday at the moment). I don't see him subscribed to the bug.14:25
rbasakDisabling plymouth is awkward. It doesn't matter in the cloud-init case, but for example lightdm starts on plymouth-ready.14:30
rbasakI had to create a dummy upstart job for that.14:30
smoseryou had to do that where?14:30
rbasakIt seems to me that disabling plymouth is quite heavily tied to plymouth's packaging.14:31
rbasaksmoser: on my Chromebook, for https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/108274214:31
ubottuUbuntu bug 1082742 in plymouth (Ubuntu) "plymouthd: ply-terminal.c: 611 ply_terminal_open: Assertion `terminal != ((void *)0)' failed." [Undecided,Confirmed]14:31
smosermaybe we need to just fix plymouth.14:31
zygashould documentation packages be called -doc or -docs?14:32
zygaI see both used heavly in the archive14:32
smoserbut fixing plymouth properly would take me quite a while.14:32
FunnyLookinHatI know this might not be the right place to ask - so let me know if I'm out of line here... any of you know any details about Software Center going away after 14.04?  Saw that referenced in this spreadsheet : https://docs.google.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE#gid=114:33
FunnyLookinHatI presume click packages are going to be a replacement of sorts/14:34
mrmcq2uwhat do you guys think of this?14:35
xnoxdoko: not sure where the change is comming from, but as per http://hg.python.org/cpython/rev/dfeda0d3d636/ string dbm keys & values are converted into bytes keys & values, thus upon doing g['a'] = 'b', g.keys() correctly returns [b'a']14:37
rbasaksmoser: it might be worth adding a dep8 test to make sure that plymouth-disabler actually disables plymouth. That way, if the plymouth packaging is changed such that the appropriate mechanism needed to disable plymouth changes, then the new plymouth package will block proposed migration unless the disable mechanism is also fixed to match.14:40
=== rickspencer3_ is now known as rickspencer3
rbasakHaving said that, I'm not clear how such a dep8 test might work. It'd need a reboot :-(14:41
xnoxdoko: same assert failure in quantal chroot with python3.2 & python3-gdbm installed. and db5.114:41
dokoxnox, hrm, did only check 3.3.2 in saucy, and didn't see it14:42
xnoxbarry: the testcase looks wrong to me, keys/values are implicitly converted to bytes when working with dbm, yet the unit-tests assert using both bytes & strings keys. Was assertIn suppose to do implicit conversion to bytes as well?14:43
xnoxdoko: hm, strange. unless something in unittests / assertIn / containers changed.14:44
barryxnox: sorry, i need context14:44
dokobarry, https://launchpadlibrarian.net/157438095/buildlog_ubuntu-trusty-amd64.python3.3_3.3.3-2_UPLOADING.txt.gz14:44
barrydoko: hmm.  that's caused by the libdb5.3 change?14:45
xnoxbarry: grep doko/xnox/barry highlights above from :13m past till now.14:45
dokobarry, that's what I was thinking, until xnox pointed out the quantal log14:46
xnoxdoko: well, not quantal log, just me trying it locally in a quantal chroot in an interractive shell.14:48
barryxnox: let me see if i can reproduce locally14:48
dokobarry, please configure -with-dbmliborder=bdb:gdbm14:49
doko-- even14:49
dokoseb128, uploaded libffi to unstable again, please yell when you see the same failures after the sync14:53
xnoxdoko: well on should be able to do import dbm.gnu as dbm, if one wants to explicitly test the gnu backend. (that's what I did)14:53
rbasakjdstrand: are you aware of bug 1242726, please?14:54
ubottubug 1242726 in php5 (Ubuntu) "[MIR] php5-common is missing dependency on php5-json" [High,Triaged] https://launchpad.net/bugs/124272614:54
seb128doko, ok14:54
rbasakjdstrand: it's awaiting your review.14:54
seb128doko, you hope to have it fixed with that version? can't you test before syncing?14:54
dokoxnox, well, the test iterates dbm._names and fails for the ndbm case, not the gnu one14:54
dokoseb128, how?14:55
seb128doko, try building one of the indicators which was failing on ppc?14:55
dokoseb128, where?14:55
dokosure, I can do that in a ppa14:55
xnoxdoko: oh, did i use the wrong backend ?! let me try again.14:56
seb128doko, dunno where, do we have any ppa which includes ppc builders?14:57
dokoI'll do in one14:57
zygabarry: is dh_sphinxdoc expected to work for python3-only projects?15:01
barryzyga: i don't know that it doesn't, but i can't say if i've explicitly tried it.  why, have you found a failure?15:01
zygabarry: I have a relatively simple python3 libary+program and dh_sphinxdocs fails to find any documentation and breaks15:02
cjwatsonzyga: it works for click15:02
jdstrandrbasak: I was not aware of that bug15:02
zygabarry: is it the case that I should be building docs myself in som overrides?15:02
xnoxbarry: doko: so on quantal python3.2/db5.1, dbm.ndbm passes when doing a string key on assertIn. But as per http://hg.python.org/cpython/rev/dfeda0d3d636/  (http://bugs.python.org/issue3799), which is strange since .keys() only returns bytes key.15:03
cjwatsonexcept I had to add a no-op override_dh_sphinxdoc-arch rule15:03
zygacjwatson: ok, I'll check out click packaging15:03
jdstrandsarnold: can you take a look at 1242726 when you've got some time?15:03
zygacjwatson: why?15:03
barryzyga: if you find a problem, please file a bug15:03
zygabarry: on sphinx(ubuntu)?15:03
* xnox thought python3-sphinx should be used with python3-only projects.15:03
rbasakjdstrand: OK, thanks for following up.15:03
zygaxnox: I'm using that15:04
cjwatsonzyga: https://launchpad.net/ubuntu/+source/click-package/0.1.1/15:04
zygacjwatson: thanks!15:04
barryzyga: if that's easiest yes.  i'll at least forward it on to debian, which is where it probably needs to be fixed15:04
cjwatson(the package was renamed to click shortly after that; those build failures illustrate the problem though)15:04
barryxnox, doko so, upstream 3.3 hg builds find with --with-dbmliborder=bdb:gdbm15:05
cjwatsonzyga: it's because click-doc is Architecture: all so dh_sphinxdoc -a doesn't have any doc packages to operate on.  I think dh_sphinxdoc should silently do nothing in this case rather than failing, personally15:05
zygacjwatson: I see that you build docs manually, through build override15:08
zygacjwatson: I just copied that aspect, still get http://pastebin.ubuntu.com/6474229/ (essentially, dh_sphinxdoc saying that it cannot find docs)15:09
cjwatsonzyga: that means that the packages that dh_sphinxdoc is operating on do not include any that sphinx docs would be copied into15:11
cjwatsonor, sorry, any that sphinx docs *have been* copied into15:11
cjwatsonyou need to install the docs into the package before running dh_sphinxdoc to mangle them15:12
zygacjwatson: ah15:14
zygacjwatson: so I need to override install to copy docs to debian/tmp/usr/share/docs/ ?15:14
cjwatsonzyga: well, I just did it with debian/click-doc.docs15:18
cjwatsonzyga: but sure, something like that15:18
zygacjwatson: ah, interesting, thanks, I'll try that15:19
dokobarry, does it pass the tests too?15:26
barrydoko: upstream hg 3.3 head does, yes15:28
dokoI don't have any dbm specific patches :-/15:29
barrydoko: i'm building the 3.3 trusty-proposed now in my -amd64 chroot15:29
* xnox ponders if this is somehow affected by locale.15:35
xnox(e.g. UTF-8 vs a non-UTF-8 locale)15:35
zygacjwatson: why did you use py3versions to to loop over multiple python3 interpreters, is that something you do as a habit or is there a genuine need for that (seeing as we always get one interpreter per release)15:38
=== freeflying is now known as freeflying_away
cjwatsonzyga: habit15:44
cjwatsonzyga: plus I see no reason why there *must* only be one python3 interpreter at any given time and I can certainly imagine cases where that might not be so15:44
xnoxisn't it per-policy. we are most-likely to have 3.3 and 3.4 as supported versions in trusty, and packages should byte-compile / compile extenstions / run-unittests across all supported versions.15:45
xnox(if they ship public modules/extensions)15:45
zygaxnox: isn't it the case that for pure-python modules they end up in /usr/lib/python3/dist-packages anyway (not 3.4, 3.4) ?15:49
barryzyga: the pyc's will be version tagged, plus extension modules must be compiled for the specific python abi version.  see peps 3147 and 314915:50
dokozyga, yes, but it would be a good idea to test it with 3.4, and have any extensions built with 3.415:50
zygabarry: ah, good point!15:50
zygaok, thanks15:51
zygaso looping it is15:51
barryzyga: also, i think with pybuild you don't need to explicitly loop15:51
zygaI was about to ask if pybuild does that for you15:51
barryi haven't actually tried it with more than one py2 or py3 enabled yet, but you definitely don't need to loop over all py2 and py3, so i assume it's properly handling all supported versions.  would be good to check ;)15:52
barrydoko: test_site crashes in an sbuild because /sbuild-nonexistent isn't lying ;)15:52
zygabarry: do I need to loop over pythons when doing build_sphinx?15:52
barryzyga: i wouldn't think so, if you have a -doc binary package, it only needs to be built once15:53
* zyga still tries to wrap that around his head, which target to override to get docs to build, which to override to (loop or not) to build everything15:54
xnoxzyga: docs are usually once with python & once with python3, unless API/code is bi-lingual, in that case you can do it once with any default python and ship into separate python-foo-doc package.15:56
=== freeflying_away is now known as freeflying
zygaxnox: so this is python3 only so I guess I need to override_dh_auto_build, run dh_auto_build and then separately python3 setup.py build_sphinx15:57
zygaand that _should_ be enugh15:57
=== adam_g_afk is now known as adam_g
dokobarry, yes, test_site needs fixing. but that's known16:25
barrydoko: cool.  i broke my local build for unrelated reasons, so i'm starting over :/16:25
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
zygabarry, xnox: is there a way to force a script of out python3-foo package and into the foo package?16:45
zyga(without doing everything manually again)16:46
slangaseksmoser: eh, why would these upstart overrides in any way distance the package from Debian?  That would be entirely upstreamable16:55
smoseri dont know. its delta versus it now.16:55
smoseri guess its not significant, but it just really bothers me in general to "fix" a bug in package A from package B.16:56
smoseri pushed some upstream. given rbasak's comments, it seems that disabling plymouth could cause fallout elsewhere.16:57
rbasakslangasek: I'm more bothered that the correct mechanism for disabling plymouth and making everything else on the system continue to work is quite closely tied to plymouth's packaging. It would be nice if plymouth packaging provided a more general mechanism to disable plymouth, rather than other packages having to know about its internals.17:01
=== bfiller is now known as bfiller_afk
xnoxzyga: export PYBUILD_DESTDIR_python3=debian/foo, if you simply want binary package "foo" to have python3 modules & scripts.17:08
xnoxzyga: PYBUILD_NAME=foo, is mostly a shorthand of PYBUILD_DESTDIR_pythonX=debian/pythonX-foo17:08
xnoxfor all python-variants (pypy, python3, python)17:09
xnoxand versions of thereoff.17:09
zygaxnox: I want the modules to be in python3-foo and the main script to be in foo17:10
zygaxnox: it's more complicated as I need one other script to be in the python3-foo package (it's part of the library)17:10
* zyga asked the same question on debian-python@ just now17:11
xnoxah =/ hm... i'd just do "mv" in override_dh_auto_install: after a normal dh_auto_install.17:11
zygaxnox: let me try that :)17:11
xnoxzyga: or maybe better ovverride dh_install instead, as i really dislike having to pass --buildsystem=pybuild when overriding dh_auto_* targets.17:14
zygaoh, I didn't rememeber that17:14
zygaxnox: but I'd have to invoke dh_install there, right?17:15
* zyga tries that17:15
* zyga has built himself a set of nice/tricky (depending on how you look) filesystems/overlays to get zero-setup-time build chroots that are always clean :-)17:17
zygaI need to finish and properly demonstrate that to people17:17
zyga(zero setup time as in, it costs nothing to spin up a clean build chroot)17:17
xnoxwell mk-sbuild creates by default snapshotted sbuild chroots using overlayfs, but can also use lvm/btrfs snapshots, for any debian/ubuntu release & native/qemu-native/cross.17:20
xnoxwhat does your setup improve?17:20
=== salem_ is now known as _salem
zygaxnox: I guess it's a bit http://xkcd.com/927/ but it's consuming different input and providers no setup parameters (tries to do the best thing without any tweaks)17:22
zygaxnox: I'm using overlayfs, tmpfs (remouted ro), upstart jobs to bring a lot of that up, and some bind mounts17:23
zygaxnox: I'm consuming simple meta-data files that tell you how to set up the environment and what to do inside17:23
zygaxnox: one use-case is to build packages cleanly17:23
zygaxnox: but that's not the only use case and the meta-data file can, e.g. run tests on a given environment17:24
zygaxnox: I wanted to run away from 'this is my {sbuild,pbulider,whatever} setup, you need my custom hax0rd config files to make it work'17:25
zygaxnox: and 'you need btfs,lvm' or something similar17:25
zygaxnox: something I could give anyone running 12.04+ and get the same result, fast17:25
xnoxzyga: right, which is what mk-sbuild did. $ mk-sbuild trusty; sbuild -d trusty *.dsc17:25
xnoxwhich is using overlayfs, snpashot by default with no configs required at all.17:25
zygaxnox: right, which is not going to work because I need to run unit tests (which is nothing like building a package here), enable certain ppas (per the meta-data build file) or bind-mount the tree, I want one tool and one input file17:26
* xnox migrated from custom sbuild to stock mk-sbuild without any configs and I'm quite happy.17:26
xnoxzyga: unit tests should always run at package build time.17:27
rbasakWhat I miss from mk-sbuild is the ability to modify the source chroot but only temporarily for what I'm working on - eg. to add a PPA or custom local repo to fulfil build deps.17:27
rbasakRight now I modify the source chroot and have to remember to modify it back.17:27
zygaxnox: unit tests may want to run more often than that, without building the package17:27
rbasakOr modify ~/.sbuildrc with custom setup commands17:27
rbasak(and remember to modify it back)17:27
rbasakStacked overlays would be nice.17:28
zygaxnox: I mean, what I built locally is just an interation of this idea17:28
zygaxnox: but I think all the helper tools suck on input (you either do stuff like debian does and it is okay or you need to customize)17:28
rbasakI was surprised to be unable to find an sbuild option that overrides ~/.sbuildrc with another file.17:28
zygaxnox: oh, also, no perl, python3 api17:28
* rbasak EODs17:28
xnoxrbasak: hm, well the stgraber launchpad-sbuild thing is quite cunning, at chroot snapshot setup it updates it and can twiddle it's sources etc. So you could write a hook into setup.d/* to twiddle sources as you need based on something at runtime (e.g. environemnt variable ADD_APT_REPOSITORY=ppa:foo/bar ?!)17:29
xnoxrbasak: but yeah, it's less than ideal at the moment for that.17:29
zygaxnox: I'm sure what I wrote is half broken sbuild :-)17:29
zygaxnox: but I'm happy with the input file and no perl aspects17:29
rbasakxnox: thanks, I'll look in to that. An env variable sounds like a good idea.17:29
zygaxnox: I'll polish it and show it to people for feedback17:29
=== _salem is now known as salem_
xnoxzyga: for more often unit-tests I just made sure they are run by auto-pkg-tests, such that they are done both on jenkins.ubuntu.com & such that I can execute them locally as well. While cumbersome, at least it's a standard interface for other people to discover and rerun full test-suites as well.17:31
zygaxnox: yeah, my package actually uses that17:32
zygaxnox: but that's not enough really17:32
zygaxnox: we run tests on landing and now we want to build packages on landing too17:32
zygaxnox: we want to run tests without heavy VMs (which will improve the test cycle a lot for what we do)17:32
zygaxnox: and sadly while autopkg tests are great, it's not easy to just run them17:33
zygaxnox: and since we don't have on-merge packages, it's not an option17:33
zygaxnox: + I want people to have a way to run tests on their laptop, running $anything_ubuntu to check all $supported_distros this way, while working offline17:33
zygaxnox: I'm sure there's an overlap but the standard solution is hard to apply to our case17:34
barrydoko, xnox yeah, no problems building trusty-p python3.3 here in a local chroot17:43
* xnox ponders if autopkgtest used missmatched source & binary packages under-test.17:44
barryxnox: i did not run the autopkgtests.  is that where the failure is happening?17:44
xnoxbarry: but i thought it should be allowed to look up string keys, after they were implicitely converted and stored as bytes.17:44
xnoxbarry: correct.17:44
xnox(it's running unit-tests though) and it looks safe enough to execute adt null runner inside chroot.17:45
barryxnox: well, if it works during package build, it should work during autopkgtesting.  maybe there's locale weirdness involved?17:45
xnoxbarry: I did pull-lp-source python3.3; python3.3 ./python3.3-*/Lib/test/test_dbm_ndbm.py fails.17:48
* xnox 's locale is Standard British English (UTF-8)17:50
barryxnox: nice.  my from-source build of 3.3 --with-dbmliborder=bdb:gdbm works fine, but the current trusty 3.3.2+ failures with the same error17:52
cjwatsonThat looks like a bug in the dbm module to me ...17:52
cjwatsonIt does a PyUnicode_Check and then fails anyway17:53
xnoxbarry: the auto-package-test suppose to test the installed binaries. So if the new python3.3 is build with that new option, that most likely means that autopkgtest was triggered too early. I've had that before with e.g. ubiquity adt tests.17:53
cjwatsonxnox,barry: http://bugs.python.org/issue1928717:55
barrycjwatson, xnox ack.  will look in a bit17:56
xnoxmy google foo didn't turn up that newer issue, only the older one.17:56
xnox(against unreleased 3.0)17:56
barryzyga: fwiw, i just converted one of my packages to pybuild.  it's py2 and py3, but it builds -doc package from sphinx: http://anonscm.debian.org/viewvc/python-modules/packages/flufl.i18n/trunk/debian/17:57
cjwatsonxnox: I looked at hg cpython directly17:57
zygabarry: I had to manually run setup.py build_sphinx and add the .docs file to copy them17:59
zygabarry: my mistake was expecting that to be optional (after all, conventions over configuration, right)17:59
* zyga looks at barry's package17:59
zygabarry: cool, I'll copy that17:59
barryzyga: looks like the d/*.install files didn't survive my svn commit.  testing a -3 now18:00
zygabarry: I wonder why I needed the .docs file though18:00
zygabarry: svn, oh my :)18:00
* zyga should push his package somewhere18:00
barryzyga: yay debian python team vcs! :)18:00
barryzyga: what's in your .docs?18:01
zygabarry: don't you need that set -e trick to keep make from hiding errors?18:03
barryzyga: no difference18:07
zygabarry: how so?18:09
barryzyga: well, i don't get errors :)18:09
zygabarry: if build_sphinx fails then it will be hidden by the second invocation18:09
zygahah :D18:09
* zyga wonders about packaging, if it should be separate from the unpacked tarball (as in that svn repo) or both together18:10
* zyga uploaded packaging to github temporairly18:13
barryzyga: it's a good question.  ubuntu source branches have the unpacked source, which i generally like.  debian-python prefers debian-only, so i tend to use that.  it's a bit less convenient to work on, though debcheckout will generally give you something workable (i tend to debcheckout --source=never though if i'm only futzing with packaging and don't need to patch the package)18:14
barryzyga: you can always get a guest account on alioth and use git.debian.org too18:14
barryat least that's free software :)  /me hides18:14
zygabarry: I got an account18:15
zygabarry: but I got lost in using it18:15
zygabarry: alioth (and various debian-send-me-an-email-type infrastructure is rather horrible to discover as a novice)18:15
zygabarry: no, you are right18:15
zygabarry: it's just I'm to stupid to use it :/18:15
zygabarry: I have zyga (or zkrynicki) on alioth, what should I do next?18:16
barryzyga: never blame the user when software sucks! :)18:16
zygabarry: the package I'm building is intended for debian as well18:16
barryzyga: you'll have to use zyga-guest@ until you become a dd18:16
zygaso can I ssh into git.debian.org somehow?18:16
barryyeah, it's confusing sadly18:17
barryzyga: i believe you should be able to ssh zyga-guest@git.debian.org18:17
* zyga gets ssl warning on alioth.debian.org hmmm18:17
zygabarry: how do I copy my ssh key there?18:17
barryzyga: are you sure it's not warning you about the new host key?  alioth crashed a while ago and it came back up a few days ago, but with a new host key18:18
zygais alioth supposed to be signed by ca.debian.org?18:18
zygabarry: ssl warning in firefox, not ssh18:18
* zyga wonders what his username is as the password i have on file doesn't work18:19
zygabarry: can you tell me if it is safe to add the SSL exception for alioth.debian.org (issued by ca.debian.org)18:20
barryzyga: probably, but don't quote me on it.  i almost never use the web ui ;)18:20
barrylooks like it's self-signed18:20
zygabarry: how can I "manage" my account?18:21
zygaoh user zyga doesn't exist18:21
* zyga creates one18:22
barryzyga: you would use alioth.debian.org but you probably need to sign in as zyga-guest (or <yourid>-guest)18:22
=== salem_ is now known as _salem
* zyga sets that up18:23
zygabarry: ha, so my unix name zyga is already taken18:23
zygabut it's not an alioth username18:23
barrysomehow i always manage to get 'barry'.  it's not *that* uncommon as a name ;)18:23
=== gaughen is now known as gaughen_
zygabarry: I'm totally sure zyga is unique18:24
zygabarry: is there a way to debug that? any IRC channel or anythnig?18:24
xeranasHi all, I have trouble to understand how works ConditionalLayout. Maybe someone can give some link to tutorial or source code sample. Basically I want make for desktop 3 column layout and for mobile 1 column. So far I tried this: https://gist.github.com/xeranas/7645981 but not working. Probably I do not understand some key things.18:24
barryzyga: didn't you mention that you'd signed up once before?18:24
zygabarry: yeah but it's claiming my account doesn't exist18:24
=== _salem is now known as salem_
=== gaughen_ is now known as gaughen
barryyou sign up with zyga but use zyga-guest until you become a dd18:25
zygabarry: so now I should be able to ssh zyga-guest@git.debian.org18:26
barryzyga: yep!18:26
zygabarry: yet it doesn't like my password, hmm18:27
* zyga looks18:27
zyganope, just dones't like it18:27
zygabarry: are you sure -guest users have ssh access?18:27
zyga(that is cool but a bit scary)18:27
barryzyga: hard to remember all the details.  maybe your account has to be enabled.  you might have to request being added to a team. https://wiki.debian.org/Teams/PythonModulesTeam18:31
zygabarry: to use svn or git?18:31
zygabarry: should I email ... hmm I don't know what debian-python@?18:32
barryzyga: debian-python@debian.org18:33
zygabarry: thanks18:34
zygabarry: this team https://wiki.debian.org/Teams/PythonModulesTeam ?18:35
zygabarry: there is confusingly named apps team as well18:35
barryzyga: there is.  basically the same group of folks and most of the conventions and policy are the same.  but there are way more modules (i.e. libraries) than apps.  dunno if there's a good reason for the division or mostly historical18:37
zygaok, writing request mail now18:39
zygabarry: I've sent my request, let's see what happens next :)18:43
=== bfiller_afk is now known as bfiller
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== Amaranthus is now known as Amaranth
dkesselgood evening. what would be the "normal" python/qt binding to develop an ubuntu application against? pyqt or pyside?19:44
barryxnox: ./bin/run-adt-test -r trusty -a amd64 -S file:///home/barry/projects/ubuntu/python33/trustyp python3.320:38
barryxnox: no errors :/20:38
=== salem_ is now known as _salem
=== racarr is now known as racarr|lunch
NoskcajCan someone please sponsor https://mentors.debian.net/package/testdrive ?21:10
=== mnepton is now known as mneptok
=== racarr|lunch is now known as racarr
xnoxbarry: /o\ i guess we just need to ping people to retry the auto-pkg-tests.22:33
barryxnox: well, actually i think my command wasn't quite right since it uses python3.3 from the archive (i.e. 3.3.2).  i'm re-running it now building from the source branch, but it takes a loooooooonnnnggggg time22:34
xnoxyeah, it does take forever.22:35
tarpmanare there precise daily-live images somewhere that are built with -updates but not -proposed?22:50
barryxnox: yay.  at least i can reproduce the bug now23:00
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== freeflying is now known as freeflying_away
twbConsider the output of "rmadison -uubuntu,debian -aamd64 firefox iceweasel" -- the Debian entries line up, but the Ubuntu ones don't.23:55
twbAgainst what package should I report that?23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!