=== nudtrobert1 is now known as nudtrobert [03:44] Good morning [08:42] doko: mitya57: sphinx-rtd-theme-common -> libjs-modernizr (universe), missing MIR it seems [08:43] although this BDs on node stuff so that might be a problem [08:46] Laney, right, I may just try to build without that theme [08:50] could maybe replace the minifier in modernizr if we have another one in main === nudtrobert1 is now known as nudtrobert [09:34] ginggs, known problem the local build failure [09:34] I didn't investigate it yet [09:34] but on builders everything is fine [09:39] LocutusOfBorg1: Any chance virtualbox will grow the 'vboxweb-service' of virtualbox-* from Oracle? [09:39] LocutusOfBorg1: hi - i suspect your arch all target needs net access, but trying a binary-only local build now [09:49] Unit193, I don't know what are you talking about :) [09:54] Logan, hey - I need to steal your python-ldap3 merge to resolve some FTBFS in tldap - hope thats OK :) [10:11] LocutusOfBorg1: problem with virtualbox local build failing seems to be if xmllint is found, but PPA build was OK, so I'll sponsor now [10:15] ginggs, true, I might try to find and patch it [10:16] thanks! [10:20] yw [10:32] Unit193, please remember to test the ext-pack [10:49] isn't kind of silly to send /etc/dput.cf with a default to upload to ubuntu ? [10:50] I just accidentally sent a bunch of test grub2 packages by mistake. Good thing I don't have upload rights [11:01] ginggs, I'm going to fix the bug right now [11:01] I already have a fix, but I'm testing it [11:01] unfortunately I don't think it is worth an upload, but let me know if otherwise [11:02] i agree it's not worth an upload on its own [11:02] caribou: dput from an Ubuntu machine? [11:02] sladen: yes [11:03] caribou: it normally is updated to default to the beta release [11:03] sladen: I had changed my laptop setup but forgot to change my test server [11:03] caribou: I changed my default dput.cf as invalid so I always have to be explicit with uploads [11:03] ie. to "do the right thing" for the most frequent users of dput on ubuntu systems [11:03] highvoltage: yeah, did that on my laptop but I'm building on a separate server these days [11:04] ah [11:04] highvoltage: no big deal as they're trusty pkg so they wouldn't go very far [11:04] however it's fair point, and perhaps the [DEFAULT] should be disabled [11:05] sladen: it also contains a local target, so maybe default to local [11:09] caribou: not with a path that probably won't exist for most people [11:09] caribou: at the moment it /does the right thing/ for those with credentials [11:09] caribou: that is different from /doing the wrong thing/ for everyone [11:09] sladen: true [11:10] sladen: I suppose that it's only rejected by the AA scripts anyway [11:19] Laney, I was going to take care of both after wily release, but as doko moved sphinx-rtd-theme to main, I will look at modernizr today. [11:20] mitya57, yeah, was re-enabling the pypy packages, sorry about that [11:20] No problem, it still needed to be done at some point [11:44] doko: hi, is it worth keeping the delta on julia ( https://launchpad.net/ubuntu/+source/julia/0.3.2-1ubuntu1 )? I'd like to sync bug fix release 0.3.11, but can merge if you prefer. [11:46] is anybody maintaining ubuntu still? [11:47] ginggs, well, openlibm would need building on all archs too, let me have a look [11:49] doko, i can apply a smilar 'build everywhere' patch to openlibm and see what happens, but there are still issues with patchelf [11:50] Teduardo, how do you mean ? [11:50] well logjam still hasn't been fixed in sendmail on ubuntu [11:51] the DH key is still too small and it cant send emails to like 80% of the internet [11:51] feel free to send a patch to the universe maintainers then [11:51] sendmail is in universe ... [11:51] ginggs, https://launchpad.net/ubuntu/+source/openlibm/0.4.1+dfsg-1build1 [11:52] comes unmodified from debian [11:53] ugh [11:56] caribou: in practice this doesn't cause much of a problem really [11:58] doko, thanks. meh, so much for "openlibm - High quality system independent, *portable*, open source libm implementation" [11:59] ginggs, at least on armhf it built, but: [11:59] Test suite completed: [11:59] 1131 test cases plus 953 tests for exception flags executed. [11:59] 882 errors occurred. [12:02] cjwatson: Thanks for that openssh fix. <3 [12:02] np [12:03] Odd_Bloke: oh, since you're here, what's the word on powerpc cloud images? [12:03] have been meaning to catch you ... [12:04] cjwatson: I'm going to spend the next couple of weeks moving all of our image building in to Launchpad (currently we have some post-build bits that we do, which means that we need to run kvm for the arch, which means a ppc64el and/or powerpc host to do it on). [12:04] Odd_Bloke: Oh, I thought it already was in Launchpad [12:05] Odd_Bloke: You build ppc64el images today, don't you? [12:05] cjwatson: Yeah, but we're building those on a POWER7 host which is going to be problematic post-wily. [12:05] Odd_Bloke: Sure; but a ppc64el host can run kvm for powerpc guests [12:06] Odd_Bloke: So this shouldn't be a blocker for doing powerpc images [12:06] ginggs, so feel free what to do. I usually like to see the ftbfs explicitly, not just be hidden. but it's your call [12:07] cjwatson: Right, we could do that, but we'd undo it all and put it on to Launchpad in the near future anyway. [12:07] doko, yeah in julia 0.4 they 'use system libm' and 'use system patchelf' and I was able to build it on armhf. I'd like to look trying the same for other archs. So I'll merge 3.11 for now [12:07] doko, hi, I assume librevenge misses the version for conflicts/replaces against *v5 [12:07] And the ppc64el stuff is very hacky, so changing it to support powerpc is high risk. [12:08] Odd_Bloke: All right. Please let me know if there's anything we can do to help, as this will be a major part of moving powerpc into scalingstack. [12:08] So the plan of attack is: (a) move all wily building in to Launchpad (via livecd-rootfs/live-build changes), (b) backport those changes to older versions. [12:08] Odd_Bloke: I'm assuming you can lift a bunch of the control logic from cdimage [12:09] ricotz, why? [12:09] cjwatson: I haven't dug in to it yet; I'm tying up loose ends this week so I can focus on it properly next week. [12:09] OK [12:10] cjwatson: But getting this done is good on many, many levels, so it is definitely going to get done. [12:11] doko, ah sorry, I meant libetonyek [12:12] ricotz, version? [12:14] Conflicts: libetonyek-0.1-1v5 (<< 0.1.3-1ubuntu3) [12:14] (no need to provide a transitional package otherwise) [12:15] like you already did with the other libs like wps [12:22] wps has a transitional package [12:23] cjwatson, i got this ugly resize script (the go_gpt() is to be dropped once bug 1490608 is fixed) ... do you know if i actually need the "blockdev --rereadpt" call if parted just created a new GPT or can i rely on the kernel to update properly [12:23] bug 1490608 in parted (Ubuntu) "parted allows to fix broken GPT only interactively" [Undecided,New] https://launchpad.net/bugs/1490608 [12:23] cjwatson, err http://paste.ubuntu.com/12337129/ [12:25] doko, yes, i know, and in libetonyek you forget the versions, try to install calligra-libs [12:28] ogra_: parted does that itself; you shouldn't need to. [12:28] cool [12:28] thanks [12:28] ricotz, version? [12:29] doko, what do you want to know? you uploaded this 2 hours ago [12:30] ricotz, the version of libetonyek [12:30] https://launchpad.net/ubuntu/+source/libetonyek/0.1.3-1ubuntu3 [12:33] pitti: wolfe-02 is a bit segfaulty. [12:33] doko, https://paste.debian.net/plain/311309 [12:35] ricotz, fix uploaded [12:43] infinity: oh? I don't seen anything unusual in dmesg [12:49] pitti: Well, the segv in the kernel test was definitely not a problem with the binary that segfaulted. [12:49] (I've retried it, hoping for another slave) [12:52] infinity: oh, for linux? I already retried that, but *shrug* [12:52] infinity: you figure rebooting the VM might help? [12:52] pitti: Yeah. [12:53] it's currently running linux-lts-utopic and ruby-libxml [12:53] I'll let at least the latter finish === MacSlow is now known as MacSlow|lunch [13:22] fginther, apw, elopio: do you actually use autopkgtest's "summary" file for anything? i. e. could I change that to summary.json and enrich it with some extra info (kernel versions, adt backend, etc.)? [13:24] hmm, the libxml2 fix introduce some failures. maybe better revert back to 2.9.1 like Debian? [13:26] doko: that error is in tracker's build log now (during the test), but the actual failure is "ERROR: tracker-sparql - missing test plan" -- seems unrelated? [13:26] ginggs, julia still has the b-d on openlibm? [13:26] pitti, glib2.0 on ppc64el failed too after the upload [13:27] otoh, publican now built [13:27] doko, for now yes [13:27] doko: already retried, that looked like another race ("ERROR:/build/glib2.0-7SKaCg/glib2.0-2.45.7/./glib/tests/testing.c:127:test_fork_fail: code should not be reached") [13:28] ok [13:28] will just take an hour or so to catch up, there's some queue [13:55] pitti, erm i use .. err ... is that in the result.tar ... if so no [13:55] apw: no, it's not, it's in artifacts.tar.gz [13:56] pitti, oh so this won't be in results this new info ? [13:56] result.tar [13:57] apw: it will [13:57] anyhow no i do not use artifacts at all [13:57] apw: 'cause you want/need it [13:57] and it's small === MacSlow|lunch is now known as MacSlow [14:12] jamespage, that's an interesting distribution format ;-P http://web.eecs.utk.edu/~plank/plank/papers/GF-Complete-Archive.pdf [14:12] doko, indeed [14:13] doko, it does have a new home - http://jerasure.org/ [14:13] jamespage, why not ship the current version? [14:14] there is a 2.0 release [14:15] doko, so you ping made my observer - let me take a look [14:15] and add a watch file =) [14:18] pitti: sounds like a good idea. [14:18] we don't use it at all. I sometimes look at it. === MacSlow is now known as MacSlow|afk [14:19] doko: looks like modernizr isn't really used by sphinx-rtd-theme, I filed https://github.com/snide/sphinx_rtd_theme/issues/245 and want to wait for upstream confirmation. [14:20] mitya57, ta [14:25] ginggs, http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=b3d9373289eab93f8ddf530549ee296003de8342 [14:25] :) [14:25] thanks [14:27] LocutusOfBorg1: no worries, but your changelog entry doesn't describe what you actually did [14:29] doko, I need to look at this properly, but my inkling is that all of the testing both in debian/ubuntu and upstream has currently been done against the current packaged version, not the newer one [14:29] upstream in swift/liberasurecode that is [14:33] jamespage, python-pyeclib looks ok, but the three library package could need some cleanup [14:33] doko, ack [14:34] doko, what about liberasurecode? I have done work directly on that package to knock it into shape [14:34] liberasurecode: [14:34] - liberasurecode1 has a hard-coded dependency on a shared library, please remove [14:34] - there is a newer 1.0.9 release, update? [14:34] please also fix: [14:34] - enable parallel build [14:34] - add Multi-Arch: same attributes [14:34] - library is underlinked, -ldl missing [14:35] so minimum is to remove the hard coded library [14:36] doko, its hard coded as its loaded as a plugin, not as a linked library [14:36] (libjerasure2 I'm assuming) [14:37] ohh [14:38] ginggs, true [14:40] updated [14:40] jamespage, ok, makes sense [14:42] pitti: Wat? [14:42] autopkgtest for keystone 2:8.0.0~b2-0ubuntu2: armhf: Test in progress [14:42] pitti: Why did python-passlib only trigger keystone on armhf and no other arches? [14:43] infinity: you know, you have sooo many questions! [14:43] pitti: I KNOW! [14:44] infinity: filed as bug 1494786, for my Monday enjoyment [14:44] bug 1494786 in Auto Package Testing "sometimes triggers tests for one architecture only" [Undecided,New] https://launchpad.net/bugs/1494786 [14:44] pitti: Oh, it might relate to there also being a new keystone. [14:44] pitti: Could just be a bit racy on the version mismatch? [14:45] yeah, I guess something like that [14:45] infinity: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sqlalchemy is just fine, but that already ran 6 days ago [14:45] so it's not about keystone in particular I think [14:53] LocutusOfBorg1: looks good :) [15:06] thanks ^2 === MacSlow|afk is now known as MacSlow [15:23] mvo: can I update packagekit to 0.9.5 and packagekit-qt to 0.9.5? that seems to give me what I want to work [15:32] Riddell: I can not thing of a reason why not, but I have not really followed that development that much recently [15:32] Riddell: I did the app-install-data update too [15:33] mvo: yeah saw that thanks [15:33] yw [15:33] mvo: I've got the updated packages here and it works for packagekit-qt, anything else I should test it with? [15:35] Riddell: not from my side [15:35] Riddell: maybe worth checking with Laney [15:35] Laney: ping :) [15:37] Riddell: dunno, look at rdeps :) [15:38] mvo: Oh hey, you're around. [15:39] mvo: It came up yesterday in the LP meeting, wrt hashed Packages, is apt 1.1 targetted for 16.04 (and, if not, how can we make it be?) [15:52] infinity: yes, early wily+1 [16:04] infinity: it will go to unstable once there are less transitions [16:08] mvo: Excellent. The sooner, the better, IMO. [16:08] yes! [16:09] pitti, nothing I look after uses summary [16:09] (which is just boottest) [16:36] I'm trying to help someone who using using debconf to produce an installer for a package. He's using the example given within http://manpages.ubuntu.com/manpages/utopic/man7/debconf-devel.7.html - in essence 'go back' from step 2 to step 1 works fine in the curses installer, but not in the CD-ROM installer. Is there a known example where 'go back' is implemented in a shell script and works for the CD-ROM instal [16:36] ler? Or any clues on how to debug it? [16:37] (for bonus points, it worked on 10.04 allegedly, but not 14.04) [16:37] should work the same way, I suggest getting DEBCONF_DEBUG=developer traces from both and comparing [16:37] generally the first step with any debconf problem [16:40] cjwatson, thanks. What actually implements db_go? (as you can tell I know nothing about this!) [16:40] (I mean on the CDROM installer) [16:43] alexbligh1: /usr/share/debconf/confmodule in either case [16:44] alexbligh1: but it gets sent to whatever implements the server end of the debconf protocol; cdebconf in the case of d-i (which I'm guessing is what you mean by the "curses installer", btw it only looks a bit like curses it isn't actually curses), debconf in the case of ubiquity (which I'm guessing is what you mean by the "CD-ROM installer") [16:44] alexbligh1: in the case of ubiquity, ubiquity intercepts the debconf protocol and fiddles with it in some cases [16:44] so um it depends [16:45] but DEBCONF_DEBUG=developer is absolutely the first step, it may well just be a simple bug at the client end [16:45] cjwatson, um, I mean whatever the thing is with the blue background at the normal command line on ubuntu-server once installed in the first case, and whatever you get on a normal ubuntu server CD-ROM install on the other. No graphical fanciness I don't think. [16:46] cjwatson, thanks. I'm wondering if something is fiddling with the return values somehow. It's as if db_go is always returning 0 (i.e. 'next'). [16:47] alexbligh1: oh, that wasn't at all how I interpreted what you meant ... [16:47] alexbligh1: debconf in the former case, cdebconf in the latter, then [16:47] alexbligh1: that sounds like the backup capb isn't set [16:47] cjwatson, how does one set the backup capability (assuming I'm translating that right)? [16:48] alexbligh1: db_capb backup [16:48] cjwatson, (the button appears, it just doesn't work) [16:48] alexbligh1: ok, if the button appears, the capb is likely set [16:49] cjwatson, that's right at the top of the example in the man page so I'm pretty sure he used that - let me check the source .... [16:49] alexbligh1: so let's see a debug trace [16:49] much quicker than guessing [16:50] cjwatson, yeah it starts "db_version 2.0" then "db_capb backup". I'll get him to produce a debug trace. I think he's gone home now (slacker). [16:50] cjwatson, thanks anyway [16:50] alexbligh1: go back definitely works in d-i, we use it in many places [16:51] inc. from shell, not that it makes a difference, same protocol either way [16:51] cjwatson, yeah, though he couldn't find an instance of it working from the CD-ROM, save for Postfix which is allegedly written in perl. [16:52] alexbligh1: localechooser for instance, very first stage of the installer, written in shell [16:52] cjwatson, apparently it only breaks if you ask more than one question in each stage or something. Debug trace needed anyway. [16:52] cjwatson, ok, I will point him at that. [16:52] cjwatson, thanks [16:52] alexbligh1: cdebconf doesn't support grouping, perhaps that's the problem. you must ask one question per stage [16:52] cjwatson, AAAAAHHHH! well that would be exactly the issue. [16:53] the beginblock/endblock stuff will not work with cdebconf [16:53] cjwatson, right. Well that explains everything. Thanks a million. Looks like we'll need to split it out into one stage per question (which is easy enough). [16:53] (it's only a stub with debconf too; but perhaps the fallback mode is different) [16:54] yeah [16:54] np [18:55] doko! [18:55] knock it off with these perl pkgs :) [18:55] ;) [18:55] I'll get this one, no prob [18:56] should be the last ones for this cycle, promised! === juliank0 is now known as juliank