=== freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === emma_ is now known as em [02:50] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox === Guest41664 is now known as NCommander [03:04] slangasek: pitti: kees: infinity: stgraber: mdeslaur: congrats [03:04] lool: bdrung_: SpamapS: mterry: sorry :) [03:04] ^^^ Tech board election results [03:06] YokoZar: thanks! [03:06] xnox, could you take a look at gsettings-desktop-schemas and gnome-themes-standard during your shift? [03:08] 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] darkxst: althought gsettings-desktop-schemas looks reasonable. [03:18] xnox, gnome-themes-standard just has a handful of minor gtk fixes in the highcontrast theme (which all the other flavors use) [03:20] and it fixes alot of theming issues in Adwaita [03:20] but anyway will check with Laney or seb128 [03:21] darkxst: looking into gnome-themes-standard, i wonder what the lock screen changes are. (background keys?!) [03:25] xnox, not sure what changes you mean, however the lock screen is gnome-shell only [03:27] darkxst: right. will test the package more and then upload. [03:27] thanks [04:39] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [04:39] @pilot out [04:58] Hi there. Could someone tell me what is the general user case of the bluetooth applet operation? [05:00] 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] Now what I am suppose to do to bring it back ON? [05:01] I guess the designed way is to go to "Settings -> Bluetooth" and there turn the swith ON. [05:01] The switch turns ON, but the interface stays down in my case, as reported by hciconfig. [05:02] Is this hardware specific? My bluetooth interface is provided by the Atheros AR3011 chip. [05:46] YokoZar: hah, thanks for the consolation. Though I'm not on the TB, I think the results came out _wonderfully_. :) [05:46] Truth be told I'm a bit relieved. It is a big responsibility. [05:47] SpamapS: If you want to stage a coup, let me know. [06:14] YokoZar: thanks! is there any more official announcement of this? :) [06:15] slangasek: Usually pleia2 puts out something on the Fridge and such, I imagine she'll do that tomorrow after the CC meeting [06:15] ok [06:34] YokoZar: thanks! [07:16] Logan_, was there some reason why you disabled JS support in mediatomb? === sivatharman__ is now known as psivaa === ikonia_ is now known as ikonia === j_f-f_ is now known as j_f-f === sraue_ is now known as sraue === steveire_ is now known as steveire === happyaro1 is now known as unhappyaron === tkamppeter_ is now known as tkamppeter === Ursinha_ is now known as Ursinha [12:54] xnox: you have marked the merge of backuppc as "please take" === highvolt1ge is now known as highvoltage [12:55] 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] ? [12:57] caribou: sure, although Logan_ was the last one to merge it "properly". I'll certainly can review your work for correctness. [12:57] xnox: I'll check with Logan_ first, in case he's started to work on it === Lutin is now known as Guest51783 [13:29] xnox: how about the php5 one ? [13:29] xnox: looking at it, mostly done [13:30] caribou: it's non-trivial. I giving up some of the merges, because i don't feel comfortable merging them. [13:31] xnox: ah, ok I see [13:31] 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] 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] xnox: ok, I'll look at it [13:34] 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] 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] rbasak: thanks, will try that [13:37] I've never tried it with sbuild though :) [13:37] However, for sbuild, it might be possible to just use qemu-user-static actually. [13:37] caribou: well, those fixes are needed on arm64/ppc64el for which emulators might not be stable (or exist) or be slow. [13:38] 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] 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] Not sure of qemu status with ppc64el. AFAIK qemu-user-static for powerpc is pretty broken. [13:39] caribou: and check locally that during build, config.guess timestamps are updated =) and all of them. [13:39] caribou: and e.g. grep for the arm64/ppc64el gnu triplets in the update config.guess/.sub. [13:41] 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] xnox: still, as for ftbs on amd64/i386 I need to be able to test the build locally [13:42] xnox: I've done a few of those already, but never on arch other than amd64/i386 === greyback is now known as greyback|lunch [13:56] 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] 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] xnox: true, but I still need to be able to test the build to find out, isn't it ? [13:58] xnox: at least test the fix [14:01] 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) === greyback|lunch is now known as greyback === ryanakca_ is now known as ryanakca === doko__ is now known as doko === dannf` is now known as dannf [15:26] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin === Lutin is now known as Guest90700 [15:41] is there any news on a bluez5 migration? [15:49] shadeslayer: Which news were you hoping for? [15:51] Any blueprints or any ongoing work to package Bluez5? [15:51] It's been packaged in Debian experimental, though no activity there since May. [15:51] No idea if anyone's dicussed and/or committed to doing the work in Ubuntu. [15:52] well, on the KDE side, the powerdevil 1.x series will be EOL soon [15:52] and only the 2.x series will be supported [15:52] which in turn depends on Bluez5 [15:53] Sure. I suspect some effort needs to be put in to testing (and possibly porting) all the rdeps. === ricmm is now known as ricmm|sick [15:56] doko: What should be done in qtchooser re bug 1209239? [15:56] bug 1209239 in qtchooser (Ubuntu) "MultiArch support for QT5 is insufficient for cross building" [Undecided,Confirmed] https://launchpad.net/bugs/1209239 [15:57] infinity: only 46 reverse deps ... right :D [15:57] 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] caribou: For arm64, you could try https://wiki.debian.org/Arm64Qemu [15:59] 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] 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] 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] 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] infinity: ok, thanks I'll look at that [16:00] infinity: I already found apw's blog post on using ARM64 Foundation mode [16:01] caribou: The Foundation Model is certainly going to give you the most correct results. But it's sloooooow. [16:01] infinity: yeah, I noticed that already [16:02] 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] 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] infinity: that could happen as well ;-) [16:02] (Again, discounting the 1% of the time when things need actual porting) [16:03] infinity: but then, if the FTBS is not arch specific, it should fail on the other arm builds as well [16:04] 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] rbasak: I always build-test on *some* arch. :) [16:05] xnox: Right, thanks. I think opening a bug upstream makes sense. [16:05] If it's an arch-specific issue, I check two arches. [16:05] 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] (does qtchooser have a bugtracker???) [16:05] I guess I'm not confident enough with autotools for that. [16:06] rbasak: Well, that goes back to "understanding the fix". :) [16:06] I think there's a difference between thinking I understand the fix, and knowing that I understand the fix. [16:06] 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] 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] mitya57: yeah, i was going to get to that soon. But am busy with touch-emulator work at the moment. [16:08] caribou: Sure, but you're trying to fix arch-specific issues here. [16:09] infinity: simply because xnox pointed be to a bunch of ftbs on amd64 qa page [16:09] s/be/me [16:10] 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] Not for autotools mangling, anyway. [16:10] Not if, like I said, you understand the fix and how to spot-check that it's correct. [16:10] 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] xnox: so I got further in the arm64 specific builds [16:10] 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] caribou: step one was to find those that are that issue =) most of them are in the universe section ;-) [16:11] caribou: There are, of course, a hundred or so failures on x86 too, you could look at those. :P [16:11] caribou: main is mostly fixed now. [16:11] infinity: that's what I did last week :) [16:11] caribou: and there is more chance on the ppc64el page ;-) [16:12] xnox: infinity: bottom line is : many of those are good ground for me to learn tons of things [17:10] xnox, mdeslaur: FYI, I'm planning on merging apache2 and php5 this week. [17:10] Any objections? [17:14] rbasak: yes please. =) you know how to test all of that stuff properly. [17:16] xnox: indeed. I run the dep8 tests I wrote :-P [17:17] 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. === gaughen_ is now known as gaughen [18:07] rbasak: no objections from me! [18:07] :) [18:15] rbasak: omg, you have Technical Board member blessing for that work. You are totally invincible now ;-) [18:23] Can anybody please upload a python-apt rebuild (for python3.4)? [18:24] (Builds fine in a PPA) [19:22] tkamppeter: your poppler uploads broke ABI [19:22] xpdf is busted now [19:22] & evince [19:23] Laney, in which point did they break ABI, perhaps I can get fixed patches. [19:23] ubuntu5 it seems [19:23] 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] Quite, yes. [19:24] tkamppeter: As a general rule, a patch that changes a function prototype is going to break ABI... [19:24] Were these backports from a new upstream version? [19:25] Perhaps we just want the new upstream and an SOVER/ABI transition. [19:25] 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:25] Freedesktop bug 72312 in utils "[patch] pdftops: Fixes/improvements for -origpagesizes" [Normal,New] [19:26] 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] 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] And then sort out how to fix it differently. [19:28] tkamppeter: ^ [19:28] The changes aren't even committed upstream yet [19:28] AFAICS [19:29] Yeah, then definitely please back them out. [19:30] And then hunt for rdeps that were built against the new ABI, so we can rebuild them. [19:31] 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] tkamppeter: For upstream, an ABI break is fine. They break ABI in poppler constantly. [19:31] tkamppeter: But we *can't* backport that to our current package, that's all. [19:32] Oh crap. [19:33] Everything that depends on poppler in ppc64el is probably broken. === pbn_ is now known as pbn [19:33] Oh, I guess it's not that many things anyway. [19:34] 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] I'll look at that more closely when I get back from lunch. [19:50] We may want poppler 0.24.5 or 0.25 (both have different abis from 0.24.4) [19:50] There is a bug somewhere with my debdiff for 0.24.4->0.24.5 attached [19:58] you mean .3 -> .4 I guess [19:59] Err, yes, of course [19:59] * mitya57 puts the time machine back [20:01] And, actually, the tkamppeter's change and .3->.4 changes are unrelated :( [20:03] yeah, that's what we observed just now [20:04] 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] (I am also in process of forwarding our changes to Debian) === cmagina_ is now known as cmagina === salem_ is now known as _salem [21:25] 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] doko: Bah, syncing Debian's differently multi-arched tk/tcl broke upgrades. [22:06] infinity, in which way? [22:07] doko: 8.6 needs the same fix you applied to 8.5 [22:08] ahh, you mean the replaces for tcl-lib? [22:08] doko: I'll do it right now, unless you want to be TIL on tcl/tk [22:08] doko: Yeah. [22:08] no, please go ahead [22:08] looking at the ruby2.0 ftbfs now ... [22:47] https://launchpadlibrarian.net/161446482/buildlog_ubuntu-trusty-amd64.ruby2.0_2.0.0.353-1build1_FAILEDTOBUILD.txt.gz [22:47] infinity, ^^^ tries to link -lieee twice, and then complaining about a duplicate symbol from the same library? [22:51] doko: Works on ARM and PPC, time to ditch x86 from the archive. [22:53] infinity, fails on armhf too, looks like glibc complains [22:54] ahh, no, it's the test_gc testcase [22:54] doko: Why is it linking that statically at all? [22:55] doko: The previous build seems to be linking -ltk8.5 [22:57] doko: Did the library shuffling lose the .so -dev symlink for tcl/tk? [22:58] infinity, enoclue yet, it has -DSTATIC_BUILD on the command line [22:58] * infinity looks closer. [23:01] lrwxrwxrwx 1 root root 11 Jan 1 23:28 /usr/lib/x86_64-linux-gnu/libtk.so -> libtk8.6.so [23:01] -rw-r--r-- 1 root root 1392528 Jan 1 15:41 /usr/lib/x86_64-linux-gnu/libtk8.6.so [23:01] lrwxrwxrwx 1 root root 11 Jan 1 15:41 /usr/lib/x86_64-linux-gnu/libtk8.6.so.0 -> libtk8.6.so [23:01] Well, that's backwards... But should still work. [23:02] still has the /usr/lib/x86_64-linux-gnu/libtcl.so symlink [23:03] and it build ok locally [23:05] but doesn't link with -lieee locally [23:07] It builds fine locally? [23:07] With current tk-dev? [23:07] yes. rechecking on osageorange [23:08] So, -lieee is from tkConfig.sh *but*, it was there in 8.5 too. [23:08] And I suspect only shows up on static builds. [23:08] So, my guess is that your local build didn't do the static thing, for whatever reason. [23:09] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === kentb is now known as kentb-away [23:21] doko: Fails locally here. I wonder what you've done to make your computer like it.