[02:50] <xnox> @pilot in
[03:04] <YokoZar> slangasek: pitti: kees: infinity: stgraber: mdeslaur: congrats
[03:04] <YokoZar> lool: bdrung_: SpamapS: mterry: sorry :)
[03:04] <YokoZar> ^^^ Tech board election results
[03:06] <mdeslaur> YokoZar: thanks!
[03:06] <darkxst> xnox, could you take a look at gsettings-desktop-schemas and gnome-themes-standard during your shift?
[03:08] <xnox> darkxst: i don't usually do any DE/gnome/desktop things, unless i really know that it doesn't have negative effects across all flavours. Somebody more clued on those components would be better to review/merge those. E.g. Laney / seb128
[03:09] <xnox> darkxst: althought gsettings-desktop-schemas looks reasonable.
[03:18] <darkxst> xnox, gnome-themes-standard just has a handful of minor gtk fixes in the highcontrast theme (which all the other flavors use)
[03:20] <darkxst> and it fixes alot of theming issues in Adwaita
[03:20] <darkxst> but anyway will check with Laney or seb128
[03:21] <xnox> darkxst: looking into gnome-themes-standard, i wonder what the lock screen changes are. (background keys?!)
[03:25] <darkxst> xnox, not sure what changes you mean, however the lock screen is gnome-shell only
[03:27] <xnox> darkxst: right. will test the package more and then upload.
[03:27] <darkxst> thanks
[04:39] <xnox> @pilot out
[04:39] <xnox> @pilot out
[04:58] <Apteryx> Hi there. Could someone tell me what is the general user case of the bluetooth applet operation?
[05:00] <Apteryx> If I turn bluetooth off from the applet, the icon disappears and the interface goes down. Good. "service bluetooth status" reports that it is still running.
[05:00] <Apteryx> Now what I am suppose to do to bring it back ON?
[05:01] <Apteryx> I guess the designed way is to go to "Settings -> Bluetooth" and there turn the swith ON.
[05:01] <Apteryx> The switch turns ON, but the interface stays down in my case, as reported by hciconfig.
[05:02] <Apteryx> Is this hardware specific? My bluetooth interface is provided by the Atheros AR3011 chip.
[05:46] <SpamapS> YokoZar: hah, thanks for the consolation. Though I'm not on the TB, I think the results came out _wonderfully_. :)
[05:46] <SpamapS> Truth be told I'm a bit relieved. It is a big responsibility.
[05:47] <YokoZar> SpamapS: If you want to stage a coup, let me know.
[06:14] <slangasek> YokoZar: thanks!  is there any more official announcement of this? :)
[06:15] <YokoZar> slangasek: Usually pleia2 puts out something on the Fridge and such, I imagine she'll do that tomorrow after the CC meeting
[06:15] <slangasek> ok
[06:34] <stgraber> YokoZar: thanks!
[07:16] <darkxst> Logan_, was there some reason why you disabled JS support in mediatomb?
[12:54] <caribou> xnox: you have marked the merge of backuppc as "please take"
[12:55] <caribou> xnox: I'd like to get some more merge experience, could it be a good idea for me to work on this one ,
[12:55] <caribou> ?
[12:57] <xnox> caribou: sure, although Logan_ was the last one to merge it "properly". I'll certainly can review your work for correctness.
[12:57] <caribou> xnox: I'll check with Logan_ first, in case he's started to work on it
[13:29] <caribou> xnox: how about the php5 one ?
[13:29] <caribou> xnox: looking at it, mostly done
[13:30] <xnox> caribou: it's non-trivial. I giving up some of the merges, because i don't feel comfortable merging them.
[13:31] <caribou> xnox: ah, ok I see
[13:31] <xnox> caribou: if you are looking into something to do really good things (and easy) to fix are http://qa.ubuntuwire.com/ftbfs/ppc64el.html and http://qa.ubuntuwire.com/ftbfs/arm64.html
[13:31] <xnox> caribou: typically it needs enabling dh-autoreconf (and sometimes dh-autotools-dev), such that config.guess/.sub and libtoolize are updated during builds.
[13:32] <caribou> xnox: ok, I'll look at it
[13:34] <caribou> xnox: is there an "easy" way to test those builds locally (i.e. w/o having some ARM H/W) ? Can sbuild do that ?
[13:37] <rbasak> caribou: https://www.stgraber.org/2012/02/03/ever-wanted-an-armel-or-armhf-container-on-an-x86-machine-its-now-possible-with-lxc-in-ubuntu-precise/ might work for you
[13:37] <caribou> rbasak: thanks, will try that
[13:37] <rbasak> I've never tried it with sbuild though :)
[13:37] <rbasak> However, for sbuild, it might be possible to just use qemu-user-static actually.
[13:37] <xnox> caribou: well, those fixes are needed on arm64/ppc64el for which emulators might not be stable (or exist) or be slow.
[13:38] <rbasak> I imagine you can set up a chroot with qemu-user-static installed, and then everything should just work. But I'm not sure if mk-sbuild can do that for youj.
[13:39] <xnox> caribou: in practice, it trains trianging the type of build failure and fixing it. E.g. if configure says that it can't determine system machine time, then config.guess/.sub need updating (preffered with dh-autoreconf, dh-autootools-dev if doesn't work)
[13:39] <rbasak> Not sure of qemu status with ppc64el. AFAIK qemu-user-static for powerpc is pretty broken.
[13:39] <xnox> caribou: and check locally that during build, config.guess timestamps are updated =) and all of them.
[13:39] <xnox> caribou: and e.g. grep for the arm64/ppc64el gnu triplets in the update config.guess/.sub.
[13:41] <xnox> caribou: for ppc64el, one often needs dh-autoreconf to update libtool, as otherwise the build log will have "libtool supports shared libraries... no" or some such and weird build error at the end with "dh_install can't find *.so" or static linking of some binaries fails.... because well it wasn't detected correctly that shared linking is available and is the only one support.
[13:42] <caribou> xnox: still, as for ftbs on amd64/i386 I need to be able to test the build locally
[13:42] <caribou> xnox: I've done a few of those already, but never on arch other than amd64/i386
[13:56] <xnox> caribou: sure, but the links i gave you, most of the packages do build correctly on i386/amd64/armh/powerpc. It's just the new ports that need enablement.
[13:57] <xnox> caribou: and it's better to have a FTBFS with a real arch-specific bug, instead of the "config.guess is out of date, abort"
[13:58] <caribou> xnox: true, but I still need to be able to test the build to find out, isn't it ?
[13:58] <caribou> xnox: at least test the fix
[14:01] <xnox> caribou: well sure, you need to make sure that the package still builds after autoreconf is enabled, and verify that config.guess/sub is updated, and libtoolize is executed (if applicable)
[15:26] <sconklin> @pilot in
[15:41] <shadeslayer> is there any news on a bluez5 migration?
[15:49] <infinity> shadeslayer: Which news were you hoping for?
[15:51] <shadeslayer> Any blueprints or any ongoing work to package Bluez5?
[15:51] <infinity> It's been packaged in Debian experimental, though no activity there since May.
[15:51] <infinity> No idea if anyone's dicussed and/or committed to doing the work in Ubuntu.
[15:52] <shadeslayer> well, on the KDE side, the powerdevil 1.x series will be EOL soon
[15:52] <shadeslayer> and only the 2.x series will be supported
[15:52] <shadeslayer> which in turn depends on Bluez5
[15:53] <infinity> Sure.  I suspect some effort needs to be put in to testing (and possibly porting) all the rdeps.
[15:56] <mitya57> doko: What should be done in qtchooser re bug 1209239?
[15:57] <shadeslayer> infinity: only 46 reverse deps ... right :D
[15:57] <caribou> following my previous discussion with xnox, does someone have a suggestion on how to setup an environment to test builds on arm64/ppc64el ?
[15:58] <infinity> caribou: For arm64, you could try https://wiki.debian.org/Arm64Qemu
[15:59] <infinity> caribou: But most of the bugs people need to fix (config.{sub,guess} updates and libtool macro updates) can be easily tested for correctness on any arch.
[15:59] <xnox> mitya57: that's rather for me, rather than doko. qtchooser demands & searching for native arch qt installation, instead of guessing / using native tools without a full native qt installation.
[16:00] <infinity> caribou: Sure, the build *might* fail later for other unrelated reasons, but history has shown that's only likely in about 1/100 such uploads.
[16:00] <xnox> mitya57: e.g. the dreaded "can't find qt installation" should be resolved, such that it always finds native qt-tools, even though native qtbase-dev is not installed.
[16:00] <caribou> infinity: ok, thanks I'll look at that
[16:00] <caribou> infinity: I already found apw's blog post on using ARM64 Foundation mode
[16:01] <infinity> caribou: The Foundation Model is certainly going to give you the most correct results.  But it's sloooooow.
[16:01] <caribou> infinity: yeah, I noticed that already
[16:02] <infinity> caribou: But, honestly, for most of these uploads, you shouldn't need to build on the tagret hardware to know that what you're fixing is correct.
[16:02] <infinity> caribou: If you do need to build on target hardware to see the fix in action, there's a fair chance you don't understand the fix.
[16:02] <caribou> infinity: that could happen as well ;-)
[16:02] <infinity> (Again, discounting the 1% of the time when things need actual porting)
[16:03] <caribou> infinity: but then, if the FTBS is not arch specific, it should fail on the other arm builds as well
[16:04] <rbasak> I've never felt confident uploading without doing at least a build test to check a fix. It's a way of checking my own work.
[16:04] <infinity> rbasak: I always build-test on *some* arch. :)
[16:05] <mitya57> xnox: Right, thanks. I think opening a bug upstream makes sense.
[16:05] <rbasak> If it's an arch-specific issue, I check two arches.
[16:05] <infinity> But for autotools type updates, I'm happy to build-test on x86, and spot-check that the update machinery did what I wanted.
[16:05] <mitya57> (does qtchooser have a bugtracker???)
[16:05] <rbasak> I guess I'm not confident enough with autotools for that.
[16:06] <infinity> rbasak: Well, that goes back to "understanding the fix". :)
[16:06] <rbasak> I think there's a difference between thinking I understand the fix, and knowing that I understand the fix.
[16:06] <infinity> rbasak: If you're not confident with the autogenerated code, I'm not sure how "it accidentally worked on two arches" is any better than "it accidentally worked on one".
[16:08] <caribou> infinity: rbasak: which goes back to my assertion that if it's not arch specific, it should ftbs on more than one arch build
[16:08] <xnox> mitya57: yeah, i was going to get to that soon. But am busy with touch-emulator work at the moment.
[16:08] <infinity> caribou: Sure, but you're trying to fix arch-specific issues here.
[16:09] <caribou> infinity: simply because xnox pointed be to a bunch of ftbs on amd64 qa page
[16:09] <caribou> s/be/me
[16:10] <xnox> caribou: well i pointed to both ppc64el, arm64. And I has _explicit_ that you do _not_ need to test build on arm64/ppc64el.
[16:10] <infinity> Not for autotools mangling, anyway.
[16:10] <infinity> Not if, like I said, you understand the fix and how to spot-check that it's correct.
[16:10] <caribou> xnox: yeah, I got that as well, but then when I looked at some failures, they did not relate to what you described
[16:10] <caribou> xnox: so I got further in the arm64 specific builds
[16:10] <xnox> caribou: note, that a test build on amd64 is sufficient as long as you verify that: you are fixing config.guess/libtool issues, and that package does update config.guess/libtoolize correctly during any build (e.g. amd64 is sufficent)
[16:11] <xnox> caribou: step one was to find those that are that issue =) most of them are in the universe section ;-)
[16:11] <infinity> caribou: There are, of course, a hundred or so failures on x86 too, you could look at those. :P
[16:11] <xnox> caribou: main is mostly fixed now.
[16:11] <caribou> infinity: that's what I did last week :)
[16:11] <xnox> caribou: and there is more chance on the ppc64el page ;-)
[16:12] <caribou> xnox: infinity: bottom line is : many of those are good ground for me to learn tons of things
[17:10] <rbasak> xnox, mdeslaur: FYI, I'm planning on merging apache2 and php5 this week.
[17:10] <rbasak> Any objections?
[17:14] <xnox> rbasak: yes please. =) you know how to test all of that stuff properly.
[17:16] <rbasak> xnox: indeed. I run the dep8 tests I wrote :-P
[17:17] <rbasak> I think there are a bunch of bugs that can be trivially fixed with a merge, too, which I'll sort out at the same time.
[18:07] <mdeslaur> rbasak: no objections from me!
[18:07] <mdeslaur> :)
[18:15] <xnox> rbasak: omg, you have Technical Board member blessing for that work. You are totally invincible now ;-)
[18:23] <mitya57> Can anybody please upload a python-apt rebuild (for python3.4)?
[18:24] <mitya57> (Builds fine in a PPA)
[19:22] <Laney> tkamppeter: your poppler uploads broke ABI
[19:22] <Laney> xpdf is busted now
[19:22] <Laney> & evince
[19:23] <tkamppeter> Laney, in which point did they break ABI, perhaps I can get fixed patches.
[19:23] <Laney> ubuntu5 it seems
[19:23] <Laney> PSOutputDev::PSOutputDev(char const*, PDFDoc*, char*, int, int, PSOutMode, int, int, bool, bool, int, int, int, int, bool, bool, GooString* (*)(PSOutputDev*, PSOutCustomCodeLocation, int, void*), void*)
[19:24] <infinity> Quite, yes.
[19:24] <infinity> tkamppeter: As a general rule, a patch that changes a function prototype is going to break ABI...
[19:24] <infinity> Were these backports from a new upstream version?
[19:25] <infinity> Perhaps we just want the new upstream and an SOVER/ABI transition.
[19:25] <tkamppeter> Laney, I will ask upstream whether one can do it without breaking ABI. The patches are from upstream. It is https://bugs.freedesktop.org/show_bug.cgi?id=72312.
[19:26] <infinity> Note that if you back out the ABI breakage, you'll also have to rebuild anything that build agaist the library post-breakage.
[19:27] <infinity> If we don't plan to take a new poppler soon, you should really just back out those patches *now* before the ABI break leaks any further.
[19:27] <infinity> And then sort out how to fix it differently.
[19:28] <infinity> tkamppeter: ^
[19:28] <Laney> The changes aren't even committed upstream yet
[19:28] <Laney> AFAICS
[19:29] <infinity> Yeah, then definitely please back them out.
[19:30] <infinity> And then hunt for rdeps that were built against the new ABI, so we can rebuild them.
[19:31] <tkamppeter> Laney, infinity, I have informed upstream now asking them to find a solution without ABI change. I will step back to the state before these upstream changes.
[19:31] <infinity> tkamppeter: For upstream, an ABI break is fine.  They break ABI in poppler constantly.
[19:31] <infinity> tkamppeter: But we *can't* backport that to our current package, that's all.
[19:32] <infinity> Oh crap.
[19:33] <infinity> Everything that depends on poppler in ppc64el is probably broken.
[19:33] <infinity> Oh, I guess it's not that many things anyway.
[19:34] <infinity> But yeah, we might have to rebuild all of poppler's rdeps after you fix it, just to be on the safe side.
[19:34] <infinity> I'll look at that more closely when I get back from lunch.
[19:50] <mitya57> We may want poppler 0.24.5 or 0.25 (both have different abis from 0.24.4)
[19:50] <mitya57> There is a bug somewhere with my debdiff for 0.24.4->0.24.5 attached
[19:58] <Laney> you mean .3 -> .4 I guess
[19:59] <mitya57> Err, yes, of course
[19:59]  * mitya57 puts the time machine back
[20:01] <mitya57> And, actually, the tkamppeter's change and .3->.4 changes are unrelated :(
[20:03] <Laney> yeah, that's what we observed just now
[20:04] <Laney> Maybe they could be cherry-picked to the 0.24 series once committed to 0.25 for .5 which we could take, or something.
[20:05]  * mitya57 needs some sleep, will be able to help with poppler tomorrow
[20:06] <mitya57> (I am also in process of forwarding our changes to Debian)
[21:25] <tkamppeter> infinity, Laney, I have now uploaded poppler -0ubuntu12, reverting to my patches which I have created to fix the bugs and proposed upstream. They do not have any ABI changes.
[22:04] <infinity> doko: Bah, syncing Debian's differently multi-arched tk/tcl broke upgrades.
[22:06] <doko> infinity, in which way?
[22:07] <infinity> doko: 8.6 needs the same fix you applied to 8.5
[22:08] <doko> ahh, you mean the replaces for tcl-lib?
[22:08] <infinity> doko: I'll do it right now, unless you want to be TIL on tcl/tk
[22:08] <infinity> doko: Yeah.
[22:08] <doko> no, please go ahead
[22:08] <doko> looking at the ruby2.0 ftbfs now ...
[22:47] <doko> https://launchpadlibrarian.net/161446482/buildlog_ubuntu-trusty-amd64.ruby2.0_2.0.0.353-1build1_FAILEDTOBUILD.txt.gz
[22:47] <doko> infinity, ^^^ tries to link -lieee twice, and then complaining about a duplicate symbol from the same library?
[22:51] <infinity> doko: Works on ARM and PPC, time to ditch x86 from the archive.
[22:53] <doko> infinity, fails on armhf too, looks like glibc complains
[22:54] <doko> ahh, no, it's the test_gc testcase
[22:54] <infinity> doko: Why is it linking that statically at all?
[22:55] <infinity> doko: The previous build seems to be linking -ltk8.5
[22:57] <infinity> doko: Did the library shuffling lose the .so -dev symlink for tcl/tk?
[22:58] <doko> infinity, enoclue yet, it has -DSTATIC_BUILD on the command line
[22:58]  * infinity looks closer.
[23:01] <infinity> lrwxrwxrwx 1 root root      11 Jan  1 23:28 /usr/lib/x86_64-linux-gnu/libtk.so -> libtk8.6.so
[23:01] <infinity> -rw-r--r-- 1 root root 1392528 Jan  1 15:41 /usr/lib/x86_64-linux-gnu/libtk8.6.so
[23:01] <infinity> lrwxrwxrwx 1 root root      11 Jan  1 15:41 /usr/lib/x86_64-linux-gnu/libtk8.6.so.0 -> libtk8.6.so
[23:01] <infinity> Well, that's backwards... But should still work.
[23:02] <doko> still has the /usr/lib/x86_64-linux-gnu/libtcl.so symlink
[23:03] <doko> and it build ok locally
[23:05] <doko> but doesn't link with -lieee locally
[23:07] <infinity> It builds fine locally?
[23:07] <infinity> With current tk-dev?
[23:07] <doko> yes. rechecking on osageorange
[23:08] <infinity> So, -lieee is from tkConfig.sh *but*, it was there in 8.5 too.
[23:08] <infinity> And I suspect only shows up on static builds.
[23:08] <infinity> So, my guess is that your local build didn't do the static thing, for whatever reason.
[23:09] <sconklin> @pilot out
[23:21] <infinity> doko: Fails locally here.  I wonder what you've done to make your computer like it.