[00:09] <brendand> xnox, well if you're interested the pypi package is 'lp-helpers'
[00:09] <brendand> lp-clean-branches is the command
[00:18] <xnox> brendand: propose it to ubuntu-dev-tools =) it already does launchpad-api caching and has a few nifty launchpad utilities =)
[01:01] <xnox> doko: can you look into libffi/powerpc ftbfs missing symbols https://launchpadlibrarian.net/157846875/buildlog_ubuntu-trusty-powerpc.libffi_3.0.13-9_FAILEDTOBUILD.txt.gz
[01:56] <infinity> xnox: Fixing.
[01:56] <xnox> infinity: thanks.
[04:49] <slangasek> @pilot out
[07:10] <Mirv> congrats everyone involved for completed libav9 + evolution 3.10 migrations
[07:23] <pitti> Good morning
[07:33] <pitti> infinity, xnox: so, infinity's forcing of git-annex and xnox's bug 1256143 will now fight each other? :-)
[07:33] <pitti> (seems xnox wins)
[07:34] <infinity> pitti: I was allowing the test to be skipped so OTHER packages could migrate, while the bug holds git-annex itself in proposed.
[07:34] <pitti> infinity: aah, that explains how libffi and python2.7 could make it in, thanks! clever
[07:58] <dholbach> good morning
[08:17] <pitti> didrocks: bonjour ! ça va ?
[08:19] <pitti> didrocks: would you have an idea why autopilot-gtk isn't autolanding? this blocks our installer tests
[08:24] <pitti> didrocks: ah, jibel told me that it's manual; so, "I can haz landing, please?"
[08:24] <didrocks> pitti: I just finished adding a slot for you :)
[08:24] <pitti> didrocks: why is that? it's not used on the phone
[08:24] <pitti> didrocks: merci
[08:24] <didrocks> pitti: cu2d has a stack granularity
[08:24] <didrocks> it wasn't done for putting things manual forever
[08:24] <pitti> ah, ok
[08:24] <didrocks> not what management decided
[08:25] <pitti> leftover from the autopilot 1.3 -> 1.4 transition?
[08:25] <pitti> (the manual flag)
[08:25] <didrocks> pitti: oh no, everything is manual as long as I can see
[08:25] <didrocks> (as long as we don't have CI Airline I guess)
[08:25] <pitti> ah
[08:25] <didrocks> s/long/far/
[08:26] <pitti> didrocks: so I guess/hope the intention is that it should be automatic, but every new autopilot landing should make sure that e. g. the unity test (and some selected others) would still succeed with it?
[08:27] <didrocks> pitti: right, unfortunately, we still can't run tests automatically on the phone when releasing a stack
[08:27] <didrocks> (the infra isn't thre)
[08:27] <didrocks> we can just run them on the desktop
[08:27] <didrocks> there*
[08:27] <pitti> didrocks: right, I understand; i. e. that's the intention, but limited by hw
[08:27] <didrocks> pitti: my intention is that it's automatic, I'm not that sure it's the management intention though
[08:27] <pitti> didrocks: oh, do the unity8 tests run on desktop? (they certainly should at some point)
[08:27] <didrocks> pitti: they do
[08:28] <didrocks> (in an unity7 session)
[08:28] <pitti> didrocks: so, that would already cover API/behavioural changes in AP
[08:28] <pitti> liek the 1.3 -> 1.4 transition
[08:28] <didrocks> yeah, but not all apps are running on desktop
[08:28] <didrocks> some tests are disabled
[08:28] <didrocks> and that's the difference between the otto tests always green
[08:28] <didrocks> and the dashboard results, not that green
[08:29] <pitti> didrocks: right, it'd probably be too expensive to run *all* our tests against new AP versions; we shoudl select some important/large ones (like unity and unity8)
[08:29] <didrocks> pitti: it's not enough, knowing the propention from AP to break only for *some* apps, and not always the same…
[08:29] <pitti> didrocks: anyway, thanks for the CI bike trip :)
[08:29] <didrocks> I guess the emulator will help :)
[08:30] <pitti> oh, right
[08:30] <didrocks> pitti: no worry, should be released today!
[08:30] <pitti> didrocks: bike > plane! :-)
[08:30] <didrocks> pitti: sil2100 will be your guide for this bike ride then! :-)
[08:31]  * pitti rings his bell on the handlebar
[08:33] <didrocks> heh
[08:56] <tsdgeos> twinkle was rebuilt
[08:56] <tsdgeos> and now i can't use it anymore since the qt3 frontend is gone :-7
[08:57]  * tsdgeos looks for the old package
[08:58] <tsdgeos> better
[09:02] <tsdgeos> now if i could tell apt not to update that package...
[09:02] <tsdgeos> :/
[09:02] <tsdgeos> oh you can
[09:19]  * infinity watches memory corruption spiral his latest glibc test build into a pit of doom and gives up for the night.
[09:22] <pitti> doko_, jibel: I can reproduce the "UUIDs not unique" failure with while python3 /usr/lib/python3.3/test/test_uuid.py; do true; done (in our test VMs)
[09:23] <pitti> doko_, jibel: I now ran the python2.7 and 3.3 tests four times each, plus this loop, with haveged installed, and I didn't get any failure (loop has run for several minutes now)
[09:23] <jibel> pitti, with a real random genetor or the faked one?
[09:23] <jibel> +ra
[09:23] <pitti> jibel: without haveged it's the real /dev/random, but our test VMs have rather little real entropy
[09:24] <pitti> and then we don't really need really true randomness for our tests, do we?
[09:24] <jibel> pitti, no we don't
[09:24] <pitti> so ISTM that installing haveged should be ok
[09:24] <jibel> agreed
[09:24] <jibel> as long as it doesn't block autopkgtest on gpg key generation
[09:25] <pitti> jibel: no; if anything it should make it faster
[09:25] <pitti> I ran the complete run-adt-test -sU python2.7 (and 3.3) several times
[09:26] <pitti> jibel: http://paste.ubuntu.com/6493239/
[09:26] <pitti> doko_: so in a way this is an actual flaw in the uuid module; it should block on getting entropy instead of creating identical ones
[09:27] <pitti> but it uses uuid1() which is primarily time based (and our VMs probably don't have nanosecond resolution)
[09:27] <pitti> so both of these together are probably rather rare
[09:27] <pitti> jibel: ok to roll this out?
[09:28] <jibel> pitti, you also need to remove then "dev/random" in bin/testbed/run-adt
[09:28] <pitti> jibel: no no, haveged writes entropy into /dev/random
[09:29] <pitti> it watches /proc/sys/kernel/random/entropy_avail for a low water mark, and if it's running low, it calculates pseudo-random numbers and writes them into the pool
[09:29] <jibel> pitti, ah okay. that's good.
[09:30] <pitti> jibel: committed
[09:30] <jibel> pitti, thanks, I'll deploy and reprovisions VMs
[09:31] <pitti> jibel: deploy is fine, I think; they'll reprovision tomorrow anyway, don't they? (that seems enough)
[09:31] <jibel> pitti, yes on saturday when nobody pays attention :)
[09:31] <tseliot> pitti: is it ok if I upload a package in main that depends on a package in universe before the MIR (bug #1255583) is approved? Or shall I wait?
[09:33] <infinity> tseliot: It's best to wait.
[09:34] <tseliot> infinity: ok, I will, thanks
[09:34] <infinity> tseliot: Of course, if you upload now, it'll show up on component-mismatches, and we'll bug people about it breaking the archive. :P
[09:35] <tseliot> infinity: and would that motivate the mir approval team? ;)
[09:35] <infinity> tseliot: Not necessarily. :P
[09:35] <tseliot> heh
[09:37] <infinity> sarnold: When you have a chance, a security audit on #1255583 would be nice.  Kernel module needed by non-free crap.  Totally not scary AT ALL.
[09:39] <tseliot> :)
[09:55] <Saviq> xnox, hey, I saw dpkg-cross is depended on by cross-essentials in the end? do I still need to pass the CMAKE_TOOLCHAIN then, or does debhelper do it already?
[09:55] <Saviq> xnox, also, I still had to pass PKG_CONFIG_EXECUTABLE there
[09:57] <xnox> dependency means, that one doesn't have to declare dependency on dpkg-cross i think.
[09:58] <xnox> passing variables is still needed, as there haven't been any changes on debhelper side yet.
[09:58] <xnox> (well there is new debhelper release in debian that needs merging)
[10:03] <seb128> pitti, hey, do you have the rights to mark https://code.launchpad.net/~vrruiz/ubuntu-system-settings/autopilot/+merge/189194 as rejected? or supersed or something
[10:03] <seb128> pitti, the target vcs is wrong and it has been superseded by https://code.launchpad.net/~vrruiz/ubuntu-system-settings/autopilot/+merge/192869
[10:04] <pitti> (in meeting)
[10:48] <rbasak> We have an Ubuntu delta for puppet that is no longer required because a dependency has been fixed. But I (presume I) can't sync it because it would involving the version number going down. Any options here, other than to wait for a newer Debian release?
[10:56] <pitti> seb128: rejected
[10:57] <seb128> pitti, danke
[10:58] <Laney> rbasak: Just that - you can drop it with the next Debian upload
[13:08] <mpt> ev, did you ever get hold of a stethoscope icon for use in <https://wiki.ubuntu.com/ErrorTracker#metrics>?
[13:08] <mpt> (or similar diagnostics-y icon)
[13:19] <Cimi> seb128, https://code.launchpad.net/~larsu/overlay-scrollbar/fix-for-3.10/+merge/196920
[13:19] <Cimi> seb128, it has a regression for gtk2 at least
[13:19] <Cimi> seb128, and I have a couple of questions
[13:19] <seb128> Cimi, how so? I'm using it for some days with gtk2 without issue
[13:20] <seb128> Cimi, can you come on #ubuntu-desktop, larsu is not on this channel
[13:20] <Cimi> seb128, open inkscape
[13:20] <Cimi> seb128, unfocus
[13:21] <Cimi> seb128, click on one of its scrollbars
[13:21] <seb128> Cimi, on a channel where larsu is please, he wrote the changes
[13:21] <Cimi> seb128, inkscape doesn't raise
[13:21] <Cimi> seb128, I commented on the MR
[13:21] <Cimi> but yeah
[13:47] <mpt> ev, I reported bug 1256308 about it, so please invalidate it if we have the icon after all. :-)
[14:08] <Saviq> mpt, hey, seb128 pointed me at you - that you'd be the one to know about any docs describing errors.u.c from a consumer perspective
[14:09] <mpt> Saviq, there are none that I know of.
[14:09] <Saviq> mpt, ok thanks
[14:52] <ev> mpt: apols, was on the phone. We don't have an icon so the bug is entirely valid
[14:54] <doko> slangasek, your freetype upload breaks the gcc build
[14:55] <doko> fatal error: freetype/ftglyph.h: No such file or directory
[14:55] <doko>  #include <freetype/ftglyph.h>
[14:55] <doko>                               ^
[14:55] <doko> compilation terminated.
[14:57] <mhr3> hey guys, we have a problem building unity8 in a ppa
[14:57] <mhr3> see https://code.launchpad.net/~ubuntu-unity/+archive/daily-build-next/+recipebuild/596169
[14:57] <mhr3> for trusty
[14:59] <seb128> hum, weird build log with pbuilder
[14:59] <seb128> I guess the arm64 buildds are maybe special?
[14:59] <seb128> not sure about the specific issue, maybe doko or cjwatson can help you...
[15:01] <cjwatson> doko: You need to use #include <ft2build.h> #include FT_GLYPH_H instead - this was always documented as the proper approach, but FreeType 2.5.1 rearranged the headers
[15:01] <cjwatson> doko: (I just ran into this in GRUB too, and fixed it upstream)
[15:02] <cjwatson> seb128: That's not an arm64 buildd
[15:02] <cjwatson> And they aren't that special
[15:02] <seb128> shrug, I can't read
[15:02] <seb128> cjwatson, sorry, friday afternoon :/
[15:03] <cjwatson> Perhaps libprocps0 being removed points to a way to investigate?
[15:04] <cjwatson> I'd like to migrate that to something more like the apt resolver
[15:04] <cjwatson> In sbuild
[15:08] <doko> cjwatson, which freetype version did introduce these macros?
[15:08] <cjwatson> doko: prehistoric AFAICT
[15:08] <doko> ok
[15:09] <cjwatson> Let me get you an accurate answer
[15:12] <cjwatson> doko: First mention is commit 8fba32d2d6f284bfd49ed6c0557880e0bb692f49, 2000-11-30, contained in 2.0.1
[15:13] <doko> thanks!
[15:13] <cjwatson> doko: http://www.freetype.org/freetype2/docs/tutorial/step1.html was the documentation I found on how includes are supposed to be done
[15:49] <saiarcot895> If a project wants to take another library they are using and strip it down to get rid of other dependencies and edit some of the code in said library, is that allowed?
[15:50] <mhr3> got another one
[15:50] <mhr3> https://launchpadlibrarian.net/157891212/buildlog.txt.gz
[15:50] <mhr3> any idea what's up with that?
[15:51] <cjwatson> mhr3: It *might* be that the chroots need to be refreshed to contain libprocps1 rather than libprocps0
[15:51] <cjwatson> infinity: ^-
[15:52] <mhr3> cjwatson, actually, might be something with qt
[15:52] <cjwatson> I suspect pbuilder-satisfydepends gets upset when it has to remove anything
[15:52] <cjwatson> mhr3: I don't think so
[15:52] <mhr3> the ones that are failing for me have deps on qt5-default
[15:52] <cjwatson> And in this case, in order to install up-to-date packages, it has to remove libprocps0 (which is obsolete and has been removed anyway, but it's still in the chroot)
[15:59] <cjwatson> mhr3: That might just happen to require a newer procps for some boring reason
[15:59] <cjwatson> Or maybe aptitude tries to upgrade everything
[15:59] <cjwatson> The log would rather suggest that
[15:59]  * cjwatson attempts to reproduce it starting with a saucy chroot
[16:36] <infinity> cjwatson: I can refresh the chroots, yeah.  It's entirely possible that removals aren't allowed in that scenario.
[16:37] <infinity> (Though, what is forcing libprocps0 off the system, that seems somewhat unfriendly...)
[16:41] <cjwatson> I wonder if that's aptitude deciding that it's obsolete all by itself
[16:41] <cjwatson> pbuilder-satisfydepends-aptitude runs aptitude with some quite exciting options
[16:41] <cjwatson> It could just be Wrong
[16:42] <infinity> I've considered adding a --purge autoremove run to slavebin/update-chroot post-upgrade, too.
[16:42] <infinity> But, in practice, a bit of cruft in a chroot before I get around to manually refreshing them has never really been an issue.
[16:42] <infinity> Until today, apparently. :P
[16:42] <infinity> But, they need a refresh anyway, they're a month old or so.  So, I'll do that today.
[16:43] <infinity> And if you decide there's a pbuild-whatever bug there too, that can happen at its own pace.
[16:46] <cjwatson> I can't reproduce it here with plain aptitude, but I think I've lost the will to care.  A chroot refresh will probably sort it out.
[16:47] <cjwatson> But I do have a good mind to rip pbuilder out of buildrecipe.
[17:05] <saiarcot895> If a project wants to take another library they are using and strip it down to get rid of other dependencies and edit some of the code in said library, is that allowed?
[17:07] <cjwatson> saiarcot895: Sounds highly dubious
[17:07] <cjwatson> I can't claim it's totally unheard of, but it would have to have a very good excuse, IMO
[17:08] <brendand> saiarcot895, would depend on licences too
[17:09] <xnox> it has been done in very specilised cases, e.g. library compiled for udeb (to be used in installer), can be  compiled with less options/dependencies. but by default the policy is to enable all options in all libraries.
[17:09] <xnox> and typically one uses the full library.
[17:10] <saiarcot895> I think the licensing works (GPL and LGPL?), but they are saying that there are a few problems in their use case (not refreshing, pagination, and some features missing)
[17:10] <saiarcot895> this is in regards to the marble library
[17:10] <xnox> saiarcot895: is this a packaging question for Ubuntu, or is it just something  you want to do as an external project?
[17:10] <saiarcot895> xnox: It's for a PPA, but I would like to follow Ubuntu packaging policies
[17:11] <cjwatson> xnox: that's not done by code copying, though, library udebs are still built out of the same source
[17:11] <xnox> saiarcot895: as long as you change the name of the library package & use a different soname/library name without conflicting with the in-archive marble you should be ok.
[17:11] <saiarcot895> xnox: also, I think they want to remove KDE code that they are not using at all
[17:12] <cjwatson> usually "there are a few problems" is an excuse for not wanting to put the effort in to consolidate things ...
[17:12] <saiarcot895> true, that will have to be done
[17:13] <cjwatson> "consolidate" as in contribute their changes to the upstream library
[17:13] <xnox> saiarcot895: it's best if they send patches to marble upstream. If the library is good, general fixes apply to all of it, and if they want to loosen dependencies, that would be possible as well (e.g. split the library into "core" and "kde" etc.)
[17:15] <saiarcot895> xnox: I just looked at marble's build instructions, and supposedly, they have an option to build with only Qt. Interesting.
[17:16] <shadeslayer_> saiarcot895: that is try
[17:16] <shadeslayer_> *true
[17:16] <shadeslayer_> saiarcot895: and afaict libmarble17 only depends on Qt stuff
[17:18] <saiarcot895> shadeslayer_: I think there is a separate marble package that depends on KDE
[17:19] <shadeslayer_> saiarcot895: true, that's called marble, and then there's marble-qt which is Qt only
[17:19] <shadeslayer_> or is supposed to be Qt only
[17:19] <shadeslayer_> the lib itself seems Qt only?
[17:20] <saiarcot895> shadeslayer_: libmarblewidget16 is Qt only, marble-qt is Qt only, and marble is KDE
[17:20] <shadeslayer_> saiarcot895: correct
[17:20] <saiarcot895> *KDE and Qt
[17:20] <shadeslayer_> and the so name was bumped so it's libmarblewidget17 now
[17:21] <shadeslayer_> but that's only in trusty , so disregard that ^^ :P
[17:22] <shadeslayer_> saiarcot895: regarding missing features, you're free to implement them, but it's usually best to communicate this with upstream
[17:22] <saiarcot895> shadeslayer_: true
[17:23] <shadeslayer_> there's also https://git.reviewboard.kde.org/dashboard/ to post your patches for KDE :)