[03:44] <pitti> Good morning
[08:42] <Laney> doko: mitya57: sphinx-rtd-theme-common -> libjs-modernizr (universe), missing MIR it seems
[08:43] <Laney> although this BDs on node stuff so that might be a problem
[08:46] <doko> Laney, right, I may just try to build without that theme
[08:50] <Laney> could maybe replace the minifier in modernizr if we have another one in main
[09:34] <LocutusOfBorg1> ginggs, known problem the local build failure
[09:34] <LocutusOfBorg1> I didn't investigate it yet
[09:34] <LocutusOfBorg1> but on builders everything is fine
[09:39] <Unit193> LocutusOfBorg1: Any chance virtualbox will grow the 'vboxweb-service' of virtualbox-* from Oracle?
[09:39] <ginggs> LocutusOfBorg1: hi - i suspect your arch all target needs net access, but trying a binary-only local build now
[09:49] <LocutusOfBorg1> Unit193, I don't know what are you talking about :)
[09:54] <jamespage> Logan, hey - I need to steal your python-ldap3 merge to resolve some FTBFS in tldap - hope thats OK :)
[10:11] <ginggs> 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] <LocutusOfBorg1> ginggs, true, I might try to find and patch it
[10:16] <LocutusOfBorg1> thanks!
[10:20] <ginggs> yw
[10:32] <LocutusOfBorg1> Unit193, please remember to test the ext-pack
[10:49] <caribou> isn't kind of silly to send /etc/dput.cf with a default to upload to ubuntu ?
[10:50] <caribou> I just accidentally sent a bunch of test grub2 packages by mistake. Good thing I don't have upload rights
[11:01] <LocutusOfBorg1> ginggs, I'm going to fix the bug right now
[11:01] <LocutusOfBorg1> I already have a fix, but I'm testing it
[11:01] <LocutusOfBorg1> unfortunately I don't think it is worth an upload, but let me know if otherwise
[11:02] <ginggs> i agree it's not worth an upload on its own
[11:02] <sladen> caribou: dput from an Ubuntu machine?
[11:02] <caribou> sladen: yes
[11:03] <sladen> caribou: it normally is updated to default to the beta release
[11:03] <caribou> sladen: I had changed my laptop setup but forgot to change my test server
[11:03] <highvoltage> caribou: I changed my default dput.cf as invalid so I always have to be explicit with uploads
[11:03] <sladen> ie. to "do the right thing" for the most frequent users of dput on ubuntu systems
[11:03] <caribou> highvoltage: yeah, did that on my laptop but I'm building on a separate server these days
[11:04] <highvoltage> ah
[11:04] <caribou> highvoltage: no big deal as they're trusty pkg so they wouldn't go very far
[11:04] <sladen> however it's fair point, and perhaps the [DEFAULT] should be disabled
[11:05] <caribou> sladen: it also contains a local target, so maybe default to local
[11:09] <sladen> caribou: not with a path that probably won't exist for most people
[11:09] <sladen> caribou: at the moment it /does the right thing/ for those with credentials
[11:09] <sladen> caribou: that is different from /doing the wrong thing/ for everyone
[11:09] <caribou> sladen: true
[11:10] <caribou> sladen: I suppose that it's only rejected by the AA scripts anyway
[11:19] <mitya57> 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] <doko> mitya57, yeah, was re-enabling the pypy packages, sorry about that
[11:20] <mitya57> No problem, it still needed to be done at some point
[11:44] <ginggs> 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] <Teduardo> is anybody maintaining ubuntu still?
[11:47] <doko> ginggs, well, openlibm would need building on all archs too, let me have a look
[11:49] <ginggs> doko, i can apply a smilar 'build everywhere' patch to openlibm and see what happens, but there are still issues with patchelf
[11:50] <ogra_> Teduardo, how do you mean ?
[11:50] <Teduardo> well logjam still hasn't been fixed in sendmail on ubuntu
[11:51] <Teduardo> the DH key is still too small and it cant send emails to like 80% of the internet
[11:51] <ogra_> feel free to send a patch to the universe maintainers then
[11:51] <ogra_> sendmail is in universe ...
[11:51] <doko> ginggs, https://launchpad.net/ubuntu/+source/openlibm/0.4.1+dfsg-1build1
[11:52] <ogra_> comes unmodified from debian
[11:53] <Teduardo> ugh
[11:56] <cjwatson> caribou: in practice this doesn't cause much of a problem really
[11:58] <ginggs> doko, thanks. meh, so much for "openlibm - High quality system independent, *portable*, open source libm implementation"
[11:59] <doko> ginggs, at least on armhf it built, but:
[11:59] <doko> Test suite completed:
[11:59] <doko>   1131 test cases plus 953 tests for exception flags executed.
[11:59] <doko>   882 errors occurred.
[12:02] <Odd_Bloke> cjwatson: Thanks for that openssh fix. <3
[12:02] <cjwatson> np
[12:03] <cjwatson> Odd_Bloke: oh, since you're here, what's the word on powerpc cloud images?
[12:03] <cjwatson> have been meaning to catch you ...
[12:04] <Odd_Bloke> 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] <cjwatson> Odd_Bloke: Oh, I thought it already was in Launchpad
[12:05] <cjwatson> Odd_Bloke: You build ppc64el images today, don't you?
[12:05] <Odd_Bloke> cjwatson: Yeah, but we're building those on a POWER7 host which is going to be problematic post-wily.
[12:05] <cjwatson> Odd_Bloke: Sure; but a ppc64el host can run kvm for powerpc guests
[12:06] <cjwatson> Odd_Bloke: So this shouldn't be a blocker for doing powerpc images
[12:06] <doko> 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] <Odd_Bloke> 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] <ginggs> 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] <ricotz> doko, hi, I assume librevenge misses the version for conflicts/replaces against *v5
[12:07] <Odd_Bloke> And the ppc64el stuff is very hacky, so changing it to support powerpc is high risk.
[12:08] <cjwatson> 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] <Odd_Bloke> 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] <cjwatson> Odd_Bloke: I'm assuming you can lift a bunch of the control logic from cdimage
[12:09] <doko> ricotz, why?
[12:09] <Odd_Bloke> 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] <cjwatson> OK
[12:10] <Odd_Bloke> cjwatson: But getting this done is good on many, many levels, so it is definitely going to get done.
[12:11] <ricotz> doko, ah sorry, I meant libetonyek
[12:12] <doko> ricotz, version?
[12:14] <ricotz> Conflicts: libetonyek-0.1-1v5 (<< 0.1.3-1ubuntu3)
[12:14] <ricotz> (no need to provide a transitional package otherwise)
[12:15] <ricotz> like you already did with the other libs like wps
[12:22] <doko> wps has a transitional package
[12:23] <ogra_> 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] <ogra_> cjwatson, err http://paste.ubuntu.com/12337129/
[12:25] <ricotz> doko, yes, i know, and in libetonyek you forget the versions, try to install calligra-libs
[12:28] <cjwatson> ogra_: parted does that itself; you shouldn't need to.
[12:28] <ogra_> cool
[12:28] <ogra_> thanks
 ricotz, version?
[12:29] <ricotz> doko, what do you want to know? you uploaded this 2 hours ago
[12:30] <doko> ricotz, the version of libetonyek
[12:30] <ricotz> https://launchpad.net/ubuntu/+source/libetonyek/0.1.3-1ubuntu3
[12:33] <infinity> pitti: wolfe-02 is a bit segfaulty.
[12:33] <ricotz> doko, https://paste.debian.net/plain/311309
[12:35] <doko> ricotz, fix uploaded
[12:43] <pitti> infinity: oh? I don't seen anything unusual in dmesg
[12:49] <infinity> pitti: Well, the segv in the kernel test was definitely not a problem with the binary that segfaulted.
[12:49] <infinity> (I've retried it, hoping for another slave)
[12:52] <pitti> infinity: oh, for linux? I already retried that, but *shrug*
[12:52] <pitti> infinity: you figure rebooting the VM might help?
[12:52] <infinity> pitti: Yeah.
[12:53] <pitti> it's currently running linux-lts-utopic and ruby-libxml
[12:53] <pitti> I'll let at least the latter finish
[13:22] <pitti> 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] <doko> hmm, the libxml2 fix introduce some failures. maybe better revert back to 2.9.1 like Debian?
[13:26] <pitti> 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] <doko> ginggs, julia still has the b-d on openlibm?
[13:26] <doko> pitti, glib2.0 on ppc64el failed too after the upload
[13:27] <doko> otoh, publican now built
[13:27] <ginggs> doko, for now yes
[13:27] <pitti> 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] <doko> ok
[13:28] <pitti> will just take an hour or so to catch up, there's some queue
[13:55] <apw> pitti, erm i use .. err ... is that in the result.tar ... if so no
[13:55] <pitti> apw: no, it's not, it's in artifacts.tar.gz
[13:56] <apw> pitti, oh so this won't be in results this new info ?
[13:56] <apw> result.tar
[13:57] <pitti> apw: it will
[13:57] <apw> anyhow no i do not use artifacts at all
[13:57] <pitti> apw: 'cause you want/need it
[13:57] <pitti> and it's small
[14:12] <doko> jamespage, that's an interesting distribution format ;-P http://web.eecs.utk.edu/~plank/plank/papers/GF-Complete-Archive.pdf
[14:12] <jamespage> doko, indeed
[14:13] <jamespage> doko, it does have a new home - http://jerasure.org/
[14:13] <doko> jamespage, why not ship the current version?
[14:14] <doko> there is a 2.0 release
[14:15] <jamespage> doko, so you ping made my observer - let me take a look
[14:15] <doko> and add a watch file =)
[14:18] <elopio> pitti: sounds like a good idea.
[14:18] <elopio> we don't use it at all. I sometimes look at it.
[14:19] <mitya57> 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] <doko> mitya57, ta
[14:25] <LocutusOfBorg1> ginggs, http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=b3d9373289eab93f8ddf530549ee296003de8342
[14:25] <LocutusOfBorg1> :)
[14:25] <LocutusOfBorg1> thanks
[14:27] <ginggs> LocutusOfBorg1: no worries, but your changelog entry doesn't describe what you actually did
[14:29] <jamespage> 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] <jamespage> upstream in swift/liberasurecode that is
[14:33] <doko> jamespage, python-pyeclib looks ok, but the three library package could need some cleanup
[14:33] <jamespage> doko, ack
[14:34] <jamespage> doko, what about liberasurecode? I have done work directly on that package to knock it into shape
[14:34] <doko> liberasurecode:
[14:34] <doko>  - liberasurecode1 has a hard-coded dependency on a shared library, please remove
[14:34] <doko>  - there is a newer 1.0.9 release, update?
[14:34] <doko> please also fix:
[14:34] <doko>  - enable parallel build
[14:34] <doko>  - add Multi-Arch: same attributes
[14:34] <doko>  - library is underlinked, -ldl missing
[14:35] <doko> so minimum is to remove the hard coded library
[14:36] <jamespage> doko, its hard coded as its loaded as a plugin, not as a linked library
[14:36] <jamespage> (libjerasure2 I'm assuming)
[14:37] <doko> ohh
[14:38] <LocutusOfBorg1> ginggs, true
[14:40] <LocutusOfBorg1> updated
[14:40] <doko> jamespage, ok, makes sense
[14:42] <infinity> pitti: Wat?
[14:42] <infinity> autopkgtest for keystone 2:8.0.0~b2-0ubuntu2: armhf: Test in progress
[14:42] <infinity> pitti: Why did python-passlib only trigger keystone on armhf and no other arches?
[14:43] <pitti> infinity: you know, you have sooo many questions!
[14:43] <infinity> pitti: I KNOW!
[14:44] <pitti> infinity: filed as bug 1494786, for my Monday enjoyment
[14:44] <infinity> pitti: Oh, it might relate to there also being a new keystone.
[14:44] <infinity> pitti: Could just be a bit racy on the version mismatch?
[14:45] <pitti> yeah, I guess something like that
[14:45] <pitti> 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] <pitti> so it's not about keystone in particular I think
[14:53] <ginggs> LocutusOfBorg1: looks good :)
[15:06] <LocutusOfBorg1> thanks ^2
[15:23] <Riddell> 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] <mvo> Riddell: I can not thing of a reason why not, but I have not really followed that development that much recently
[15:32] <mvo> Riddell: I did the app-install-data update too
[15:33] <Riddell> mvo: yeah saw that thanks
[15:33] <mvo> yw
[15:33] <Riddell> mvo: I've got the updated packages here and it works for packagekit-qt, anything else I should test it with?
[15:35] <mvo> Riddell: not from my side
[15:35] <mvo> Riddell: maybe worth checking with Laney
[15:35] <Riddell> Laney: ping :)
[15:37] <Laney> Riddell: dunno, look at rdeps :)
[15:38] <infinity> mvo: Oh hey, you're around.
[15:39] <infinity> 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] <mvo> infinity: yes, early wily+1
[16:04] <mvo> infinity: it will go to unstable once there are less transitions
[16:08] <infinity> mvo: Excellent.  The sooner, the better, IMO.
[16:08] <mvo> yes!
[16:09] <fginther> pitti, nothing I look after uses summary
[16:09] <fginther> (which is just boottest)
[16:36] <alexbligh1> 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] <alexbligh1> ler? Or any clues on how to debug it?
[16:37] <alexbligh1> (for bonus points, it worked on 10.04 allegedly, but not 14.04)
[16:37] <cjwatson> should work the same way, I suggest getting DEBCONF_DEBUG=developer traces from both and comparing
[16:37] <cjwatson> generally the first step with any debconf problem
[16:40] <alexbligh1> cjwatson, thanks. What actually implements db_go? (as you can tell I know nothing about this!)
[16:40] <alexbligh1> (I mean on the CDROM installer)
[16:43] <cjwatson> alexbligh1: /usr/share/debconf/confmodule in either case
[16:44] <cjwatson> 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] <cjwatson> alexbligh1: in the case of ubiquity, ubiquity intercepts the debconf protocol and fiddles with it in some cases
[16:44] <cjwatson> so um it depends
[16:45] <cjwatson> but DEBCONF_DEBUG=developer is absolutely the first step, it may well just be a simple bug at the client end
[16:45] <alexbligh1> 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] <alexbligh1> 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] <cjwatson> alexbligh1: oh, that wasn't at all how I interpreted what you meant ...
[16:47] <cjwatson> alexbligh1: debconf in the former case, cdebconf in the latter, then
[16:47] <cjwatson> alexbligh1: that sounds like the backup capb isn't set
[16:47] <alexbligh1> cjwatson, how does one set the backup capability (assuming I'm translating that right)?
[16:48] <cjwatson> alexbligh1: db_capb backup
[16:48] <alexbligh1> cjwatson, (the button appears, it just doesn't work)
[16:48] <cjwatson> alexbligh1: ok, if the button appears, the capb is likely set
[16:49] <alexbligh1> 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] <cjwatson> alexbligh1: so let's see a debug trace
[16:49] <cjwatson> much quicker than guessing
[16:50] <alexbligh1> 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] <alexbligh1> cjwatson, thanks anyway
[16:50] <cjwatson> alexbligh1: go back definitely works in d-i, we use it in many places
[16:51] <cjwatson> inc. from shell, not that it makes a difference, same protocol either way
[16:51] <alexbligh1> 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] <cjwatson> alexbligh1: localechooser for instance, very first stage of the installer, written in shell
[16:52] <alexbligh1> cjwatson, apparently it only breaks if you ask more than one question in each stage or something. Debug trace needed anyway.
[16:52] <alexbligh1> cjwatson, ok, I will point him at that.
[16:52] <alexbligh1> cjwatson, thanks
[16:52] <cjwatson> alexbligh1: cdebconf doesn't support grouping, perhaps that's the problem.  you must ask one question per stage
[16:52] <alexbligh1> cjwatson, AAAAAHHHH! well that would be exactly the issue.
[16:53] <cjwatson> the beginblock/endblock stuff will not work with cdebconf
[16:53] <alexbligh1> 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] <cjwatson> (it's only a stub with debconf too; but perhaps the fallback mode is different)
[16:54] <cjwatson> yeah
[16:54] <cjwatson> np
[18:55] <mterry> doko!
[18:55] <mterry> knock it off with these perl pkgs  :)
[18:55] <doko> ;)
[18:55] <mterry> I'll get this one, no prob
[18:56] <doko> should be the last ones for this cycle, promised!