| === slank is now known as slank_away | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| Monotoko | 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 |
|---|---|---|
| xnox | barry: no problem, it was a small script that we don't even use by default ;-) | 00:08 |
| Monotoko | is it a licensing issue or something else? | 00:08 |
| xnox | barry: i have gnome-sudoku done as well but hoping robert_ancell will look into merging it upstream in gnome =) | 00:08 |
| barry | xnox: hey, as long as i can turn a row green, i am happy :) | 00:08 |
| barry | xnox: \o/ | 00:08 |
| xnox | =)))))) | 00:08 |
| * xnox has a headhacke so zzzz now =) | 00:09 | |
| slangasek | Monotoko: aren't these applications visible in the software-center without first enabling partner? | 00:10 |
| Monotoko | 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 |
| Monotoko | and it seems to have worked | 00:14 |
| Monotoko | but if the error was something else I apologise | 00:14 |
| cjwatson | Monotoko: As far as the Ubuntu installer is concerned, partner is enabled by default. | 00:15 |
| cjwatson | 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:16 |
| cjwatson | Monotoko: (If it was last Wed/Thu or thereabouts, it was probably that error.) | 00:17 |
| smoser | 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:21 |
| slangasek | smoser: 6/6 success or fail? | 00:22 |
| slangasek | because it failed consistently here for me, there was an obvious bug once I looked at it | 00:22 |
| smoser | 6/6 success. it found the datasource in all, and imported ssh keys and such. | 00:27 |
| smoser | http://paste.ubuntu.com/1409242/ | 00:27 |
| smoser | (console log, the portion that plymouth didn't eat) | 00:27 |
| smoser | but i'll re-try | 00:28 |
| slangasek | 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 |
| slangasek | smoser: so the new patch should work equally well for you | 00:29 |
| smoser | slangasek, its wierd. | 00:50 |
| smoser | there has to be some relation to this and the plymouth issue. | 00:51 |
| smoser | as with your newly patched version (2.46) i see the cloud-init local messages in every one | 00:51 |
| === rickspencer3_ is now known as rickspencer3 | ||
| arosen | zul: ping | 01:12 |
| === 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 | ||
| zul | arosen: pong | 02:53 |
| === cpg|away is now known as cpg | ||
| slangasek | 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? | 04:21 |
| === 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 | ||
| slangasek | 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)? | 05:59 |
| === k is now known as Logan_ | ||
| === cpg|away is now known as cpg | ||
| === sgnb is now known as Guest12569 | ||
| dholbach | good morning | 08:01 |
| pitti | Good morning | 09:03 |
| pitti | slangasek: some deps> yes, I also get it; I know why, but I didn't address that yet | 09:03 |
| === dholbach_ is now known as dholbach | ||
| mlankhorst | slangasek: renamed libs are special | 09:18 |
| mlankhorst | since only the -dev packages would conflict, I only added xorg-renamed-package on those | 09:19 |
| mlankhorst | however for mesa, everything would conflict, so they all provide it | 09:20 |
| mlankhorst | 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 | 09:22 |
| === henrix_ is now known as henrix | ||
| === mcclurmc is now known as mcclurmc_away | ||
| tjaalton | stokachu: it is done | 09:52 |
| mlankhorst | hold on let me check if I can put up a 10.8 version instead.. | 10:05 |
| mlankhorst | 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. :-) | 10:13 |
| === 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 | ||
| infinity | xnox: Gah. | 12:48 |
| xnox | infinity: =)))) | 12:48 |
| infinity | xnox: If your pkg-create-dbgsym changelog is accurate, DO NOT WANT. | 12:49 |
| xnox | infinity: why not? pitti, Daviey & me do want it. | 12:49 |
| infinity | xnox: xz -9 will take FOREVER to compress. | 12:49 |
| cjwatson | Yeah, surely it will kill our build queue. | 12:49 |
| xnox | infinity: do you want -6 | 12:49 |
| infinity | xnox: There was a reason we agreed on -6 or -6e | 12:50 |
| infinity | xnox: -6 is the default, even, for this same reason. | 12:50 |
| xnox | infinity: me didn't recall if it was which one it was. Will the xz -6 be ok? | 12:50 |
| cjwatson | Just lose the -z6 | 12:50 |
| cjwatson | Or the -z9 | 12:50 |
| xnox | infinity: -6e is not supported by dpkg in precise which we need in the retracers. | 12:50 |
| infinity | xnox: 6 is fine, which is the default, so just drop the -z9, as Colin says. | 12:50 |
| xnox | (dpkg-deb that is) | 12:50 |
| infinity | xnox: Don't do 6e anyway, I just looked up the CPU use tables. | 12:51 |
| xnox | cjwatson: infinity: ack. | 12:51 |
| xnox | cjwatson: infinity: can you block the upload from migrating? /me will be away from the keyboard for ~0.5h now. | 12:51 |
| infinity | Switching to xz will slaughter ARM on some of the large packages anyway, but no need to make it worse. :P | 12:51 |
| xnox | or I will fix it in an hour =) | 12:51 |
| infinity | xnox: I'll fix it right now. | 12:51 |
| xnox | infinity: thanks | 12:52 |
| cjwatson | I don't suppose we can use xz just on fast architectures? | 12:52 |
| cjwatson | (I guess this was discussed ...) | 12:52 |
| infinity | cjwatson: If it looks awful, we can always back off. | 12:52 |
| cjwatson | Fair enough | 12:53 |
| infinity | xnox: Uploaded. | 12:54 |
| infinity | 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. | 12:56 |
| === psivaa_lunch is now known as psivaa | ||
| === Ursinha-afk is now known as Ursinha | ||
| didrocks | 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 |
| ubottu | Launchpad bug 1085581 in Compiz "new windows open below panel and launcher (raring staging ppa)" [High,New] https://launchpad.net/bugs/1085581 | 13:22 |
| didrocks | 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 |
| didrocks | rebuilding the same code today is experiencing that | 13:22 |
| didrocks | (but I don't know when the regression started) | 13:23 |
| didrocks | I tried (but maybe wrongly) to downgrade binutils and gcc, without any luck | 13:23 |
| didrocks | doko would maybe have an idea as well ^ | 13:24 |
| didrocks | (it's like if some compiz plugins, despite telling they are loaded are ignored) | 13:25 |
| infinity | didrocks: Diff the build logs for new warnings? | 13:25 |
| infinity | didrocks: And if it's plugins failing to load, that should be easy to trace, right? | 13:25 |
| didrocks | infinity: they don't fail to load though | 13:26 |
| didrocks | it's like if they were not acting | 13:26 |
| didrocks | infinity: so, let me try to send that in ppa | 13:26 |
| didrocks | and then do the diffing | 13:26 |
| didrocks | to ensure having the same env | 13:26 |
| infinity | didrocks: Well, there's likely one of three options here. | 13:27 |
| infinity | 1) The toolchain got stricter, and some bad code got a bit worse due to it. | 13:28 |
| infinity | 2) The toolchain has a regression somewhere. | 13:28 |
| infinity | 3) A build-dep had an SOVER bump and the new version of libfoo is broken. | 13:28 |
| didrocks | 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 |
| infinity | 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:28 |
| didrocks | infinity: yeah, I'll do that as well | 13:29 |
| infinity | 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:29 |
| didrocks | 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 |
| infinity | 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:30 |
| didrocks | infinity: yeah, I'm going to diff the deps of compiz | 13:31 |
| infinity | didrocks: Are the two plugins mentioned (place and grid) shipped in the main compiz package? | 13:31 |
| didrocks | infinity: yeah, all plugins are in the main compiz source now | 13:32 |
| didrocks | (apart from unity) | 13:32 |
| infinity | Not the main source, I meant the main binary package. | 13:32 |
| didrocks | ah, its in compiz-plugins-default | 13:32 |
| infinity | (Just trying to figure out what I should be drilling down to) | 13:32 |
| infinity | Kay. | 13:32 |
| didrocks | and the other bin is in compiz-core, containing the main compiz bin | 13:32 |
| === yofel_ is now known as yofel | ||
| infinity | So, the only bumped dep I see is libdecoration0, but not an ABI bump. | 13:37 |
| infinity | Not terribly exciting, unless its headers broke. | 13:37 |
| infinity | Oh, that comes from compiz. | 13:37 |
| infinity | Nevermind. | 13:37 |
| didrocks | infinity: so it seems that compiz-core is the guilty one | 13:39 |
| didrocks | infinity: if I install locally built compiz-plugins-default and old-distro-build compiz-core, it's working | 13:40 |
| infinity | didrocks: Due to the SOVER and ABI bump? | 13:40 |
| infinity | Files in second .deb but not in first | 13:40 |
| infinity | ------------------------------------- | 13:40 |
| infinity | -rw-r--r-- root/root /usr/lib/libcompiz_core.so.0.9.9 | 13:40 |
| infinity | -rw-r--r-- root/root /usr/share/doc/compiz-core/changelog.gz | 13:40 |
| infinity | lrwxrwxrwx root/root /usr/lib/libcompiz_core.so.ABI-20121130 -> libcompiz_core.so.0.9.9 | 13:40 |
| infinity | Files in first .deb but not in second | 13:40 |
| infinity | ------------------------------------- | 13:40 |
| infinity | -rw-r--r-- root/root /usr/lib/libcompiz_core.so.0.9.8.5 | 13:40 |
| infinity | -rw-r--r-- root/root /usr/share/doc/compiz-core/changelog.Debian.gz | 13:40 |
| infinity | lrwxrwxrwx root/root /usr/lib/libcompiz_core.so.ABI-20120927 -> libcompiz_core.so.0.9.8.5 | 13:40 |
| seb128 | 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 |
| didrocks | infinity: oh, I'm just doing a 1:0.9.8.4+bzr3412-0ubuntu1 rebuild in fact | 13:41 |
| infinity | didrocks: Or is this all rebuilding the old version? | 13:41 |
| didrocks | to remove this parameter | 13:41 |
| infinity | Kay. | 13:41 |
| didrocks | so yeah, staying on the same version | 13:41 |
| infinity | So, compiz-core is being misbuilt (or, more likely, has buggy code that a new toolchain is less forgiving about). | 13:42 |
| infinity | Definitely diffing build logs would be a good next step. | 13:42 |
| didrocks | infinity: can you rescore https://launchpad.net/~didrocks/+archive/ppa/+build/4035589 please? | 13:42 |
| infinity | Yep. | 13:42 |
| didrocks | so that we have a clean ppa build | 13:42 |
| didrocks | thanks :) | 13:42 |
| infinity | Is that enough 9s? | 13:43 |
| didrocks | I will live with this :) | 13:43 |
| didrocks | I see no warning, nothing weird on my local build | 13:43 |
| didrocks | diffing will be better | 13:43 |
| infinity | That's disconcerting. | 13:43 |
| infinity | What's compiz's build time? I'll throw it at a couple of local sbuilds. | 13:44 |
| didrocks | no change in dep | 13:45 |
| didrocks | infinity: on a i7, it's 6-7 minutes | 13:45 |
| didrocks | 25 minutes on a normal machine | 13:45 |
| infinity | 6 it is, then. | 13:45 |
| infinity | Well, my i7 is only 2 cores, so maybe not 6. :P | 13:46 |
| didrocks | 14:45:24 didrocks | no change in dep -> I meant, compiz-core still have the exact dep, so no soname bump | 13:46 |
| didrocks | infinity: heh, should still be quicker than my old laptop :) | 13:46 |
| infinity | Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz | 13:47 |
| infinity | Yeah, it's not awful. | 13:47 |
| infinity | The 16G of RAM and building everything in a tmpfs also helps. | 13:47 |
| didrocks | I saw worse :-) | 13:47 |
| didrocks | I feel so unpowered with 8G of RAM now! :) | 13:47 |
| infinity | I kinda want 32... | 13:48 |
| didrocks | heh | 13:48 |
| infinity | didrocks: Oh, wait, you said a build in raring on 2012-11-12 was also okay? | 13:52 |
| didrocks | infinity: right | 13:52 |
| didrocks | if you takes those debs (the one you currently have in raring), they are working fine | 13:53 |
| didrocks | 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:53 |
| didrocks | 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:54 |
| infinity | Okay, that rules out glibc 2.16. It might implicate binutils 2.23. | 13:55 |
| infinity | glibc was a week or two before that, but binutils landed right in your window. | 13:55 |
| didrocks | I tried to downgrade it to 2.23-2ubuntu1 (and I removed ccache) | 13:55 |
| infinity | So, I'd be inclined to try hard to downgrade binutils. :P | 13:55 |
| infinity | didrocks: No, no. To 2.22.90... from quantal. | 13:56 |
| infinity | didrocks: If this is a binutils bug, it would have likely come with 2.23 | 13:56 |
| didrocks | but it landed the 6? | 13:56 |
| infinity | didrocks: In proposed. Your PPA doesn't build against proposed. | 13:57 |
| didrocks | it wasn't the PPA at the time | 13:57 |
| didrocks | just a direct upload to proposed | 13:57 |
| infinity | Oh, this 2012-11-12 build you speak of was in the archive? | 13:57 |
| didrocks | let me grab the build log :) | 13:57 |
| seb128 | infinity, https://launchpad.net/ubuntu/+source/compiz/1:0.9.8.4+bzr3412-0ubuntu1 | 13:57 |
| seb128 | didrocks, Get:9 http://ftpmaster.internal/ubuntu/ raring/main binutils i386 2.23-2ubuntu1 [2439 kB] | 13:58 |
| infinity | Kay. | 13:58 |
| didrocks | Setting up binutils (2.23-2ubuntu1) ... | 13:58 |
| didrocks | yep | 13:58 |
| infinity | 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:58 |
| infinity | That rules out most of the usual suspects, unless doko pulled in some breakage in a GCC SVN cherrypick. | 13:59 |
| didrocks | cmake | 13:59 |
| didrocks | it is cmake ! :/ | 13:59 |
| infinity | Oh, right. cmake. | 13:59 |
| infinity | It's always cmake. | 13:59 |
| didrocks | thanks for the suggestion seb128 | 13:59 |
| seb128 | didrocks, yw! | 13:59 |
| didrocks | cmake, 2 unity strikes in 1 upload :/ | 13:59 |
| infinity | didrocks: Did you find it in a log diff, or just manually? | 14:00 |
| seb128 | see, I don't like autotools but cmake is in another league :p | 14:00 |
| didrocks | infinity: manually up to now | 14:00 |
| didrocks | let's see the build logs if nothing relevant… | 14:00 |
| seb128 | the ppa build is almost done, will be able to diff the build logs | 14:00 |
| infinity | didrocks: Oh, you're blaming cmake without having actually found an issue yet? :) | 14:00 |
| infinity | I'm all for that. | 14:00 |
| didrocks | infinity: ah no :) | 14:00 |
| didrocks | infinity: manually -> just downgraded cmake | 14:01 |
| didrocks | and built | 14:01 |
| infinity | Ahh. | 14:01 |
| didrocks | installed the new compiz-core | 14:01 |
| infinity | Effin' cmake. | 14:01 |
| didrocks | and it's working | 14:01 |
| didrocks | I'm mad TBH :) | 14:01 |
| infinity | Wait. I thought I saw some cmake spew scroll by in one of my logs.. | 14:01 |
| infinity | Oh, no, that happened in the old build too. | 14:02 |
| infinity | Anyhow, if you're down with blaming cmake, I can stop panicking about base toolchain malfunctions. | 14:03 |
| didrocks | infinity: indeed :-) | 14:03 |
| didrocks | infinity: well, at least, I'm happy it's scoped now | 14:03 |
| infinity | Now, if we could only remove cmake, and everything that {build-,}depends on it from the archive. | 14:03 |
| bregma | +1 | 14:03 |
| didrocks | ;) | 14:03 |
| ogra-cb | add a Provides: cmake to autotools ? | 14:04 |
| pitti | infinity: I thought you had that power :) | 14:04 |
| infinity | pitti: I do. It conflicts with my power to draw a paycheque. | 14:04 |
| didrocks | :) | 14:04 |
| didrocks | one cmake, 2 hairy unity issues… | 14:06 |
| === notgary_ is now known as notgary | ||
| tumbleweed | xnox: isn't xz -9 a little excessive? | 14:07 |
| tumbleweed | oh infinity noticed | 14:07 |
| infinity | tumbleweed: You're living in the past, catch up on -changes. | 14:07 |
| infinity | :P | 14:07 |
| didrocks | 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:07 |
| infinity | No problem. Always happy to wear skis for a coworker. | 14:08 |
| xnox | tumbleweed: you should lock responding until finishing the daily catchup. | 14:08 |
| didrocks | :) | 14:08 |
| xnox | tumbleweed: =))))))) | 14:08 |
| tumbleweed | xnox: that was actually a 15 minute catchup. I'm waiting for a build :) | 14:08 |
| xnox | tumbleweed: ah, fair enough then. | 14:08 |
| pitti | 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:11 |
| didrocks | pitti: so normally, there is a configuration to ask to be checked | 14:12 |
| pitti | didrocks: I think that already has been done when we asked for the PPA | 14:12 |
| didrocks | pitti: but for copying to the archive, this config was occuring to create another issue for copying the ddebs to the distro | 14:12 |
| pitti | didrocks: ah, this package is not ever going to land in the archive | 14:12 |
| pitti | in Ubuntu, I mean | 14:12 |
| didrocks | pitti: so normally, you just open a RT to add ddebs to the ppa | 14:13 |
| infinity | pitti: No build-dep needed, it's in the chroots. | 14:13 |
| infinity | pitti: But yeah, there's a config twiddle. | 14:13 |
| pitti | didrocks: I mean, did you have to add distadfile to get the .ddebs into the .changes? | 14:13 |
| didrocks | no, you don't need it as infinity said | 14:14 |
| infinity | pitti: The config twiddle tells pkg-create-dbgsym to add it to changes. Didn't you write that code? :P | 14:14 |
| pitti | 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 |
| infinity | if [ "$add_to_files" = "1" ]; then | 14:14 |
| infinity | dpkg-distaddfile "$ddeb" "$ddebsection" "$ddebpriority" | 14:14 |
| infinity | fi | 14:14 |
| infinity | pitti: Yeah, it's a PPA twiddle. | 14:15 |
| pitti | infinity: ah, so I guess they missed that part of our request | 14:15 |
| infinity | pitti: But, we should get down to testing and fixing soyuz ASAP and get rid of these tiwddly hacks. | 14:15 |
| infinity | Maybe I can try to schedule that before Christmas holidays happen. | 14:15 |
| pitti | infinity: write that code> argh, but this was years ago or so; don't expect my brain to work _that_ well :) | 14:16 |
| mvo | 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 |
| infinity | stgraber / xnox: ^^ | 14:17 |
| xnox | mvo: yeah about that. | 14:18 |
| infinity | mvo: Props on revision 5801. :P | 14:18 |
| pitti | infinity: ok, so I'll sent an RT to get that PPA ddebified | 14:18 |
| infinity | pitti: Which is a PPA that will never be copies to the archive, I assume? | 14:19 |
| pitti | infinity: b-deping on p-c-d isn't sufficient then? | 14:19 |
| infinity | s/copies/copied/ | 14:19 |
| pitti | infinity: right | 14:19 |
| xnox | 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 |
| infinity | pitti: There's no need to build-dep on it at all, it's in all the chroots anyway. | 14:19 |
| pitti | we just need it for some test packages for daisy/apport/juju chamrs | 14:19 |
| xnox | mvo: since if ubiquity is run offline there isn't much that can be done. | 14:19 |
| infinity | pitti: It just keys off a CurrentlyBuilding twiddle. | 14:19 |
| mvo | xnox: indeed, either way is fine with me | 14:19 |
| pitti | infinity: right, but I wondered if an RT is mandatory for this | 14:19 |
| infinity | pitti: An RT, or a #webops ping. | 14:20 |
| xnox | mvo: ok. I will send an email out and CC you on it, such that you are up to date. | 14:20 |
| mvo | 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 |
| infinity | elif grep -qs '^Build-Debug-Symbols: yes$' /CurrentlyBuilding; then | 14:20 |
| infinity | addtofiles="-a" | 14:20 |
| infinity | else | 14:20 |
| mvo | infinity: *coug* ;) | 14:20 |
| mvo | (re 5801) | 14:21 |
| xnox | 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:21 |
| mvo | xnox: *nod* | 14:22 |
| jcastro_ | infinity: hey, this is is the sort of thing you always know, any idea why natty isn't on old-releases yet? | 14:22 |
| infinity | jcastro_: Lack of round tuits. | 14:23 |
| cjwatson | http://people.canonical.com/~cjwatson/cross/armhf/raring/ for the interested/borderline-insane | 14:23 |
| cjwatson | (results of attempting to cross-build all of raring/main from amd64 to armhf) | 14:24 |
| infinity | jcastro_: By which, I assume you mean the archive portion, not the ISOs (which seem to be on old-releases) | 14:24 |
| infinity | cjwatson: Oh joy, this would be where we get our "fix five broken packages" from? :) | 14:24 |
| cjwatson | infinity: Aye | 14:24 |
| jcastro_ | oh am I looking in the wrong place? http://old-releases.ubuntu.com/ubuntu/dists/ | 14:24 |
| infinity | jcastro_: That depends on what you're looking for. | 14:25 |
| infinity | jcastro_: Images, or packages? | 14:25 |
| jcastro_ | packages | 14:25 |
| infinity | jcastro_: If you want packages, you're looking in the right place, and correct that they're not archived yet. | 14:25 |
| infinity | cjwatson: Oh, hey, apache2 looks like an easy fix (famous last words). | 14:27 |
| mdeslaur | jcastro_: every time you ask a question like that, I always find out why by looking at askubuntu.com :) | 14:27 |
| penguin42 | cjwatson: gawk just seems to be making the mistake of running a test suite on itself | 14:27 |
| jcastro_ | mdeslaur: hey it's a legit question! | 14:27 |
| mdeslaur | hehe :) | 14:27 |
| infinity | penguin42: Yeahp, most of these are simple fixes. Just lots of them. | 14:27 |
| cjwatson | infinity: Possibly, yeah | 14:28 |
| OdyX | pitti, tkamppeter__ : fyi: security fix uploaded for Wheezy / cups 1.5.3 . | 14:28 |
| penguin42 | it might work if you installed qemu :-) | 14:28 |
| cjwatson | penguin42: Yeah, let's not tell me about all of them | 14:28 |
| cjwatson | penguin42: It's deliberate this way | 14:28 |
| pitti | OdyX: thanks muchly for handling this! | 14:28 |
| cjwatson | penguin42: You can cross-build more if you use qemu-user-static, yes; but that won't help with bootstrapping arm64 | 14:28 |
| infinity | cjwatson: Do you have simple destructions for reproducing the cross build environment? | 14:28 |
| cjwatson | gawk is probably a matter of honouring DEB_BUILD_OPTIONS=nocheck | 14:29 |
| infinity | nocheck, but it should probably also have an if HOST != BUILD guard. | 14:29 |
| infinity | All testsuites should, IMO. | 14:29 |
| infinity | (Well, all testsuites that run native code) | 14:29 |
| cjwatson | Then you can't run them under qemu if you have that set up. | 14:29 |
| cjwatson | nocheck is sufficient, I think - sbuild sets that for host != build at the moment | 14:30 |
| infinity | Oh, I suppose. | 14:30 |
| infinity | Actually, glibc's is wildly perverse (and works in the qemu case). | 14:30 |
| infinity | It tests if ld.so can be run. :P | 14:30 |
| infinity | 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 |
| infinity | cjwatson: Since I'm assuming cross-build-whatever doesn't exist in the archive yet, etc. | 14:32 |
| cjwatson | 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 |
| cjwatson | ... 'g++-arm-linux-gnueabihf', 'pkg-config-arm-linux-gnueabihf', 'dpkg-cross'] };" in .sbuildrc if we haven't yet got crossbuild-essential-armhf | 14:32 |
| cjwatson | That should be close enough for government work, anyway | 14:32 |
| cjwatson | Then sbuild --build=amd64 --host=armhf -d raring -c raring-armhf blah.dsc | 14:33 |
| infinity | Oh, wait, can I just reuse the armhf chroots I already have? | 14:33 |
| infinity | (removing qemu to force failures, I guess) | 14:33 |
| cjwatson | Are they full of x86 binaries? | 14:33 |
| infinity | No, they're full of... Oh, --TARGET, not --arch. | 14:34 |
| infinity | Derp. | 14:34 |
| cjwatson | Right | 14:34 |
| cjwatson | --arch=amd64 --target=armhf in fact | 14:34 |
| cjwatson | If you're on an i386 host | 14:34 |
| infinity | Which I'm not, but yeah. | 14:35 |
| cjwatson | Oh, and please forward fixes to Debian with User: crossbuild@debian.org Usertags: cross | 14:35 |
| infinity | 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 | |
| tumbleweed | yes | 14:36 |
| infinity | (base)adconrad@cthulhu:~$ mk-sbuild --arch=amd64 --target=armhf raring | 14:37 |
| infinity | E: /var/lib/schroot/chroots/raring-amd64 already exists; aborting | 14:37 |
| infinity | Indeed. | 14:37 |
| cjwatson | You can use --name=random-garbage or something if you want to make sure | 14:37 |
| cjwatson | And move at the end | 14:37 |
| infinity | What should these actually be named when all is said and done? | 14:37 |
| infinity | -amd64-armhf or something? | 14:37 |
| cjwatson | Probably something like that | 14:38 |
| infinity | Well, I mean, so sbuild finds them magically. :P | 14:38 |
| cjwatson | I'm using -armhf because I have no native chroots here | 14:38 |
| cjwatson | 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:38 |
| infinity | I'd certainly like to. | 14:39 |
| infinity | I realise I'm a weird corner case, but I do a lot of native armhf testbuilds on my laptop. | 14:39 |
| infinity | For now, though, I can stop doing that. | 14:39 |
| cjwatson | One other thing: the build coordination is fairly bodgy at the moment, and I'm occasionally prodding it by hand | 14:39 |
| infinity | It's not like I don't have a bunch of faster-than-qemu ARM kit. | 14:39 |
| cjwatson | So it's not *quite* completely automatic | 14:40 |
| cjwatson | Though it's close | 14:40 |
| cjwatson | Most of the BD-Uninstallable entries amount to "need to multiarch some stuff" | 14:40 |
| cjwatson | The bulk of which is complicated: python, perl, gobject-introspection | 14:41 |
| cjwatson | 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:41 |
| mlankhorst | 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:42 |
| cjwatson | Quite a lot of -dev packages are coinstallable | 14:43 |
| cjwatson | In such a case I suppose you'd need to think about whether having the union of all installed headers would confuse things | 14:43 |
| infinity | Problematic if headers of the same name end up on the search path in different spots, otherwise generally okay. | 14:44 |
| mlankhorst | probably not, libdrm_intel.pc would still not be available on arch | 14:44 |
| infinity | Ish. | 14:44 |
| infinity | But yeah, you need to look at it case-by-case. | 14:44 |
| mlankhorst | so having a global i915_drm.h should be harmless | 14:45 |
| mlankhorst | shrug, I'll try building and find out | 14:45 |
| infinity | mlankhorst: Well, harmless, unless a configure script considers the existence of the header to mean something. | 14:45 |
| infinity | mlankhorst: But this is why we have arch-specific include paths. | 14:46 |
| === slank_away is now known as slank | ||
| shadeslayer | 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 |
| mlankhorst | only packages that care about libdrm are mesa and plymouth, and i think they properly use pkgconfig | 14:46 |
| infinity | mlankhorst: Famous last words. ;) | 14:46 |
| infinity | 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 |
| infinity | Then you avoid worry about if it's a problem. | 14:47 |
| infinity | s/worry/worrying/ | 14:47 |
| mlankhorst | might actually break things though, most are lazy with path.. | 14:47 |
| infinity | Hrm? | 14:48 |
| infinity | GCC has the paths by default. | 14:48 |
| infinity | People who can't sort out how to type #include <foo.h> get what they deserve. | 14:48 |
| infinity | (Or people who build with -nostdinc) | 14:49 |
| mlankhorst | shrug we used to build libdrm_intel on arm | 14:49 |
| infinity | mlankhorst: You could follow glibc's lead, and put only arch-specific stuff in arch dirs, but that requires actually paying attention. | 14:50 |
| infinity | mlankhorst: (See 'dpkg -L libc6-dev') | 14:50 |
| mlankhorst | yeah probably will do that, wine build-deps for i386 is a good testcase btw.. | 14:50 |
| mlankhorst | tons of -dev without m-a same.. | 14:50 |
| infinity | There's no harm (other than wasted disk space) in just shoving all your headers in the arch-specific path. | 14:51 |
| infinity | If our toolchain didn't work with that, we'd be pretty screwed already. | 14:51 |
| mlankhorst | considering how some utils like to hardcode path for libdrm, would prefer not to change it | 14:52 |
| infinity | Well, wasted disk space, and possibly broken configure scripts, but testing for the latter is just some rdep rebuilds. | 14:52 |
| doko | cjwatson, what do you mean by "fixed'? the linker paths? | 14:52 |
| infinity | mlankhorst: Things hardcode the path to the HEADERS? | 14:52 |
| cjwatson | doko: Yeah, the -rpath-link thing that we talked about at UDS | 14:53 |
| cjwatson | Or rather the need for it | 14:53 |
| cjwatson | I thought Steve was getting you a reduced test case for that? | 14:53 |
| mlankhorst | infinity: cant remember where I saw -I/usr/include/libdrm though | 14:54 |
| cjwatson | doko: Oh, possibly it was a cross-toolchain issue that Steve was going to talk with hrw about | 14:55 |
| infinity | mlankhorst: Eww, instead of #include <libdrm/foo.h>? | 14:55 |
| cjwatson | There's an item for it on foundations-r-improve-cross-compilation | 14:55 |
| === Tonio__ is now known as Tonio_aw | ||
| === Tonio_aw is now known as Tonio__ | ||
| cjwatson | Which I'm going to mark done because it's bug 923779 | 14:55 |
| ubottu | Launchpad bug 923779 in armel-cross-toolchain-base (Ubuntu) "cross-linker behaviour differs from native linked" [Undecided,Triaged] https://launchpad.net/bugs/923779 | 14:55 |
| cjwatson | hrw: Have you been able to get anywhere with that bug ^ ? | 14:56 |
| mlankhorst | infinity: well libdrm fails without $(pkg-config --cflags libdrm) anyway.. | 14:56 |
| infinity | cjwatson: Hrm, sbuild seems to want to use my raring-amd64 chroot by default for this. That's a bit suboptimal. | 15:03 |
| infinity | Ahh, I can feed it --chroot | 15:04 |
| cjwatson | infinity: Yeah, that's why my directions included -c | 15:04 |
| infinity | Bingo. | 15:04 |
| cjwatson | (I have an sbuild-cross wrapper to make it less tedious) | 15:04 |
| infinity | Let's see how this goes. | 15:04 |
| infinity | Hrm, except for the odd failure to umount my overlay, that seemed to go well. | 15:06 |
| doko | 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:06 |
| doko | and the 4.diff is definitely wrong how to derive the multiarch name | 15:07 |
| cjwatson | infinity: Not a problem I've seen ... | 15:08 |
| cjwatson | doko: Oh, so this might just be a matter of updating the -base packages? | 15:09 |
| cjwatson | Against new binutils source? | 15:09 |
| infinity | cjwatson: No, it's a random schroot hiccup, I think. Trying again. | 15:09 |
| infinity | cjwatson: What's the expected failure mode if I don't do the rpath-link twiddle? | 15:10 |
| infinity | Granted, my testcase of GNU hello was a bit simplistic, but it went fine without. | 15:10 |
| cjwatson | infinity: It's in bug 923779 | 15:10 |
| ubottu | Launchpad bug 923779 in armel-cross-toolchain-base (Ubuntu) "cross-linker behaviour differs from native linked" [Undecided,Triaged] https://launchpad.net/bugs/923779 | 15:10 |
| doko | cjwatson, given that the toolchain is from april, probably yes | 15:11 |
| cjwatson | I think it only fails when you have indirect library linkage; hello won't have that | 15:11 |
| rbasak | infinity: around? Do you remember the conversation a long time ago about update-initramfs parameters when called from flash-kernel-installer.postinst? | 15:11 |
| rbasak | infinity: it's broken ATM because the installer is using 3.5.0-17-highbank but the installer installs 3.5.0-19-highbank, so update-initramfs fails | 15:12 |
| rbasak | Is the solution just to bump d-i's kernel, or is there a better answer? | 15:12 |
| rbasak | I don't recall the details of that previous conversation and why we went with in-target update-initramfs -c -k $(uname -r) | 15:12 |
| infinity | rbasak: Wait, what's using $(uname -r)? | 15:14 |
| infinity | rbasak: That's going to be wrong more often than right. | 15:14 |
| * rbasak looks | 15:14 | |
| infinity | Ugh, f-k-i does? Eww. | 15:15 |
| rbasak | infinity: I think it's http://paste.ubuntu.com/1410440/ line 75 | 15:15 |
| rbasak | infinity: IIRC, -k all didn't work or something like that? I'm sure I had a conversation with somebody along these lines | 15:16 |
| infinity | Yeah, like I said, f-k-i. | 15:16 |
| === Quintasan_ is now known as Quintasan | ||
| infinity | rbasak: Is this actually causing a problem? Installing kernel packages should be generating a proper initrd anyway. | 15:16 |
| rbasak | infinity: there is a problem. I might have the root cause wrong though. ATM, quantal highbank d-i netinst is broken. | 15:16 |
| infinity | Oh dear. No, installing kernel packages won't generate an initrd, cause update-initramfs is diverted. | 15:17 |
| ogra_ | in-target update-initramfs -c -k $(uname -r) || true | 15:17 |
| ogra_ | it cant cause a problem | 15:17 |
| ogra_ | unless 7bin/ture is gone :) | 15:17 |
| rbasak | $(uname -r) doesn't match the installed kernel | 15:17 |
| rbasak | I think that's the issue | 15:17 |
| infinity | ogra_: Yes, the problem is that it doesn't generate an initrd. :P | 15:17 |
| ogra_ | */bin/true | 15:17 |
| infinity | This code is terribly wrong. | 15:18 |
| infinity | rbasak: So, this is going to need a more clever in-target to find the installed kernels, if -k all really isn't working right. But I'd like to know why that is first. | 15:18 |
| ogra_ | we have a function for that iirc | 15:19 |
| infinity | ogra_: For which "that"? | 15:19 |
| ogra_ | finding the latest kernel | 15:19 |
| ogra_ | oh | 15:19 |
| ogra_ | no, its inline, its not a function at all :/ | 15:19 |
| ogra_ | latest_version=$(linux-version list | linux-version sort | tail -1) | 15:20 |
| ogra_ | but that should do it for f-k-i too | 15:20 |
| infinity | ogra_: Except that we don't have linux-version in d-i. | 15:21 |
| ogra_ | but in the target | 15:21 |
| infinity | Oh, fair point. | 15:21 |
| ogra_ | needs some chrooting etc | 15:21 |
| infinity | That'd do the trick, then. | 15:21 |
| ogra_ | but essentially just replacing uname -r with the value of $ latest_version should do | 15:21 |
| infinity | I do wonder if it's intentional that -c -k all doesn't work. | 15:22 |
| infinity | Let me dig into that. | 15:22 |
| ogra_ | i think it is | 15:22 |
| ogra_ | at some point in time -u did just work for creating them | 15:22 |
| ogra_ | was so much easier | 15:22 |
| mvo | stgraber: \o/ | 15:24 |
| infinity | ogra_: Reading the code, '-c -k all' should work. | 15:25 |
| rbasak | Please don't take my word that -c -k all doens't work. I just vaguely remember something about it and I'm sure we tried using -k all at the time, that's all | 15:26 |
| ogra_ | iirc i tried it back then with rbasak and it didnt for him | 15:26 |
| infinity | ogra_: If version is "all", it just rexecs itself with "-mode -k ver" for all versions. | 15:26 |
| ogra_ | well, i dont mind using "all" | 15:26 |
| ogra_ | bug 1056482 | 15:27 |
| ubottu | Launchpad bug 1056482 in flash-kernel (Ubuntu) "/dev/mmcblk0p1 is not a block device when installing flash-kernel" [Undecided,Fix released] https://launchpad.net/bugs/1056482 | 15:27 |
| rbasak | it looks like I tried -k all a minute ago and it didn't work, but I'm going to reproduce from scratch to make sure | 15:27 |
| rbasak | Will be about 15 minutes I think | 15:27 |
| * cjwatson greps old IRC logs | 15:27 | |
| cjwatson | I remember talking about this | 15:27 |
| * ogra_ too | 15:27 | |
| ogra_ | bug 1035269 | 15:29 |
| ubottu | Launchpad bug 1035269 in The Eilt project "highbank quantal installer regression" [Critical,Fix released] https://launchpad.net/bugs/1035269 | 15:29 |
| infinity | Oh, hahahaha. | 15:29 |
| ogra_ | thats it | 15:29 |
| infinity | Okay, so "-c -k all" totally rexec with "-c -k $ver" for all versions. But the version list is from the state dir. | 15:29 |
| infinity | Which is empty if you have no initrds. | 15:29 |
| infinity | That should be fixed, but not for an SRU. | 15:29 |
| ogra_ | funny | 15:29 |
| infinity | For now, yeah, futzing in the chroot to find the highest installed kernel is the sane route. | 15:30 |
| ogra_ | oh, wait, we talk about an SRU here ? | 15:30 |
| cjwatson | #ubuntu-release 2012-09-26 perhaps? | 15:30 |
| infinity | ogra_: Yeah, this is for Q. | 15:30 |
| cjwatson | Not as explicit as I remember | 15:30 |
| infinity | ogra_: Where d-i/kernel skew is breaking ARM installers. | 15:31 |
| * ogra_ isnt sure we had the f-k dep on linux-version back then | 15:31 | |
| ogra_ | have to check | 15:31 |
| ogra_ | ah, yeah, its 3.0, we should | 15:31 |
| infinity | It's basically the same version. | 15:31 |
| infinity | R's only one revision ahead. | 15:31 |
| stokachu | tjaalton: awesome! thank you so much | 15:32 |
| ogra_ | k | 15:32 |
| infinity | ogra_ / rbasak: Who feels like working up an f-k-i patch for this? | 15:32 |
| ogra_ | so: latest_version=$(in-target linux-version list | in-target linux-version sort | tail -1) | 15:32 |
| ogra_ | does that look ok ? | 15:33 |
| infinity | If it works, sure. :P | 15:33 |
| * rbasak will try it in a moment | 15:33 | |
| * ogra_ wonders if the pipe will behave | 15:33 | |
| ogra_ | cjwatson, there must be something older | 15:36 |
| ogra_ | flash-kernel (3.0~rc.4ubuntu20) quantal; urgency=low | 15:36 |
| ogra_ | * seemingly -k all doesnt want to work with -c, use -k $(uname -r) for now | 15:36 |
| ogra_ | -- Oliver Grawert <ogra@ubuntu.com> Fri, 10 Aug 2012 18:29:34 +0200 | 15:36 |
| ogra_ | we surely discussed it before the upload date | 15:37 |
| cjwatson | Yeah, I failed to find it | 15:37 |
| infinity | ogra_: If there isn't a Debian bug for that, can you file one? My gut feeling is that -kall for create should include all kernels installed EVAR. | 15:38 |
| infinity | ogra_: But I'd rather fix it upstream with maks reviewing it, than hack it in Ubuntu for no good reason. | 15:38 |
| === plars_ is now known as plars | ||
| rbasak | http://irclogs.ubuntu.com/2012/08/10/%23ubuntu-devel.html#t15:09 perhaps? | 15:41 |
| ogra_ | heh awesome | 15:43 |
| ogra_ | and it has the answer for my "in-target" question from above ... cjwatson pro-actively answered it back then already | 15:44 |
| rbasak | Running two in-targets in a pipeline screwed up. I guess it's trying to do the setup and teardown twice concurrently | 15:44 |
| cjwatson | Yeah, I can believe that | 15:44 |
| cjwatson | either use a temporary variable or use in-target sh -c '...' | 15:45 |
| ogra_ | yeah, was just looking at the latter | 15:46 |
| rbasak | Everything seemed to stop working so rather than poke I just set off a reinstall | 15:46 |
| rbasak | "in-target: Unexpected error; command not executed: 'echo yes'" | 15:46 |
| ogra_ | latest_version=$(in-target sh -c 'linux-version list | in-target linux-version sort | tail -1') | 15:47 |
| ogra_ | try that | 15:47 |
| cjwatson | tail -n1 please | 15:49 |
| cjwatson | may as well be POSIXy | 15:49 |
| ogra_ | k | 15:50 |
| rbasak | ack | 15:50 |
| cjwatson | rbasak: command not executed> I think that's what you get if you omit the sh -c? | 15:50 |
| cjwatson | Oh, no | 15:50 |
| cjwatson | That's if chroot_setup fails | 15:51 |
| cjwatson | So, yeah, reboot :) | 15:51 |
| infinity | Temp variables are way more readable than nested sh -c | 15:51 |
| rbasak | cjwatson: I think in-target completely broke after attempting the double in-target pipeline. No command worked after that. I'm just reinstalling rather than worrying about the stuffed environment | 15:51 |
| cjwatson | It's rescueable by hand but not worthit | 15:51 |
| rbasak | Yeah | 15:51 |
| * ogra_ grumbles about linux-version | 15:54 | |
| ogra_ | why doesnt it just ahve a --latest option | 15:54 |
| infinity | Because it hates your freedom. | 15:57 |
| ogra_ | heh | 15:57 |
| rbasak | ogra_: a couple of minor corrections: latest_version=$(in-target --pass-stdout sh -c 'linux-version list | linux-versi | 15:57 |
| rbasak | on sort | tail -n1') | 15:57 |
| ogra_ | oh, right, forgot about --pass-stdout | 15:58 |
| rbasak | this appears to work from the shell. Note that I'm testing with only one kernel installed currently. I'll see if I can try with a second. | 15:58 |
| cjwatson | Heh, yes, I should have spotted that | 15:58 |
| * rbasak learned about --pass-stdout the last time round | 15:58 | |
| infinity | rbasak: in-target apt-get install linux-image-3.5.0-17-highbank should do. | 15:58 |
| ogra_ | well, i was even referring to it above :) | 15:58 |
| infinity | rbasak: Since we know that one exists. :P | 15:59 |
| * rbasak tries | 15:59 | |
| rbasak | Though I wonder. Will f-k-i.postinst ever run with two kernel installed, OOI? | 15:59 |
| ogra_ | rbasak, pretty unlikely but you never know | 16:01 |
| cjwatson | On cross-building: somebody brave might try to get qt4-x11 to work. It's possible it just needs to be told to use the correct compiler and linker | 16:01 |
| rbasak | I've broken something. Is this because I used in-target apt-get install instead of apt-install? | 16:02 |
| infinity | Oh, maybe. | 16:03 |
| * rbasak reboots again | 16:04 | |
| ogra_ | btw, why dont we have the kernel version exported in some variable or sitting in some preseed value we could ask | 16:04 |
| ogra_ | (by the code that selects the right kernel during installation i mean) | 16:06 |
| infinity | You could source /usr/lib/base-installer/kernel.sh and use arch_get_kernel_flavour with some archdetect magic. But that's way more hassle than just checking what's in the chroot. | 16:08 |
| infinity | Plus, also fails with different installer types. | 16:09 |
| infinity | So, don't do that. :P | 16:09 |
| ogra_ | yeah, i was more thinking about a preseed template from base-installer or so | 16:09 |
| ogra_ | it already has a bunch of kernel things | 16:10 |
| ogra_ | well, rather initrd | 16:11 |
| ogra_ | oh ! | 16:15 |
| ogra_ | base-installer/kernel/image | 16:15 |
| ogra_ | i wonder if we could rely on that | 16:15 |
| cjwatson | Won't work for server images which use live-installer | 16:16 |
| ogra_ | ah, indeed | 16:16 |
| rbasak | OK it works for two kernels too | 16:18 |
| rbasak | Tested from the network console shell thing | 16:18 |
| ogra_ | great | 16:18 |
| rbasak | latest_version=$(in-target --pass-stdout sh -c 'linux-version list | linux-version sort | tail -n1') | 16:18 |
| ogra_ | k, will upload to raring in a minute | 16:20 |
| rbasak | ogra_: bug 1084106 | 16:23 |
| ubottu | Error: Launchpad bug 1084106 could not be found | 16:23 |
| rbasak | It's private but I'll make it public in a moment | 16:24 |
| ogra_ | http://paste.ubuntu.com/1410585/ | 16:27 |
| ogra_ | just a final cross check | 16:27 |
| infinity | That || true there annoys me. | 16:28 |
| infinity | Fine for the SRU, since it was there before anyway. | 16:28 |
| infinity | But... If that fails, the system likely won't boot. :P | 16:28 |
| ogra_ | well, thats raring atm | 16:28 |
| infinity | Seems silly to short it. | 16:28 |
| ogra_ | let me drop it there then | 16:28 |
| ogra_ | (note that one comes from debian) | 16:28 |
| infinity | Keep it in Q, on the off chance it had a purpose I can't divine. | 16:28 |
| infinity | But, yeah, drop it in R. :P | 16:29 |
| infinity | And we'll find out! | 16:29 |
| ogra_ | in-target update-initramfs -u || true | 16:29 |
| ogra_ | thats the original line | 16:29 |
| rbasak | lgtm. Unless the version has spaces in it :-P | 16:29 |
| infinity | rbasak: That would be a neat trick. | 16:29 |
| ogra_ | hard to do :) | 16:29 |
| unshadow | Hi guys, sorry if this is the wrong channel for that but do you think Ubuntu is going towards or away from mono ? | 16:30 |
| ogra_ | depends on your speaker setup | 16:30 |
| infinity | *rimshot* | 16:30 |
| ogra_ | most are using a 5,1 one nowadays though | 16:30 |
| infinity | unshadow: And yes, this is the wrong channel for that. | 16:30 |
| infinity | Oh look, our first build failure in the shiny new daily-upstart PPA. | 16:31 |
| infinity | Off to a great start. | 16:31 |
| infinity | jodh: *slow clap* | 16:31 |
| jodh | infinity: you spotted it, so you get to help fix it :) | 16:43 |
| infinity | jodh: If by "spotted", you mean "got emailed about it", sure. I spotted it. As did all your teammates. ;) | 16:44 |
| infinity | jodh: Public shame fixed many bugs. | 16:44 |
| infinity | s/fixed/fixes/ | 16:44 |
| jodh | infinity: share the love I say | 16:44 |
| jodh | infinity: The shame is that we've never had a daily build before. I'm trying to rectify that :) Upstart builds in every other environment and platform we have, so any ideas as to why this is failing welcome. | 16:46 |
| infinity | BAD: wrong content in file 0x95464e0 (output), expected 'UPSTART_INSTANCE= | 16:48 |
| infinity | ' got 'PWD=/ | 16:48 |
| infinity | ' | 16:48 |
| infinity | at tests/test_job_process.c:682 (test_run). | 16:48 |
| infinity | That's some failure. | 16:48 |
| jodh | infinity: something is causing the environment to be different to that expected. It w | 16:50 |
| infinity | Seems odd to be that strict about what you expect the environment to be. | 16:50 |
| infinity | I'd call that a broken test. | 16:50 |
| infinity | Assuming the env *does* have UPSTART_INSTANCE= in it somewhere (and I bet it does), whining because it also has PWD is a bit odd. | 16:51 |
| jodh | infinity: it is not a broken test - every aspect of a newly created upstart job is checked - file descriptors, env vars, etc. That way we can guarantee behaviour. | 16:52 |
| infinity | So, it's actually a bug to have PWD in the env? Hrm. | 16:53 |
| jodh | infinity: no - it's a bug to have PWD in the environment array at that index. | 16:53 |
| jodh | infinity: I think I've just worked out what is causing this behaviour! Thanks for being the sounding board :) | 16:56 |
| infinity | :P | 16:57 |
| === allee_ is now known as allee | ||
| === deryck is now known as deryck[lunch] | ||
| arosen | zul: you aroudn? | 17:44 |
| zul | arosen: in a meeting | 17:45 |
| zul | arosen: should be available about in a hour | 17:45 |
| natschil | Hello. Does the program that mounts things in nautilus for ubuntu completely ignore fstab? | 17:50 |
| natschil | I have some mount options I need for a certain usb device I've put into fstab. Whenever I mount it manually using mount(8) it mounts the way I want it to, and clicking the relevant icon in unity brings me to the right place. If I, however, unmount it and then let nautilus mount it, it gets mounted in the wrong mountpoint. I'm now wondering whether this is the way it's supposed to work, or whether there is a bug somewhere. | 17:51 |
| mspencer | pitti: png re. bug 657275 | 17:54 |
| ubottu | Launchpad bug 657275 in apport (Ubuntu) "ubuntu-bug should save reports offline automatically rather than giving a cryptic error message" [Wishlist,In progress] https://launchpad.net/bugs/657275 | 17:54 |
| pitti | slangasek: actually, I think "set gnutarget elf32-littlearm" might just work; thanks for this! | 17:54 |
| pitti | mspencer: hello | 17:54 |
| mspencer | pitti: You were suggesting asking the user where to save the report. However, it looks like apport only has the ability to show an open file dialog. | 17:55 |
| mspencer | pitti: what would you like me to do about this? add a new function, modify the current one to add a type option, or what? | 17:56 |
| mspencer | pitti: The UserInterface.ui_question_file function only shows an open file dialog. | 17:59 |
| cjwatson | doko: Hm, you said that armhf-cross-toolchain-base has a toolchain from April, but the changelog for 1.91 said it was updated to the raring toolchain? | 18:00 |
| cjwatson | doko: Was that the version you were looking at? | 18:00 |
| pitti | mspencer: it doesn't need to use the ui_question_file() method, that's only for hooks | 18:01 |
| pitti | mspencer: well, of course you can use it if it works for you; I thought you could set a title there? | 18:01 |
| pitti | mspencer: so I think it's best for now to add new Gtk.* code to the place where you do the saving | 18:02 |
| natschil | Anybody know what program mounts external media in ubuntu? Something mounts my external vfat disk with the showexec flag set, and it's driving me insane because there seems to be no documentation I can find to tell me what is responsible. | 18:02 |
| slangasek | pitti: really? I still didn't get it working here, glad it's working for you :) | 18:03 |
| mspencer | pitti: Don't I need to use the ui_ methods so it works with the apport-cli and apport-gtk? | 18:03 |
| sarnold | natschil: I think I'd suggest starting with udev; rules somewhere in /etc/ tell udev what actions to take when what kinds of usb devices are plugged in, and it probably kicks off the automatic mounting | 18:03 |
| pitti | slangasek: at least the output now is identical for both qemu-arm gdb and gdb-multiarch | 18:04 |
| sarnold | natschil: I think all the programs it runs are in /lib/udev/ | 18:04 |
| slangasek | pitti: huh, would love to see the full command you're running | 18:04 |
| pitti | mspencer: yes, if you want to implement it in those other two UIs as well | 18:04 |
| mspencer | pitti: Yes, the title can be set, but the button says 'Open' and there is no place to type a file name. | 18:05 |
| pitti | slangasek: I now produce a set of test .crash files for various classes (GTK, Qt, CLI, d-bus) for all arches and releases, in https://code.launchpad.net/~daisy-pluckers/+archive/daisy-seeds | 18:05 |
| sarnold | mspencer: iirc, some dialogs don't show a place to type until you've started typing | 18:05 |
| natschil | sarnold: Of course udev is involved somewhere, but it isn't what's responsible for the mounting. | 18:06 |
| pitti | slangasek: so that we can use those for testing retracer rollouts, daisy branches, etc | 18:06 |
| pitti | slangasek: I now took the "sleep 10" raring core dump | 18:06 |
| natschil | sarnold: I know this because I created an udev rule to set MODE to something permissive, but that changed nothing. | 18:06 |
| pitti | slangasek: but otherwise the exact same command line as yesterday | 18:06 |
| sarnold | natschil: oh, damn :/ | 18:06 |
| natschil | I suspect there's some level of "make it insanely hard to configure external devices to be mounted with executable permissions, because it's unsafe" | 18:07 |
| pitti | slangasek: it's still not a "good" trace, though, I need more armhf ddebs | 18:08 |
| slangasek | pitti: hmm, same commandline but different test case? Because I still get 'wrong size gregset struct in core file' unconditionally | 18:09 |
| mspencer | sarnold: But where the File chooser dialog is created the type defaults to an Open dialog. | 18:10 |
| pitti | slangasek: I guess what I do next is to (1) fix armhf indexes on ddebs.u.c., (2) fix the horrible hacks which I currently have in my apport branch, so that other people can actually try this by themselves, and (3) run this against the "test .crash" files that are in the PPA | 18:11 |
| mspencer | pitti: So do you want me to add an optional parameter to the ui_question_file implementations that allows the file chooser type to be set? | 18:11 |
| sarnold | mspencer: so it's not just a misleading title then :( | 18:14 |
| mspencer | sarnold: No, this is actually an Open dialog. | 18:14 |
| sarnold | mspencer: sorry for the distraction then :) | 18:16 |
| pitti | mspencer: yes, if you want to implement it in all three, this would make most sense | 18:16 |
| mspencer | pitti: That's what I'll do, thanks for your advice. | 18:18 |
| cjwatson | natschil: udisks2 in current versions of Ubuntu; I don't know the details of how you might remove showexec though, so this is just a pointer | 18:20 |
| natschil | cjwatson: http://www.kirsle.net/blog/kirsle/rant--arrogant-developers suggests that the options have become hardcoded | 18:20 |
| slangasek | pitti: sorry, I'm still not following how you got this to work; I'd really like to understand why I got stuck here | 18:21 |
| cjwatson | natschil: I think that's best regarded as somebody blowing off steam about difficulties (and probably representative of poor documentation) rather than a true reflection of the state of affairs. | 18:21 |
| natschil | cjwatson: the reason: exposing mount options to end users is apparently not a useful thing to do | 18:21 |
| natschil | the arrogance. | 18:21 |
| natschil | it astounds me. | 18:21 |
| cjwatson | The code does not seem to bear that out. | 18:21 |
| cjwatson | At least not entirely; there is definitely some degree of support for configuration there. | 18:22 |
| ev | bdmurray: http://www.mariterra.co.uk/page/location | 18:22 |
| cjwatson | I just don't know the details since it's not a codebase I'm particularly familiar with. | 18:22 |
| cjwatson | (And the documentation certainly leaves something to be desired.) | 18:22 |
| natschil | cjwatson: but where? neither gconf nor dconf editors seem to show anything of that sort. | 18:22 |
| natschil | cjwatson: I think I will download the source code. | 18:23 |
| cjwatson | It at least seems to be trying to pick some of it up from fstab ... perhaps it's picky | 18:23 |
| cjwatson | Anyway, I'm not going to stare at this any longer :) | 18:23 |
| pitti | slangasek: for the xeyes crash it looks like this now: http://paste.ubuntu.com/1410821/ | 18:23 |
| natschil | cjwatson: probably. Those developers are idiots | 18:23 |
| cjwatson | natschil: Please take the rants elsewhere. | 18:23 |
| cjwatson | They are not appropriate here. | 18:23 |
| natschil | cjwatson: my bad, I should probably be more objective and say that the software is a failure, because it fails to read options from fstab. | 18:24 |
| pitti | slangasek: and with "qemu-arm -L /tmp/sandbox usr/bin/gdb" I'm getting an identical trace | 18:26 |
| cjwatson | natschil: That is not yet supported by evidence (perhaps it's simply overly selective), and in any case is a distinctly unhelpful way to approach the problem that I don't think is useful in #ubuntu-devel | 18:26 |
| slangasek | pitti: oh, cool; so there was just a problem with that particular test case we were working with yesterday | 18:26 |
| slangasek | (the nux one) | 18:26 |
| pitti | slangasek: at least I hope so, yes | 18:27 |
| pitti | raring armhf ddeb indexes are back, BTW | 18:27 |
| pitti | quantal's should be produced over night | 18:27 |
| natschil | cjwatson: I have evidence to support it on my machine. Steps to reproduce: create something in fstab that uses an uuid. watch devicekit fail. | 18:28 |
| cjwatson | It hasn't been called devicekit for quite a while ... | 18:28 |
| slangasek | pitti: sweet | 18:28 |
| natschil | cjwatson: sure, calling the developers idiots may not be that productive. The thing is that I'm annoyed that their arrogance seems to be the cause of me wasting my day trying to find said configuration options. | 18:28 |
| cjwatson | And we use UUIDs absolutely everywhere in Ubuntu, so I do not think that this is a systemic failure | 18:29 |
| cjwatson | It is often useful to distinguish between "fails for me" and "fails for everyone" | 18:29 |
| cjwatson | This is a developer channel, not user support, so please take a more productive line | 18:29 |
| natschil | cjwatson: what is it called nowadays? | 18:29 |
| cjwatson | devicekit-disks became udisks became udisks2 | 18:29 |
| cjwatson | ish | 18:29 |
| pitti | slangasek: I also noticed that our standard "gdb" amd64 package can seamlessly process i386 core dumps, which is really nice; I don't need i386 dchroots on the retracer machines any more | 18:30 |
| * cjwatson -> dinner | 18:31 | |
| === deryck[lunch] is now known as deryck | ||
| slangasek | pitti: indeed :) | 18:34 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursula is now known as Guest43737 | ||
| === Ursinha-afk is now known as Ursinha | ||
| === mcclurmc is now known as mcclurmc_away | ||
| infinity | xnox: FWIW, you can stop fretting about iptables, the latest kernel upload fixes it (see the successful powerpc retry) | 18:59 |
| slangasek | mlankhorst: why does xorg-server-lts-quantal include a patch not in the quantal-proposed version of xorg-server (xorg-server-legacy-bgnone.patch)? | 19:43 |
| seb128 | slangasek, if the xserver-xorg-lts-quantal breaks multimedia keys in Unity/GNOME is that something we want to handle with a break statement or something? or do we just need to land the corresponding fix? | 19:46 |
| slangasek | seb128: hmmm, we ought to fix it | 19:46 |
| seb128 | slangasek, that's https://bugs.launchpad.net/bugs/1034090 for which I uploaded a SRU fix today | 19:46 |
| ubottu | Launchpad bug 1034090 in gnome-settings-daemon (Ubuntu Precise) "Hotkeys not functional after upgrade to quantal's xorg (new xinput version)" [High,In progress] | 19:46 |
| slangasek | well, by "fix" I mean either that the incompatibility needs to be reverted *or* an update like g-s-d is needed, yeah | 19:47 |
| seb128 | slangasek, right, the fix is in the queue, I'm wondering if we should ensure both get updated in locked steps in some way | 19:47 |
| slangasek | in the latter case, there should also be a breaks | 19:47 |
| seb128 | so xserver-xorg-lts-quantal needs to Breaks gnome-settings-daemon (<< 3.4.2-0ubuntu0.6.1) | 19:48 |
| seb128 | http://launchpadlibrarian.net/124872994/gnome-settings-daemon_3.4.2-0ubuntu0.6.1_source.changes | 19:48 |
| seb128 | is the upload | 19:48 |
| seb128 | there is a SRU in proposed for g-s-d atm but it should be good to move tomorrow (I will try to make sure it's verification-done tomorrow) | 19:48 |
| mlankhorst | slangasek: it's required for -nc to work | 19:51 |
| mlankhorst | else it will fail to start | 19:51 |
| slangasek | mlankhorst: and that's something that's relied on by some software in precise? | 19:51 |
| mlankhorst | yeah | 19:51 |
| slangasek | mlankhorst: could you please reupload the package adding an explanation of this to the changelog and adding the Breaks: on gnome-settings-daemon that seb128 says above is needed? | 19:52 |
| mlankhorst | slangasek: well I tend not to explain those specific things since I autogenerate the entire stack | 19:53 |
| === henrix is now known as henrix_ | ||
| slangasek | mlankhorst: ok - I'm not really happy about changelogs being autogenerated, but we'll roll with it. how about the Breaks, then? | 19:55 |
| mlankhorst | entire stack is generated by running xorg-pkg-tools/lts-stack, I'll take a look at the breaks.. | 19:55 |
| slangasek | mlankhorst: do you prefer that I accept the current version of this package without the Breaks and you upload again with a new version number, or should I reject this one and wait for a reupload? | 19:55 |
| seb128 | slangasek, mlankhorst: thanks | 19:55 |
| mlankhorst | slangasek: might be best to accept the current version to build the rest, then I'll reupload? | 19:56 |
| slangasek | mlankhorst: yep, fine with me | 19:56 |
| mlankhorst | and the script is automated because it's the only way I prevent human mistakes from being a problem :/ | 20:00 |
| slangasek | mlankhorst: yep - I certainly approve of this kind of automation, I just would prefer that it not be applied in a way that prevents changelogs from working the normal way :) | 20:02 |
| mwhudson | hm | 20:12 |
| mwhudson | what is stdin for an upstart job? /dev/null? | 20:12 |
| slangasek | unless you use a different 'console' option, yes | 20:13 |
| slangasek | (or use a redirect in the script itself) | 20:13 |
| mwhudson | well yes, the latter point had occurred to me :-) | 20:14 |
| mwhudson | hmm | 20:15 |
| mwhudson | although this upstart job says "console output: | 20:15 |
| mwhudson | oh nevermind | 20:16 |
| slangasek | in that case, IIRC stdin is also attached to the console | 20:16 |
| mwhudson | it's other bits of my code doing something odd | 20:16 |
| mwhudson | slangasek: yeah, that's what the docs say | 20:16 |
| mwhudson | i think i am just going to go and hate bash a bit, brb | 20:16 |
| mwhudson | while read line ; do | 20:19 |
| mwhudson | er mischan | 20:19 |
| === glebihan_ is now known as glebihan | ||
| arges | whats the process for adding a patch to a package that doesn't have a patch system set up yet? | 20:47 |
| penguin42 | arges: I just had a look at edit-patch, I wondered whether that might set ione up, but it doesn't seem to | 20:51 |
| arges | penguin42, thanks,yea I've got it working with quilt and adding the necessary files. but was wondering how I can properly prepare that to fix a bug. | 20:53 |
| slangasek | cyphermox: does the dnsmasq conversion to use of dbus in quantal mean we no longer have a config file on disk anywhere that shows the current dns server settings? if so, how can one see this list for debugging? | 21:08 |
| cyphermox | ah, it does. In the file I wrote that it will be listed in /var/log/syslog when NM changes it | 21:09 |
| cyphermox | if you want to query it, it's sending a USR1 signal to dnsmasq | 21:09 |
| slangasek | cyphermox: USR1 causes dnsmasq to echo it to syslog? | 21:09 |
| cyphermox | yes | 21:09 |
| cyphermox | it causes dnsmasq to write statistics data to syslog, and that includes the servers | 21:09 |
| infinity | Huh, so it does. | 21:10 |
| infinity | Handy. | 21:10 |
| * infinity tries to remember that for when it'll be useful. | 21:10 | |
| cyphermox | indeed. it's documented in the manpage, not sure if there should be more obvious docs for this | 21:11 |
| cyphermox | slangasek: seen the other SRU for dnsmasq though, since it's required for these changes? | 21:13 |
| cjwatson | arges: If there's no patch system, and the source is format 1.0 (no debian/source/format or it just contains '1.0'), then just apply the patch directly to the upstream source code. | 22:19 |
| arges | cjwatson, ok i'll do that then for bug 1071209 . thanks | 22:20 |
| ubottu | Launchpad bug 1071209 in memtest86+ (Ubuntu Raring) "memtest86 test #7 false positives (random number sequence error)" [Medium,In progress] https://launchpad.net/bugs/1071209 | 22:20 |
| cjwatson | arges: Yes. If you look at memtest+'s .diff.gz, you'll see it already has some patches applied this way. | 22:21 |
| arges | cool fixing it now | 22:22 |
| === cpg|away is now known as cpg | ||
| doko | cjwatson, the linaro page you did mention, only has this old one. So I think you are talking about armhf, not am64? | 22:38 |
| === rickspencer3_ is now known as rickspencer3 | ||
| === salem_ is now known as _salem | ||
| cjwatson | doko: Um, you mean about -cross-toolchain-base? Right now I'm not looking at the arm64 cross-toolchain at all, only armhf | 23:39 |
| stgraber | hallyn: oh well, looks like I'll need to split the container-detect job into container-detect and container-detect-write, so I can make the first be "start on startup" and only have the second do the /run writting. | 23:47 |
| slangasek | stgraber: why's this? | 23:47 |
| stgraber | hallyn: that way we can start using the "container" and "not-container" events very very early on and prevent stuff like plymouth, console-*, setvtrgb, ureadhead, ... from starting | 23:47 |
| stgraber | slangasek: ^ that's why | 23:47 |
| slangasek | cyphermox: SRU for dnsmasq> hmmm no, sorry, my question came from a completely different context of resolvconf bug reports | 23:48 |
| stgraber | basically we have a bunch of stuff that tries to start at boot time and either fails miserably (because we don't have real ttys) or starts but doesn't do anything useful (like plymouth) | 23:48 |
| cyphermox | slangasek: ok.. | 23:48 |
| stgraber | we have nice events to deal with those case, but currently the container-detect job depends on /run being mounted so we can't use those very early in the boot sequence | 23:48 |
| slangasek | stgraber: console* and setvtrgb don't happen pre-virtualfilesystems; and I would assert that suppressing plymouth and ureadahead in a container is a wrong fix | 23:50 |
| slangasek | stgraber: and I'm not sure why plymouth "doesn't do anything useful" for that matter, the existing job setup should allow it to connect to the text-only console and do any necessary mountall handling | 23:52 |
| slangasek | stgraber: so, can you please file a bug against plymouth about this :) | 23:53 |
| stgraber | well, containers aren't allowed to access block devices, so it's unlikely to be really useful (we support cryptsetup but it's a pre-startup hook outside the container). Anyway, doing some specific plymouth testing now to confirm that it fails to render anything on the pts | 23:54 |
| slangasek | "containers aren't allowed to access block devices" - not universally true :) | 23:55 |
| slangasek | and even if it were, I'm very concerned about adding additional complexity to the common jobs on the grounds that they're deemed not useful in some contexts | 23:56 |
| stgraber | slangasek: so, I have plymouthd running, how do I get it to show me something? | 23:56 |
| slangasek | stgraber: did 'plymouth show-splash' get called? (/etc/init/plymouth-splash.conf) | 23:57 |
| stgraber | slangasek: I called show-splash manually, so yeah | 23:58 |
| slangasek | start plymouthd; call 'plymouth show-splash'; then call, e.g., 'plymouth ask-for-password --prompt 'open sesame: ' | 23:58 |
| stgraber | ok, the ask-for-password just returns and nothing is shown on /dev/lxc/console (my current tty) | 23:59 |
| slangasek | er, ok, that's weird | 23:59 |
| slangasek | (and a bug) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!