=== slank is now known as slank_away === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [00:08] hey guys... I was just wondering why there isn't an option on install for partner repos? I installed Linux for someone the other day and they couldn't figure out how to get Skype installed... [00:08] barry: no problem, it was a small script that we don't even use by default ;-) [00:08] is it a licensing issue or something else? [00:08] barry: i have gnome-sudoku done as well but hoping robert_ancell will look into merging it upstream in gnome =) [00:08] xnox: hey, as long as i can turn a row green, i am happy :) [00:08] xnox: \o/ [00:08] =)))))) [00:09] * xnox has a headhacke so zzzz now =) [00:10] Monotoko: aren't these applications visible in the software-center without first enabling partner? [00:14] slangasek, she said she had an error while trying to install... something about the repos... so I installed the partner ones via SSH [00:14] and it seems to have worked [00:14] but if the error was something else I apologise [00:15] Monotoko: As far as the Ubuntu installer is concerned, partner is enabled by default. [00:16] Monotoko: There was an error in a skype update the other day that might have been what they ran into. It was fixed shortly afterward, but it would depend on the time window in question. [00:17] Monotoko: (If it was last Wed/Thu or thereabouts, it was probably that error.) [00:21] slangasek, i'll rebuild, but the first patch of more asyncer was 6/6 in the ones i launched. i'll rebuild, and then do a test of at least 20. [00:22] smoser: 6/6 success or fail? [00:22] because it failed consistently here for me, there was an obvious bug once I looked at it [00:27] 6/6 success. it found the datasource in all, and imported ssh keys and such. [00:27] http://paste.ubuntu.com/1409242/ [00:27] (console log, the portion that plymouth didn't eat) [00:28] but i'll re-try [00:29] smoser: right, so it /happened/ that in your case, the events from both / and /run were ready to go in the same iteration of the loop so you're unaffected by my bug; adding a hard 'sleep 60' to a job exposes it nicely [00:29] smoser: so the new patch should work equally well for you [00:50] slangasek, its wierd. [00:51] there has to be some relation to this and the plymouth issue. [00:51] as with your newly patched version (2.46) i see the cloud-init local messages in every one === rickspencer3_ is now known as rickspencer3 [01:12] zul: ping === cpg is now known as cpg|away === sraue_ is now known as sraue === fenris is now known as Guest76064 === Guest76064 is now known as ejat [02:53] arosen: pong === cpg|away is now known as cpg [04:21] mlankhorst, bryce: for wayland and libdrm, it seems that only the -dev packages have the "xorg-renamed-package" provides; shouldn't the other packages have this too? === Logan_ is now known as Brooke === Brooke is now known as k === fenris is now known as Guest52458 === cpg is now known as cpg|away [05:59] bryce, mlankhorst: the xorg-server-lts-quantal in the new queue is based on an xorg-server that's still awaiting verification in quantal-proposed; any chance we can get that verified quickly, so we don't have to worry about accidentally letting wrong changes into precise-updates (since this won't hit the normal verification checks)? === k is now known as Logan_ === cpg|away is now known as cpg === sgnb is now known as Guest12569 [08:01] good morning [09:03] Good morning [09:03] slangasek: some deps> yes, I also get it; I know why, but I didn't address that yet === dholbach_ is now known as dholbach [09:18] slangasek: renamed libs are special [09:19] since only the -dev packages would conflict, I only added xorg-renamed-package on those [09:20] however for mesa, everything would conflict, so they all provide it [09:22] but yeah I should have kept in mind about the quantal -proposed queue, I would have expected things to clear sooner but not going to happen. :P === henrix_ is now known as henrix === mcclurmc is now known as mcclurmc_away [09:52] stokachu: it is done [10:05] hold on let me check if I can put up a 10.8 version instead.. [10:13] woops wrong version, meant the one not from proposed in quantal, anyhow the proposed quantal version should be reasonably safe, let me reverify quantal fixes just in case. :-) === mcclurmc_away is now known as mcclurmc === Guest3774 is now known as Tm_Tr === hrww is now known as hrw === _salem is now known as salem_ === stan_ is now known as stan === davidm` is now known as davidm === psivaa is now known as psivaa_lunch === cpg is now known as cpg|away === fisted_ is now known as fisted [12:48] xnox: Gah. [12:48] infinity: =)))) [12:49] xnox: If your pkg-create-dbgsym changelog is accurate, DO NOT WANT. [12:49] infinity: why not? pitti, Daviey & me do want it. [12:49] xnox: xz -9 will take FOREVER to compress. [12:49] Yeah, surely it will kill our build queue. [12:49] infinity: do you want -6 [12:50] xnox: There was a reason we agreed on -6 or -6e [12:50] xnox: -6 is the default, even, for this same reason. [12:50] infinity: me didn't recall if it was which one it was. Will the xz -6 be ok? [12:50] Just lose the -z6 [12:50] Or the -z9 [12:50] infinity: -6e is not supported by dpkg in precise which we need in the retracers. [12:50] xnox: 6 is fine, which is the default, so just drop the -z9, as Colin says. [12:50] (dpkg-deb that is) [12:51] xnox: Don't do 6e anyway, I just looked up the CPU use tables. [12:51] cjwatson: infinity: ack. [12:51] cjwatson: infinity: can you block the upload from migrating? /me will be away from the keyboard for ~0.5h now. [12:51] Switching to xz will slaughter ARM on some of the large packages anyway, but no need to make it worse. :P [12:51] or I will fix it in an hour =) [12:51] xnox: I'll fix it right now. [12:52] infinity: thanks [12:52] I don't suppose we can use xz just on fast architectures? [12:52] (I guess this was discussed ...) [12:52] cjwatson: If it looks awful, we can always back off. [12:53] Fair enough [12:54] xnox: Uploaded. [12:56] cjwatson: I expect it'll look pretty ugly for, say, webkit, but in most cases, should be fine. I guess we'll see over time if it's a loss we're okay with suffering, or if we have to exclude armhf until we have arm64 buildds. === psivaa_lunch is now known as psivaa === Ursinha-afk is now known as Ursinha [13:22] hey infinity, maybe you will have an idea: seems that rebuilding compiz (the distro version) with no code change shows a lot of new issues like bug #1085581 [13:22] Launchpad bug 1085581 in Compiz "new windows open below panel and launcher (raring staging ppa)" [High,New] https://launchpad.net/bugs/1085581 [13:22] rebuilding the same on quantal doesn't show this kind of issue, running compiz built on 2012-11-12 doesn't show the issue as well [13:22] rebuilding the same code today is experiencing that [13:23] (but I don't know when the regression started) [13:23] I tried (but maybe wrongly) to downgrade binutils and gcc, without any luck [13:24] doko would maybe have an idea as well ^ [13:25] (it's like if some compiz plugins, despite telling they are loaded are ignored) [13:25] didrocks: Diff the build logs for new warnings? [13:25] didrocks: And if it's plugins failing to load, that should be easy to trace, right? [13:26] infinity: they don't fail to load though [13:26] it's like if they were not acting [13:26] infinity: so, let me try to send that in ppa [13:26] and then do the diffing [13:26] to ensure having the same env [13:27] didrocks: Well, there's likely one of three options here. [13:28] 1) The toolchain got stricter, and some bad code got a bit worse due to it. [13:28] 2) The toolchain has a regression somewhere. [13:28] 3) A build-dep had an SOVER bump and the new version of libfoo is broken. [13:28] infinity: apart from gcc and binutils (that I maybe missed something in the downgrade path), for the "toolchain", do you see anything else? [13:28] didrocks: So, check all your dependencies on the Q and R builds to see if they're actually the same (they may well not be), and then go from there. [13:29] infinity: yeah, I'll do that as well [13:29] didrocks: linux-libc-dev and libc6-dev would be the other major toolchain changes, but unless compiz is using libc internal symbols (which I wouldn't put past it, I suppose), libc shouldn't have broken it, and it really shouldn't be using much scary from linux headers. [13:30] infinity: indeed, I'll try the libc6 road anyway. Boost is out because it didn't change since the last upload to raring [13:30] didrocks: build-deps changing would be the most likely scenario, though, IMO. And if it was an ABI bump, that would explain why Q builds work fine on raring (cause they'd use the old lib). [13:31] infinity: yeah, I'm going to diff the deps of compiz [13:31] didrocks: Are the two plugins mentioned (place and grid) shipped in the main compiz package? [13:32] infinity: yeah, all plugins are in the main compiz source now [13:32] (apart from unity) [13:32] Not the main source, I meant the main binary package. [13:32] ah, its in compiz-plugins-default [13:32] (Just trying to figure out what I should be drilling down to) [13:32] Kay. [13:32] and the other bin is in compiz-core, containing the main compiz bin === yofel_ is now known as yofel [13:37] So, the only bumped dep I see is libdecoration0, but not an ABI bump. [13:37] Not terribly exciting, unless its headers broke. [13:37] Oh, that comes from compiz. [13:37] Nevermind. [13:39] infinity: so it seems that compiz-core is the guilty one [13:40] infinity: if I install locally built compiz-plugins-default and old-distro-build compiz-core, it's working [13:40] didrocks: Due to the SOVER and ABI bump? [13:40] Files in second .deb but not in first [13:40] ------------------------------------- [13:40] -rw-r--r-- root/root /usr/lib/libcompiz_core.so.0.9.9 [13:40] -rw-r--r-- root/root /usr/share/doc/compiz-core/changelog.gz [13:40] lrwxrwxrwx root/root /usr/lib/libcompiz_core.so.ABI-20121130 -> libcompiz_core.so.0.9.9 [13:40] Files in first .deb but not in second [13:40] ------------------------------------- [13:40] -rw-r--r-- root/root /usr/lib/libcompiz_core.so.0.9.8.5 [13:40] -rw-r--r-- root/root /usr/share/doc/compiz-core/changelog.Debian.gz [13:40] lrwxrwxrwx root/root /usr/lib/libcompiz_core.so.ABI-20120927 -> libcompiz_core.so.0.9.8.5 [13:41] infinity, there is an ABI bump in the ppa but didrocks is testing by simply rebuilding the current raring version atm so that rules the ABI change out [13:41] infinity: oh, I'm just doing a 1:0.9.8.4+bzr3412-0ubuntu1 rebuild in fact [13:41] didrocks: Or is this all rebuilding the old version? [13:41] to remove this parameter [13:41] Kay. [13:41] so yeah, staying on the same version [13:42] So, compiz-core is being misbuilt (or, more likely, has buggy code that a new toolchain is less forgiving about). [13:42] Definitely diffing build logs would be a good next step. [13:42] infinity: can you rescore https://launchpad.net/~didrocks/+archive/ppa/+build/4035589 please? [13:42] Yep. [13:42] so that we have a clean ppa build [13:42] thanks :) [13:43] Is that enough 9s? [13:43] I will live with this :) [13:43] I see no warning, nothing weird on my local build [13:43] diffing will be better [13:43] That's disconcerting. [13:44] What's compiz's build time? I'll throw it at a couple of local sbuilds. [13:45] no change in dep [13:45] infinity: on a i7, it's 6-7 minutes [13:45] 25 minutes on a normal machine [13:45] 6 it is, then. [13:46] Well, my i7 is only 2 cores, so maybe not 6. :P [13:46] 14:45:24 didrocks | no change in dep -> I meant, compiz-core still have the exact dep, so no soname bump [13:46] infinity: heh, should still be quicker than my old laptop :) [13:47] Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz [13:47] Yeah, it's not awful. [13:47] The 16G of RAM and building everything in a tmpfs also helps. [13:47] I saw worse :-) [13:47] I feel so unpowered with 8G of RAM now! :) [13:48] I kinda want 32... [13:48] heh [13:52] didrocks: Oh, wait, you said a build in raring on 2012-11-12 was also okay? [13:52] infinity: right [13:53] if you takes those debs (the one you currently have in raring), they are working fine [13:53] well, more exactly, we now know that it's the compiz-core from that date which is fine contrary to one we can produce today [13:54] I wonder if something changed in the dlopen world, as it's what compiz is doing for its plugin (but it's still dlopening as we have unity loaded and some other plugins like the ws one seems to work) [13:55] Okay, that rules out glibc 2.16. It might implicate binutils 2.23. [13:55] glibc was a week or two before that, but binutils landed right in your window. [13:55] I tried to downgrade it to 2.23-2ubuntu1 (and I removed ccache) [13:55] So, I'd be inclined to try hard to downgrade binutils. :P [13:56] didrocks: No, no. To 2.22.90... from quantal. [13:56] didrocks: If this is a binutils bug, it would have likely come with 2.23 [13:56] but it landed the 6? [13:57] didrocks: In proposed. Your PPA doesn't build against proposed. [13:57] it wasn't the PPA at the time [13:57] just a direct upload to proposed [13:57] Oh, this 2012-11-12 build you speak of was in the archive? [13:57] let me grab the build log :) [13:57] infinity, https://launchpad.net/ubuntu/+source/compiz/1:0.9.8.4+bzr3412-0ubuntu1 [13:58] didrocks, Get:9 http://ftpmaster.internal/ubuntu/ raring/main binutils i386 2.23-2ubuntu1 [2439 kB] [13:58] Kay. [13:58] Setting up binutils (2.23-2ubuntu1) ... [13:58] yep [13:58] Toolchain package versions: libc6-dev_2.16-0ubuntu3 make_3.81-8.2ubuntu2 dpkg-dev_1.16.9ubuntu1 gcc-4.7_4.7.2-5ubuntu5 g++-4.7_4.7.2-5ubuntu5 binutils_2.23-2ubuntu1 libstdc++6-4.7-dev_4.7.2-5ubuntu5 libstdc++6_4.7.2-5ubuntu5 [13:59] That rules out most of the usual suspects, unless doko pulled in some breakage in a GCC SVN cherrypick. [13:59] cmake [13:59] it is cmake ! :/ [13:59] Oh, right. cmake. [13:59] It's always cmake. [13:59] thanks for the suggestion seb128 [13:59] didrocks, yw! [13:59] cmake, 2 unity strikes in 1 upload :/ [14:00] didrocks: Did you find it in a log diff, or just manually? [14:00] see, I don't like autotools but cmake is in another league :p [14:00] infinity: manually up to now [14:00] let's see the build logs if nothing relevant… [14:00] the ppa build is almost done, will be able to diff the build logs [14:00] didrocks: Oh, you're blaming cmake without having actually found an issue yet? :) [14:00] I'm all for that. [14:00] infinity: ah no :) [14:01] infinity: manually -> just downgraded cmake [14:01] and built [14:01] Ahh. [14:01] installed the new compiz-core [14:01] Effin' cmake. [14:01] and it's working [14:01] I'm mad TBH :) [14:01] Wait. I thought I saw some cmake spew scroll by in one of my logs.. [14:02] Oh, no, that happened in the old build too. [14:03] Anyhow, if you're down with blaming cmake, I can stop panicking about base toolchain malfunctions. [14:03] infinity: indeed :-) [14:03] infinity: well, at least, I'm happy it's scoped now [14:03] Now, if we could only remove cmake, and everything that {build-,}depends on it from the archive. [14:03] +1 [14:03] ;) [14:04] add a Provides: cmake to autotools ? [14:04] infinity: I thought you had that power :) [14:04] pitti: I do. It conflicts with my power to draw a paycheque. [14:04] :) [14:06] one cmake, 2 hairy unity issues… === notgary_ is now known as notgary [14:07] xnox: isn't xz -9 a little excessive? [14:07] oh infinity noticed [14:07] tumbleweed: You're living in the past, catch up on -changes. [14:07] :P [14:07] infinity: anyway, let's see if I can dive a little bit more than a revert… Thanks a lot for testing in //, that helped to keep me motivated :) [14:08] No problem. Always happy to wear skis for a coworker. [14:08] tumbleweed: you should lock responding until finishing the daily catchup. [14:08] :) [14:08] tumbleweed: =))))))) [14:08] xnox: that was actually a 15 minute catchup. I'm waiting for a build :) [14:08] tumbleweed: ah, fair enough then. [14:11] didrocks: for your magic PPAs which produce ddebs, do you need to do anything else than just build-dep'ing on p-c-dbgsym? I suppose you need dpkg-distaddfile the ddebs? [14:12] pitti: so normally, there is a configuration to ask to be checked [14:12] didrocks: I think that already has been done when we asked for the PPA [14:12] pitti: but for copying to the archive, this config was occuring to create another issue for copying the ddebs to the distro [14:12] didrocks: ah, this package is not ever going to land in the archive [14:12] in Ubuntu, I mean [14:13] pitti: so normally, you just open a RT to add ddebs to the ppa [14:13] pitti: No build-dep needed, it's in the chroots. [14:13] pitti: But yeah, there's a config twiddle. [14:13] didrocks: I mean, did you have to add distadfile to get the .ddebs into the .changes? [14:14] no, you don't need it as infinity said [14:14] pitti: The config twiddle tells pkg-create-dbgsym to add it to changes. Didn't you write that code? :P [14:14] infinity: ah, ok; because it didn't seem to be installed in the https://launchpad.net/~daisy-pluckers/+archive/daisy-seeds/+packages builds [14:14] if [ "$add_to_files" = "1" ]; then [14:14] dpkg-distaddfile "$ddeb" "$ddebsection" "$ddebpriority" [14:14] fi [14:15] pitti: Yeah, it's a PPA twiddle. [14:15] infinity: ah, so I guess they missed that part of our request [14:15] pitti: But, we should get down to testing and fixing soyuz ASAP and get rid of these tiwddly hacks. [14:15] Maybe I can try to schedule that before Christmas holidays happen. [14:16] infinity: write that code> argh, but this was years ago or so; don't expect my brain to work _that_ well :) [14:17] cjwatson, ev: not sure if you are still right people but at some point a quick review of https://code.launchpad.net/~mvo/ubiquity/ssologin/+merge/137264 if the basic structure makes sense would be nice from one of the real ubiquity developers :) [14:17] stgraber / xnox: ^^ [14:18] mvo: yeah about that. [14:18] mvo: Props on revision 5801. :P [14:18] infinity: ok, so I'll sent an RT to get that PPA ddebified [14:19] pitti: Which is a PPA that will never be copies to the archive, I assume? [14:19] infinity: b-deping on p-c-d isn't sufficient then? [14:19] s/copies/copied/ [14:19] infinity: right [14:19] mvo: there were a few of us discussing sso in the bluefin office on friday & there is an idea to show it on first-login after install or upgrade, when there is network connectivity to catch more userbase. [14:19] pitti: There's no need to build-dep on it at all, it's in all the chroots anyway. [14:19] we just need it for some test packages for daisy/apport/juju chamrs [14:19] mvo: since if ubiquity is run offline there isn't much that can be done. [14:19] pitti: It just keys off a CurrentlyBuilding twiddle. [14:19] xnox: indeed, either way is fine with me [14:19] infinity: right, but I wondered if an RT is mandatory for this [14:20] pitti: An RT, or a #webops ping. [14:20] mvo: ok. I will send an email out and CC you on it, such that you are up to date. [14:20] xnox: great, thanks. if its going to be in the installer this branch is probably the right starting point, if not, well, the glade and the logic is still a good starting point [14:20] elif grep -qs '^Build-Debug-Symbols: yes$' /CurrentlyBuilding; then [14:20] addtofiles="-a" [14:20] else [14:20] infinity: *coug* ;) [14:21] (re 5801) [14:21] mvo: I looked at your branch & I like it better than the qt stuff in the u1 installer visual-wise. But visuals may or may not change come the release time. [14:22] xnox: *nod* [14:22] infinity: hey, this is is the sort of thing you always know, any idea why natty isn't on old-releases yet? [14:23] jcastro_: Lack of round tuits. [14:23] http://people.canonical.com/~cjwatson/cross/armhf/raring/ for the interested/borderline-insane [14:24] (results of attempting to cross-build all of raring/main from amd64 to armhf) [14:24] jcastro_: By which, I assume you mean the archive portion, not the ISOs (which seem to be on old-releases) [14:24] cjwatson: Oh joy, this would be where we get our "fix five broken packages" from? :) [14:24] infinity: Aye [14:24] oh am I looking in the wrong place? http://old-releases.ubuntu.com/ubuntu/dists/ [14:25] jcastro_: That depends on what you're looking for. [14:25] jcastro_: Images, or packages? [14:25] packages [14:25] jcastro_: If you want packages, you're looking in the right place, and correct that they're not archived yet. [14:27] cjwatson: Oh, hey, apache2 looks like an easy fix (famous last words). [14:27] jcastro_: every time you ask a question like that, I always find out why by looking at askubuntu.com :) [14:27] cjwatson: gawk just seems to be making the mistake of running a test suite on itself [14:27] mdeslaur: hey it's a legit question! [14:27] hehe :) [14:27] penguin42: Yeahp, most of these are simple fixes. Just lots of them. [14:28] infinity: Possibly, yeah [14:28] pitti, tkamppeter__ : fyi: security fix uploaded for Wheezy / cups 1.5.3 . [14:28] it might work if you installed qemu :-) [14:28] penguin42: Yeah, let's not tell me about all of them [14:28] penguin42: It's deliberate this way [14:28] OdyX: thanks muchly for handling this! [14:28] penguin42: You can cross-build more if you use qemu-user-static, yes; but that won't help with bootstrapping arm64 [14:28] cjwatson: Do you have simple destructions for reproducing the cross build environment? [14:29] gawk is probably a matter of honouring DEB_BUILD_OPTIONS=nocheck [14:29] nocheck, but it should probably also have an if HOST != BUILD guard. [14:29] All testsuites should, IMO. [14:29] (Well, all testsuites that run native code) [14:29] Then you can't run them under qemu if you have that set up. [14:30] nocheck is sufficient, I think - sbuild sets that for host != build at the moment [14:30] Oh, I suppose. [14:30] Actually, glibc's is wildly perverse (and works in the qemu case). [14:30] It tests if ld.so can be run. :P [14:32] cjwatson: So, yeah, if you have "this is how to reproduce this madness" steps somewhere, I'll pick off a bunch of these. [14:32] cjwatson: Since I'm assuming cross-build-whatever doesn't exist in the archive yet, etc. [14:32] infinity: mk-sbuild --target=armhf, move the chroot to the right name if slangasek hasn't fixed that bug yet, do the crazy buildflags.conf thing from https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap if doko hasn't fixed the toolchain yet (you probably want to ignore the rest of that page), and put "$crossbuild_core_depends = { armhf => ['build-essential', 'gcc-arm-linux-gnueabihf', ... [14:32] ... 'g++-arm-linux-gnueabihf', 'pkg-config-arm-linux-gnueabihf', 'dpkg-cross'] };" in .sbuildrc if we haven't yet got crossbuild-essential-armhf [14:32] That should be close enough for government work, anyway [14:33] Then sbuild --build=amd64 --host=armhf -d raring -c raring-armhf blah.dsc [14:33] Oh, wait, can I just reuse the armhf chroots I already have? [14:33] (removing qemu to force failures, I guess) [14:33] Are they full of x86 binaries? [14:34] No, they're full of... Oh, --TARGET, not --arch. [14:34] Derp. [14:34] Right [14:34] --arch=amd64 --target=armhf in fact [14:34] If you're on an i386 host [14:35] Which I'm not, but yeah. [14:35] Oh, and please forward fixes to Debian with User: crossbuild@debian.org Usertags: cross [14:36] Will mk-sbuild bomb out if it tried to build over an existing chroot? [14:36] * infinity kinda doesn't want to blow up his current ones. [14:36] yes [14:37] (base)adconrad@cthulhu:~$ mk-sbuild --arch=amd64 --target=armhf raring [14:37] E: /var/lib/schroot/chroots/raring-amd64 already exists; aborting [14:37] Indeed. [14:37] You can use --name=random-garbage or something if you want to make sure [14:37] And move at the end [14:37] What should these actually be named when all is said and done? [14:37] -amd64-armhf or something? [14:38] Probably something like that [14:38] Well, I mean, so sbuild finds them magically. :P [14:38] I'm using -armhf because I have no native chroots here [14:38] I think we'll need to patch sbuild to look for $build-$host if we want to support both native and cross chroots on the same system [14:39] I'd certainly like to. [14:39] I realise I'm a weird corner case, but I do a lot of native armhf testbuilds on my laptop. [14:39] For now, though, I can stop doing that. [14:39] One other thing: the build coordination is fairly bodgy at the moment, and I'm occasionally prodding it by hand [14:39] It's not like I don't have a bunch of faster-than-qemu ARM kit. [14:40] So it's not *quite* completely automatic [14:40] Though it's close [14:40] Most of the BD-Uninstallable entries amount to "need to multiarch some stuff" [14:41] The bulk of which is complicated: python, perl, gobject-introspection [14:41] There are probably a handful of bits of low-hanging fruit left, though, where we just need to make some tool M-A: foreign or need to make some simple library M-A: same [14:42] would be nice if some of the -dev packages would coinstall too, is M-A: same ok when some headers are not installed on all archs, but otherwise the same? [14:43] Quite a lot of -dev packages are coinstallable [14:43] In such a case I suppose you'd need to think about whether having the union of all installed headers would confuse things [14:44] Problematic if headers of the same name end up on the search path in different spots, otherwise generally okay. [14:44] probably not, libdrm_intel.pc would still not be available on arch [14:44] Ish. [14:44] But yeah, you need to look at it case-by-case. [14:45] so having a global i915_drm.h should be harmless [14:45] shrug, I'll try building and find out [14:45] mlankhorst: Well, harmless, unless a configure script considers the existence of the header to mean something. [14:46] mlankhorst: But this is why we have arch-specific include paths. === slank_away is now known as slank [14:46] chrisccoulson: I see that you're the one usually uploading ubufox, I was wondering if you know of a way to ship a systemwide firefox profile [14:46] only packages that care about libdrm are mesa and plymouth, and i think they properly use pkgconfig [14:46] mlankhorst: Famous last words. ;) [14:47] mlankhorst: For MA -dev packages, you really do want the headers in arch-specific paths, IMO, even if they're 99% the same. [14:47] Then you avoid worry about if it's a problem. [14:47] s/worry/worrying/ [14:47] might actually break things though, most are lazy with path.. [14:48] Hrm? [14:48] GCC has the paths by default. [14:48] People who can't sort out how to type #include get what they deserve. [14:49] (Or people who build with -nostdinc) [14:49] shrug we used to build libdrm_intel on arm [14:50] mlankhorst: You could follow glibc's lead, and put only arch-specific stuff in arch dirs, but that requires actually paying attention. [14:50] mlankhorst: (See 'dpkg -L libc6-dev') [14:50] yeah probably will do that, wine build-deps for i386 is a good testcase btw.. [14:50] tons of -dev without m-a same.. [14:51] There's no harm (other than wasted disk space) in just shoving all your headers in the arch-specific path. [14:51] If our toolchain didn't work with that, we'd be pretty screwed already. [14:52] considering how some utils like to hardcode path for libdrm, would prefer not to change it [14:52] Well, wasted disk space, and possibly broken configure scripts, but testing for the latter is just some rdep rebuilds. [14:52] cjwatson, what do you mean by "fixed'? the linker paths? [14:52] mlankhorst: Things hardcode the path to the HEADERS? [14:53] doko: Yeah, the -rpath-link thing that we talked about at UDS [14:53] Or rather the need for it [14:53] I thought Steve was getting you a reduced test case for that? [14:54] infinity: cant remember where I saw -I/usr/include/libdrm though [14:55] doko: Oh, possibly it was a cross-toolchain issue that Steve was going to talk with hrw about [14:55] mlankhorst: Eww, instead of #include ? [14:55] There's an item for it on foundations-r-improve-cross-compilation === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ [14:55] Which I'm going to mark done because it's bug 923779 [14:55] Launchpad bug 923779 in armel-cross-toolchain-base (Ubuntu) "cross-linker behaviour differs from native linked" [Undecided,Triaged] https://launchpad.net/bugs/923779 [14:56] hrw: Have you been able to get anywhere with that bug ^ ? [14:56] infinity: well libdrm fails without $(pkg-config --cflags libdrm) anyway.. [15:03] cjwatson: Hrm, sbuild seems to want to use my raring-amd64 chroot by default for this. That's a bit suboptimal. [15:04] Ahh, I can feed it --chroot [15:04] infinity: Yeah, that's why my directions included -c [15:04] Bingo. [15:04] (I have an sbuild-cross wrapper to make it less tedious) [15:04] Let's see how this goes. [15:06] Hrm, except for the odd failure to umount my overlay, that seemed to go well. [15:06] cjwatson, hrw's cross-use-multiarch-dirs.patch is not yet in binutils, and probably it shouldn't. 129_ld_mulitarch_dirs.patch should do the trick [15:07] and the 4.diff is definitely wrong how to derive the multiarch name [15:08] infinity: Not a problem I've seen ... [15:09] doko: Oh, so this might just be a matter of updating the -base packages? [15:09] Against new binutils source? [15:09]