=== freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === Ursinha-afk is now known as Ursinha [04:43] catbus1: ping [06:21] Good morning === work_alkisg is now known as alkisg [07:51] morning === iahmad is now known as iahmad|afk [08:48] good morning === coalwate1 is now known as coalwater === freeflying is now known as freeflying_away === iahmad|afk is now known as iahmad [09:27] lamont: just found yet another wipefs bug in our ancient util-linux.. any chance we'll get a newer version at some point? [09:29] lamont: I guess nobody else is able to touch/update that package with the single big debian.diff.gz :/ === doko_ is now known as doko [09:40] slangasek: btw, I set you as reviewer for https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming, is that ok? [09:40] slangasek: s/reviewer/approver/ [09:42] pitti: there is a git repo for util-linux. [09:43] but yeah, new util-linux would be nice. At least for /etc/fstab.d/ which would be very nice. === freeflying_away is now known as freeflying [09:53] is that just me, or does software-center hang/crash at startup for other people, too? [09:53] some DBInvalidArgError in /usr/share/software-center/softwarecenter/backend/reviews/__init__.py [09:54] pitti: did my db transition gone wrong? [09:54] softwarecenter.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] could very well be a corrupted local BDB database [09:54] I see that, but it doesn't crash it for me [09:55] pitti: 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] and eventually it crashes with a BadDrawable X window error [09:55] xnox: usually not; so far, every BDB update only changed the on-disk format for transactions [09:55] (there was a window when db versions of software centre and the lense were different) [09:55] but almost all software only uses in-memory transactions [09:55] crash> probably https://bugs.webkit.org/show_bug.cgi?id=123480 [09:55] bugs.webkit.org bug 123480 in WebKit Gtk "ubuntu software center hits _XReadEvents() error" [Normal,Unconfirmed] [09:55] Laney: ah, so it runs, but doesn't crash with the drawable? [09:56] * ogra_ has it too [09:56] it's pretty common, but I never managed to get it [09:56] seb128, didrocks, lool: http://developer.ubuntu.com/packaging/ (check what's new on there :-)) [09:56] software centre freezes here up into a dark window [09:57] yup [09:57] xnox, Laney: I get the freeze in a guest session too, so not related to DB migration [09:57] no, it's old [09:57] the "invalid db->open argument' still looks scary, though [09:57] its webkit [09:58] ogra_: ok, thanks [09:58] maybe someone who gets it could ping on that bug [09:59] bug 1211887 [09:59] bug 1211887 in software-center (Ubuntu) "software-center crashed with signal 5 in _XReadEvents()" [High,Confirmed] https://launchpad.net/bugs/1211887 [10:00] looks like 47 people did already :) [10:00] pitti, s-c and webkit don't like each others :/ [10:00] but not easy to debug [10:00] and nobody upstream replied to the report yet [10:01] /usr/share/software-center/softwarecenter/backend/ubuntusso.py verify_token_sync() looks relatively isolated [10:01] dholbach, I never looked at that yet, not sure what is new ... it's not in french though [10:01] seb128, there should be french on there! [10:01] dholbach, lol, is there any other try at getting translators to do their job? ;-) [10:02] seb128, the French translation is done 100% now [10:02] dholbach, \o/ [10:07] In 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] The 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:10] break=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:11] what 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:15] seb128: completely english for me though! ;) [10:15] didrocks, same here, tell dholbach! [10:15] seb128: even not German for you? [10:16] * didrocks runs [10:16] ;) [10:16] * seb128 slaps didrocks [10:16] :( [10:16] seb128, translations are linked from there, you hippies! [10:16] xnox: it's about the same as init=/bin/bash, although plymouth does allocate a vt in that case [10:17] dholbach, where? [10:17] * seb128 can't see it [10:17] seb128, http://developer.ubuntu.com/packaging/ - search for "French"? [10:17] xnox: In previous versions, plymouth special-cased anything that started from /sbin/init*, maybe they changed their special casing to only include /bin/bash? [10:18] dholbach, no match [10:18] seb128, argh [10:18] xnox: we want early breaks to troubleshoot stuff before upstart or other service have a chance to run, but after the initramfs [10:18] seb128, sorry, something's wrong - I could just see it, because I was the admin of the page in WP - nevermind [10:18] dholbach, ;-) [10:18] dholbach, you hippie! [10:18] :p [10:18] didrocks, seb128, http://developer.ubuntu.com/packaging/fr/html/ [10:18] :) [10:18] dholbach, c'est mieux [10:18] ;-) [10:19] alkisg: 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] dholbach: ah, le packaging guide est *enfin* fixé ;) (just have to push it to default url now :p) [10:19] alkisg: that's what ubuntu boot into, if previous boot fails. [10:19] didrocks, 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 instance [10:19] alkisg: there should be a boot entry marked "... (recovery mode)" [10:20] dholbach: ahah, in fact, I meant put the French page as default of course :) [10:20] didrocks, haha [10:21] xnox: 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:24] alkisg: =/ 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:25] xnox: plymouth does support init=/bin/bash, i.e. it allows bash to have a vt [10:26] But I think that if I rename it, it doesn't [10:26] It did in 12.04, it doesn't in 14.04 [10:26] alkisg: 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:27] xnox: plymouth is in the initramfs though, isn't it? [10:27] alkisg: if there is plymouth in the initramfs, and it was started from there, it will need to be stopped someway. [10:28] Plymouth has code that reads the kernel command line for that specific case... at least it did when I looked in 12.04 [10:28] alkisg: 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] And now that part of its code no longer works... [10:28] xnox: ah, that's good to know. Until 12.04 stgraber pulled plymouth in the initramfs from the ltsp package [10:28] (it's still in effect in 14.04), [10:29] ...so if we remove it, it will solve the vt problem... [10:29] i don't think that's what you want. [10:29] check the code and file a bug. [10:30] You're right about that. Thanks, /me apt-get source's plymouth... [10:30] bzr branch lp:ubuntu/plymouth might be better. [10:31] pitti: I know that packages in main cannot depend on packages in universe but they can still recommend them, can't they? [10:31] tseliot: no, only suggests [10:32] pitti: ok, I guess I have a problem then, as the new release of nvidia prime (main) will need bbswitch (universe) [10:33] pitti: is a MIR the only solution? [10:33] tseliot: recommends are also considered for main inclusion. suggests are not. [10:33] tseliot: if the kernel team and/or you is fine with maintaining that additional kernel driver, sure [10:33] (build-depends, depends, recommends) are all pulled into main. [10:34] tseliot: i. e. the question is whether we want to support nvidia prime [10:34] pitti: oh, I can definitely maintain it [10:34] xnox: yeah, strstr (state->kernel_command_line, " init=") != NULL; ==> that was removed... /me looks deeper before filing a bug report, thanks for your assistance [10:34] xnox: right [10:34] * xnox 's irc is lagging today. [10:35] pitti: yes, I think we (oem) do [10:36] xnox: 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] So we'll need to rename our custom init to "init-ltsp-sh" :( [10:37] stgraber: ^ [10:37] alkisg: alternatively your script can ping plymouth to check if it is up and stop it yourself. [10:37] xnox: do you have those commands handy? [10:37] (good idea, thank you!) [10:38] alkisg: check plymouth --help; and try them out. Also see testing at https://wiki.ubuntu.com/Plymouth [10:38] Thanks a lot [10:41] Ouch, plymouth quit at that point produces some more udev messages and then hangs the system. /me tries renaming init-ltsp... [10:48] Haha, "init=/sbin/init-sh init=/sbin/init-ltsp" did the trick. The first one tricked plymouth, the second one was the actual init. [10:49] * alkisg checks if the plymouth patch is ubuntu specific, to request a change there... === 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 [13:29] doko, barry: FYI, autopkgtest notifications have been broken since the lab move, so playing email relay: python{2.7,3.3,3.4} autopkgtests currently fail [13:30] pitti, please ignore those for 3.4 [13:30] doko: ack [13:30] doko: (there are some str vs. bytes confusion) [13:30] pitti, url for the others? [13:31] https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python2.7/ [13:31] https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python3.3/ [13:31] latest is https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python3.3/9/ARCH=i386,label=adt/ [13:31] doko: that seems to have similar str vs bytes issues ("TypeError: gdbm key must be bytes, not str", and others) === MacSlow|lunch is now known as MacSlow [13:32] doko: ah, actually no; that's the only test on 3.3 that fails [13:35] pitti, 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] on i386 [13:51] hey, are recommends installed during clean package builds? [13:51] I guess not, correct? [13:52] correct [13:52] great :) [13:53] doko: 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 locally [13:55] pitti: shove a random generator hw dongle into the test host to solve the problem :) [13:55] well, installing haveged might already help [13:56] http://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators [14:00] zyga: well, it's a VM -- you need virtual hw :) [14:01] pitti: you can plug the usb dongle into the vm I guees, or shove randomness somehow from the hos [14:01] t === Sweetsha1k is now known as Sweetshark [14:13] pitti, 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:18] anyone able to ack (or review and reject) plymouth-disabler (https://launchpad.net/ubuntu/trusty/+queue?queue_state=0&queue_text=) [14:19] smoser: is it really a 2.8KiB package? can we not instead merge it / build it from plymouth source package? [14:20] xnox, slangasek was fairly strongly opposed to that. [14:20] oh really =) interesting. [14:20] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1235231 [14:20] Ubuntu bug 1235231 in plymouth (Ubuntu) "plymouth loses output to /dev/console (such as ci-info: messages)" [High,Confirmed] [14:20] (although i don't have his response to that specifically in that bug) [14:22] smoser: 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] it has nothing to do with cloud-init [14:22] plymouth has a dataloss bug [14:22] this is completely unrelated to cloud-init [14:22] (maybe not cloud-init upstream, not sure about cloud-init debian pkg) [14:23] sure I understand there. [14:23] smoser: people rarely notice which src package a particular binary package is build from =) [14:24] my 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:25] i'd like to reduce delta not increase it. [14:25] ok. 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:30] Disabling plymouth is awkward. It doesn't matter in the cloud-init case, but for example lightdm starts on plymouth-ready. [14:30] I had to create a dummy upstart job for that. [14:30] you had to do that where? [14:31] It seems to me that disabling plymouth is quite heavily tied to plymouth's packaging. [14:31] smoser: on my Chromebook, for https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1082742 [14:31] Ubuntu bug 1082742 in plymouth (Ubuntu) "plymouthd: ply-terminal.c: 611 ply_terminal_open: Assertion `terminal != ((void *)0)' failed." [Undecided,Confirmed] [14:31] maybe we need to just fix plymouth. [14:32] should documentation packages be called -doc or -docs? [14:32] I see both used heavly in the archive [14:32] but fixing plymouth properly would take me quite a while. [14:33] I 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=1 [14:34] I presume click packages are going to be a replacement of sorts/ [14:35] http://etoileos.com/news/archive/2007/07/19/1755/ [14:35] what do you guys think of this? [14:37] doko: 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:40] smoser: 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. === rickspencer3_ is now known as rickspencer3 [14:41] Having said that, I'm not clear how such a dep8 test might work. It'd need a reboot :-( [14:41] doko: same assert failure in quantal chroot with python3.2 & python3-gdbm installed. and db5.1 [14:42] xnox, hrm, did only check 3.3.2 in saucy, and didn't see it [14:43] barry: 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:44] doko: hm, strange. unless something in unittests / assertIn / containers changed. [14:44] xnox: sorry, i need context [14:44] barry, https://launchpadlibrarian.net/157438095/buildlog_ubuntu-trusty-amd64.python3.3_3.3.3-2_UPLOADING.txt.gz [14:45] doko: hmm. that's caused by the libdb5.3 change? [14:45] barry: grep doko/xnox/barry highlights above from :13m past till now. [14:46] barry, that's what I was thinking, until xnox pointed out the quantal log [14:48] doko: well, not quantal log, just me trying it locally in a quantal chroot in an interractive shell. [14:48] xnox: let me see if i can reproduce locally [14:49] barry, please configure -with-dbmliborder=bdb:gdbm [14:49] -- even [14:53] seb128, uploaded libffi to unstable again, please yell when you see the same failures after the sync [14:53] doko: 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:54] jdstrand: are you aware of bug 1242726, please? [14:54] bug 1242726 in php5 (Ubuntu) "[MIR] php5-common is missing dependency on php5-json" [High,Triaged] https://launchpad.net/bugs/1242726 [14:54] doko, ok [14:54] jdstrand: it's awaiting your review. [14:54] doko, you hope to have it fixed with that version? can't you test before syncing? [14:54] xnox, well, the test iterates dbm._names and fails for the ndbm case, not the gnu one [14:55] seb128, how? [14:55] doko, try building one of the indicators which was failing on ppc? [14:55] seb128, where? [14:55] sure, I can do that in a ppa [14:56] doko: oh, did i use the wrong backend ?! let me try again. [14:57] doko, dunno where, do we have any ppa which includes ppc builders? [14:57] I'll do in one [14:57] thanks [15:01] barry: is dh_sphinxdoc expected to work for python3-only projects? [15:01] zyga: 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:02] barry: I have a relatively simple python3 libary+program and dh_sphinxdocs fails to find any documentation and breaks [15:02] zyga: it works for click [15:02] rbasak: I was not aware of that bug [15:02] barry: is it the case that I should be building docs myself in som overrides? [15:03] barry: 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] except I had to add a no-op override_dh_sphinxdoc-arch rule [15:03] cjwatson: ok, I'll check out click packaging [15:03] sarnold: can you take a look at 1242726 when you've got some time? [15:03] cjwatson: why? [15:03] zyga: if you find a problem, please file a bug [15:03] barry: on sphinx(ubuntu)? [15:03] * xnox thought python3-sphinx should be used with python3-only projects. [15:03] jdstrand: OK, thanks for following up. [15:04] xnox: I'm using that [15:04] ok. [15:04] zyga: https://launchpad.net/ubuntu/+source/click-package/0.1.1/ [15:04] cjwatson: thanks! [15:04] zyga: if that's easiest yes. i'll at least forward it on to debian, which is where it probably needs to be fixed [15:04] (the package was renamed to click shortly after that; those build failures illustrate the problem though) [15:05] xnox, doko so, upstream 3.3 hg builds find with --with-dbmliborder=bdb:gdbm [15:05] *fine [15:05] zyga: 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, personally [15:08] cjwatson: I see that you build docs manually, through build override [15:09] cjwatson: I just copied that aspect, still get http://pastebin.ubuntu.com/6474229/ (essentially, dh_sphinxdoc saying that it cannot find docs) [15:11] zyga: that means that the packages that dh_sphinxdoc is operating on do not include any that sphinx docs would be copied into [15:11] or, sorry, any that sphinx docs *have been* copied into [15:12] you need to install the docs into the package before running dh_sphinxdoc to mangle them [15:14] cjwatson: ah [15:14] cjwatson: so I need to override install to copy docs to debian/tmp/usr/share/docs/ ? [15:18] zyga: well, I just did it with debian/click-doc.docs [15:18] zyga: but sure, something like that [15:19] cjwatson: ah, interesting, thanks, I'll try that [15:26] barry, does it pass the tests too? [15:28] doko: upstream hg 3.3 head does, yes [15:29] I don't have any dbm specific patches :-/ [15:29] doko: i'm building the 3.3 trusty-proposed now in my -amd64 chroot [15:35] * xnox ponders if this is somehow affected by locale. [15:35] (e.g. UTF-8 vs a non-UTF-8 locale) [15:38] cjwatson: 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) === freeflying is now known as freeflying_away [15:44] zyga: habit [15:44] zyga: 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 so [15:45] isn'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] (if they ship public modules/extensions) [15:49] xnox: 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:50] zyga: the pyc's will be version tagged, plus extension modules must be compiled for the specific python abi version. see peps 3147 and 3149 [15:50] zyga, yes, but it would be a good idea to test it with 3.4, and have any extensions built with 3.4 [15:50] barry: ah, good point! [15:51] ok, thanks [15:51] so looping it is [15:51] zyga: also, i think with pybuild you don't need to explicitly loop [15:51] oh? [15:51] I was about to ask if pybuild does that for you [15:52] i 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] doko: test_site crashes in an sbuild because /sbuild-nonexistent isn't lying ;) [15:52] barry: do I need to loop over pythons when doing build_sphinx? [15:53] zyga: i wouldn't think so, if you have a -doc binary package, it only needs to be built once [15:53] ok [15:54] * 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 everything [15:56] zyga: 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. === freeflying_away is now known as freeflying [15:57] xnox: 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_sphinx [15:57] and that _should_ be enugh [15:57] enough === adam_g_afk is now known as adam_g [16:25] barry, yes, test_site needs fixing. but that's known [16:25] doko: cool. i broke my local build for unrelated reasons, so i'm starting over :/ === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [16:45] barry, xnox: is there a way to force a script of out python3-foo package and into the foo package? [16:46] (without doing everything manually again) [16:55] smoser: eh, why would these upstart overrides in any way distance the package from Debian? That would be entirely upstreamable [16:55] i dont know. its delta versus it now. [16:56] i guess its not significant, but it just really bothers me in general to "fix" a bug in package A from package B. [16:57] i pushed some upstream. given rbasak's comments, it seems that disabling plymouth could cause fallout elsewhere. [17:01] slangasek: 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. === bfiller is now known as bfiller_afk [17:08] zyga: export PYBUILD_DESTDIR_python3=debian/foo, if you simply want binary package "foo" to have python3 modules & scripts. [17:08] zyga: PYBUILD_NAME=foo, is mostly a shorthand of PYBUILD_DESTDIR_pythonX=debian/pythonX-foo [17:09] for all python-variants (pypy, python3, python) [17:09] and versions of thereoff. [17:10] xnox: I want the modules to be in python3-foo and the main script to be in foo [17:10] xnox: it's more complicated as I need one other script to be in the python3-foo package (it's part of the library) [17:11] * zyga asked the same question on debian-python@ just now [17:11] ah =/ hm... i'd just do "mv" in override_dh_auto_install: after a normal dh_auto_install. [17:11] xnox: let me try that :) [17:14] zyga: or maybe better ovverride dh_install instead, as i really dislike having to pass --buildsystem=pybuild when overriding dh_auto_* targets. [17:14] oh, I didn't rememeber that [17:15] xnox: but I'd have to invoke dh_install there, right? [17:15] * zyga tries that [17:15] yeah. [17:16] cool [17:17] * 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] I need to finish and properly demonstrate that to people [17:17] (zero setup time as in, it costs nothing to spin up a clean build chroot) [17:20] well 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] what does your setup improve? === salem_ is now known as _salem [17:22] xnox: 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:23] xnox: I'm using overlayfs, tmpfs (remouted ro), upstart jobs to bring a lot of that up, and some bind mounts [17:23] xnox: I'm consuming simple meta-data files that tell you how to set up the environment and what to do inside [17:23] xnox: one use-case is to build packages cleanly [17:24] xnox: but that's not the only use case and the meta-data file can, e.g. run tests on a given environment [17:25] xnox: 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] xnox: and 'you need btfs,lvm' or something similar [17:25] xnox: something I could give anyone running 12.04+ and get the same result, fast [17:25] zyga: right, which is what mk-sbuild did. $ mk-sbuild trusty; sbuild -d trusty *.dsc [17:25] which is using overlayfs, snpashot by default with no configs required at all. [17:26] xnox: 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 file [17:26] * xnox migrated from custom sbuild to stock mk-sbuild without any configs and I'm quite happy. [17:27] zyga: unit tests should always run at package build time. [17:27] What 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] Right now I modify the source chroot and have to remember to modify it back. [17:27] xnox: unit tests may want to run more often than that, without building the package [17:27] Or modify ~/.sbuildrc with custom setup commands [17:27] (and remember to modify it back) [17:28] Stacked overlays would be nice. [17:28] xnox: I mean, what I built locally is just an interation of this idea [17:28] xnox: 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] I was surprised to be unable to find an sbuild option that overrides ~/.sbuildrc with another file. [17:28] xnox: oh, also, no perl, python3 api [17:28] * rbasak EODs [17:29] rbasak: 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] rbasak: but yeah, it's less than ideal at the moment for that. [17:29] xnox: I'm sure what I wrote is half broken sbuild :-) [17:29] xnox: but I'm happy with the input file and no perl aspects [17:29] xnox: thanks, I'll look in to that. An env variable sounds like a good idea. [17:29] xnox: I'll polish it and show it to people for feedback === _salem is now known as salem_ [17:31] zyga: 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:32] xnox: yeah, my package actually uses that [17:32] xnox: but that's not enough really [17:32] xnox: we run tests on landing and now we want to build packages on landing too [17:32] xnox: we want to run tests without heavy VMs (which will improve the test cycle a lot for what we do) [17:33] xnox: and sadly while autopkg tests are great, it's not easy to just run them [17:33] xnox: and since we don't have on-merge packages, it's not an option [17:33] xnox: + 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 offline [17:34] xnox: I'm sure there's an overlap but the standard solution is hard to apply to our case [17:43] doko, xnox yeah, no problems building trusty-p python3.3 here in a local chroot [17:44] * xnox ponders if autopkgtest used missmatched source & binary packages under-test. [17:44] xnox: i did not run the autopkgtests. is that where the failure is happening? [17:44] barry: but i thought it should be allowed to look up string keys, after they were implicitely converted and stored as bytes. [17:44] barry: correct. [17:45] (it's running unit-tests though) and it looks safe enough to execute adt null runner inside chroot. [17:45] xnox: well, if it works during package build, it should work during autopkgtesting. maybe there's locale weirdness involved? [17:48] barry: I did pull-lp-source python3.3; python3.3 ./python3.3-*/Lib/test/test_dbm_ndbm.py fails. [17:49] http://paste.ubuntu.com/6474943/ [17:50] * xnox 's locale is Standard British English (UTF-8) [17:52] xnox: 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 error [17:52] That looks like a bug in the dbm module to me ... [17:53] It does a PyUnicode_Check and then fails anyway [17:53] barry: 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:55] xnox,barry: http://bugs.python.org/issue19287 [17:56] cjwatson, xnox ack. will look in a bit [17:56] my google foo didn't turn up that newer issue, only the older one. [17:56] (against unreleased 3.0) [17:57] zyga: 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] xnox: I looked at hg cpython directly [17:58] ok. [17:59] barry: I had to manually run setup.py build_sphinx and add the .docs file to copy them [17:59] barry: my mistake was expecting that to be optional (after all, conventions over configuration, right) [17:59] * zyga looks at barry's package [17:59] oh [17:59] barry: cool, I'll copy that [18:00] zyga: looks like the d/*.install files didn't survive my svn commit. testing a -3 now [18:00] barry: I wonder why I needed the .docs file though [18:00] barry: svn, oh my :) [18:00] * zyga should push his package somewhere [18:00] zyga: yay debian python team vcs! :) [18:01] zyga: what's in your .docs? [18:01] build/sphinx/html [18:03] barry: don't you need that set -e trick to keep make from hiding errors? [18:07] zyga: no difference [18:09] barry: how so? [18:09] zyga: well, i don't get errors :) [18:09] barry: if build_sphinx fails then it will be hidden by the second invocation [18:09] hah :D [18:09] ok [18:10] * zyga wonders about packaging, if it should be separate from the unpacked tarball (as in that svn repo) or both together [18:13] * zyga uploaded packaging to github temporairly [18:13] https://github.com/zyga/debian.plainbox/tree/master/debian [18:14] zyga: 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] zyga: you can always get a guest account on alioth and use git.debian.org too [18:14] at least that's free software :) /me hides [18:15] barry: I got an account [18:15] barry: but I got lost in using it [18:15] barry: alioth (and various debian-send-me-an-email-type infrastructure is rather horrible to discover as a novice) [18:15] barry: no, you are right [18:15] barry: it's just I'm to stupid to use it :/ [18:16] barry: I have zyga (or zkrynicki) on alioth, what should I do next? [18:16] zyga: never blame the user when software sucks! :) [18:16] barry: the package I'm building is intended for debian as well [18:16] zyga: you'll have to use zyga-guest@ until you become a dd [18:16] ok [18:16] so can I ssh into git.debian.org somehow? [18:17] yeah, it's confusing sadly [18:17] zyga: i believe you should be able to ssh zyga-guest@git.debian.org [18:17] * zyga gets ssl warning on alioth.debian.org hmmm [18:17] barry: how do I copy my ssh key there? [18:18] zyga: 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 key [18:18] is alioth supposed to be signed by ca.debian.org? [18:18] barry: ssl warning in firefox, not ssh [18:19] * zyga wonders what his username is as the password i have on file doesn't work [18:20] barry: can you tell me if it is safe to add the SSL exception for alioth.debian.org (issued by ca.debian.org) [18:20] zyga: probably, but don't quote me on it. i almost never use the web ui ;) [18:20] looks like it's self-signed [18:21] barry: how can I "manage" my account? [18:21] oh user zyga doesn't exist [18:22] * zyga creates one [18:22] zyga: you would use alioth.debian.org but you probably need to sign in as zyga-guest (or -guest) === salem_ is now known as _salem [18:23] * zyga sets that up [18:23] barry: ha, so my unix name zyga is already taken [18:23] but it's not an alioth username [18:23] :D [18:23] somehow i always manage to get 'barry'. it's not *that* uncommon as a name ;) === gaughen is now known as gaughen_ [18:24] barry: I'm totally sure zyga is unique [18:24] barry: is there a way to debug that? any IRC channel or anythnig? [18:24] Hi 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]