| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === emma_ is now known as em | ||
| xnox | @pilot in | 02:50 |
|---|---|---|
| === 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 | ||
| YokoZar | slangasek: pitti: kees: infinity: stgraber: mdeslaur: congrats | 03:04 |
| YokoZar | lool: bdrung_: SpamapS: mterry: sorry :) | 03:04 |
| YokoZar | ^^^ Tech board election results | 03:04 |
| mdeslaur | YokoZar: thanks! | 03:06 |
| darkxst | xnox, could you take a look at gsettings-desktop-schemas and gnome-themes-standard during your shift? | 03:06 |
| 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:08 |
| xnox | darkxst: althought gsettings-desktop-schemas looks reasonable. | 03:09 |
| darkxst | xnox, gnome-themes-standard just has a handful of minor gtk fixes in the highcontrast theme (which all the other flavors use) | 03:18 |
| darkxst | and it fixes alot of theming issues in Adwaita | 03:20 |
| darkxst | but anyway will check with Laney or seb128 | 03:20 |
| xnox | darkxst: looking into gnome-themes-standard, i wonder what the lock screen changes are. (background keys?!) | 03:21 |
| darkxst | xnox, not sure what changes you mean, however the lock screen is gnome-shell only | 03:25 |
| xnox | darkxst: right. will test the package more and then upload. | 03:27 |
| darkxst | thanks | 03:27 |
| xnox | @pilot out | 04:39 |
| === 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 | @pilot out | 04:39 |
| Apteryx | Hi there. Could someone tell me what is the general user case of the bluetooth applet operation? | 04:58 |
| 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:00 |
| 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:01 |
| Apteryx | Is this hardware specific? My bluetooth interface is provided by the Atheros AR3011 chip. | 05:02 |
| 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:46 |
| YokoZar | SpamapS: If you want to stage a coup, let me know. | 05:47 |
| slangasek | YokoZar: thanks! is there any more official announcement of this? :) | 06:14 |
| 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:15 |
| stgraber | YokoZar: thanks! | 06:34 |
| darkxst | Logan_, was there some reason why you disabled JS support in mediatomb? | 07:16 |
| === 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 | ||
| caribou | xnox: you have marked the merge of backuppc as "please take" | 12:54 |
| === highvolt1ge is now known as highvoltage | ||
| 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:55 |
| 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 | 12:57 |
| === Lutin is now known as Guest51783 | ||
| caribou | xnox: how about the php5 one ? | 13:29 |
| caribou | xnox: looking at it, mostly done | 13:29 |
| xnox | caribou: it's non-trivial. I giving up some of the merges, because i don't feel comfortable merging them. | 13:30 |
| 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:31 |
| caribou | xnox: ok, I'll look at it | 13:32 |
| 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:34 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| === greyback is now known as greyback|lunch | ||
| 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:56 |
| 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:57 |
| 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 | 13:58 |
| 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) | 14:01 |
| === 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 | ||
| sconklin | @pilot in | 15:26 |
| === 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 | ||
| shadeslayer | is there any news on a bluez5 migration? | 15:41 |
| infinity | shadeslayer: Which news were you hoping for? | 15:49 |
| 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:51 |
| 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:52 |
| infinity | Sure. I suspect some effort needs to be put in to testing (and possibly porting) all the rdeps. | 15:53 |
| === ricmm is now known as ricmm|sick | ||
| mitya57 | doko: What should be done in qtchooser re bug 1209239? | 15:56 |
| ubottu | bug 1209239 in qtchooser (Ubuntu) "MultiArch support for QT5 is insufficient for cross building" [Undecided,Confirmed] https://launchpad.net/bugs/1209239 | 15:56 |
| 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:57 |
| infinity | caribou: For arm64, you could try https://wiki.debian.org/Arm64Qemu | 15:58 |
| 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. | 15:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| caribou | infinity: but then, if the FTBS is not arch specific, it should fail on the other arm builds as well | 16:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| caribou | infinity: simply because xnox pointed be to a bunch of ftbs on amd64 qa page | 16:09 |
| caribou | s/be/me | 16:09 |
| 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:10 |
| 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:11 |
| caribou | xnox: infinity: bottom line is : many of those are good ground for me to learn tons of things | 16:12 |
| rbasak | xnox, mdeslaur: FYI, I'm planning on merging apache2 and php5 this week. | 17:10 |
| rbasak | Any objections? | 17:10 |
| xnox | rbasak: yes please. =) you know how to test all of that stuff properly. | 17:14 |
| rbasak | xnox: indeed. I run the dep8 tests I wrote :-P | 17:16 |
| 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. | 17:17 |
| === gaughen_ is now known as gaughen | ||
| mdeslaur | rbasak: no objections from me! | 18:07 |
| mdeslaur | :) | 18:07 |
| xnox | rbasak: omg, you have Technical Board member blessing for that work. You are totally invincible now ;-) | 18:15 |
| mitya57 | Can anybody please upload a python-apt rebuild (for python3.4)? | 18:23 |
| mitya57 | (Builds fine in a PPA) | 18:24 |
| Laney | tkamppeter: your poppler uploads broke ABI | 19:22 |
| Laney | xpdf is busted now | 19:22 |
| Laney | & evince | 19:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| ubottu | Freedesktop bug 72312 in utils "[patch] pdftops: Fixes/improvements for -origpagesizes" [Normal,New] | 19:25 |
| 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:26 |
| 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:27 |
| infinity | tkamppeter: ^ | 19:28 |
| Laney | The changes aren't even committed upstream yet | 19:28 |
| Laney | AFAICS | 19:28 |
| infinity | Yeah, then definitely please back them out. | 19:29 |
| infinity | And then hunt for rdeps that were built against the new ABI, so we can rebuild them. | 19:30 |
| 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:31 |
| infinity | Oh crap. | 19:32 |
| infinity | Everything that depends on poppler in ppc64el is probably broken. | 19:33 |
| === pbn_ is now known as pbn | ||
| infinity | Oh, I guess it's not that many things anyway. | 19:33 |
| 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:34 |
| 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:50 |
| Laney | you mean .3 -> .4 I guess | 19:58 |
| mitya57 | Err, yes, of course | 19:59 |
| * mitya57 puts the time machine back | 19:59 | |
| mitya57 | And, actually, the tkamppeter's change and .3->.4 changes are unrelated :( | 20:01 |
| Laney | yeah, that's what we observed just now | 20:03 |
| 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:04 |
| * mitya57 needs some sleep, will be able to help with poppler tomorrow | 20:05 | |
| mitya57 | (I am also in process of forwarding our changes to Debian) | 20:06 |
| === cmagina_ is now known as cmagina | ||
| === salem_ is now known as _salem | ||
| 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. | 21:25 |
| infinity | doko: Bah, syncing Debian's differently multi-arched tk/tcl broke upgrades. | 22:04 |
| doko | infinity, in which way? | 22:06 |
| infinity | doko: 8.6 needs the same fix you applied to 8.5 | 22:07 |
| 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:08 |
| 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:47 |
| infinity | doko: Works on ARM and PPC, time to ditch x86 from the archive. | 22:51 |
| doko | infinity, fails on armhf too, looks like glibc complains | 22:53 |
| doko | ahh, no, it's the test_gc testcase | 22:54 |
| infinity | doko: Why is it linking that statically at all? | 22:54 |
| infinity | doko: The previous build seems to be linking -ltk8.5 | 22:55 |
| infinity | doko: Did the library shuffling lose the .so -dev symlink for tcl/tk? | 22:57 |
| doko | infinity, enoclue yet, it has -DSTATIC_BUILD on the command line | 22:58 |
| * infinity looks closer. | 22:58 | |
| 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:01 |
| doko | still has the /usr/lib/x86_64-linux-gnu/libtcl.so symlink | 23:02 |
| doko | and it build ok locally | 23:03 |
| doko | but doesn't link with -lieee locally | 23:05 |
| infinity | It builds fine locally? | 23:07 |
| infinity | With current tk-dev? | 23:07 |
| doko | yes. rechecking on osageorange | 23:07 |
| 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:08 |
| sconklin | @pilot out | 23:09 |
| === 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 | ||
| infinity | doko: Fails locally here. I wonder what you've done to make your computer like it. | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!