/srv/irclogs.ubuntu.com/2012/12/04/#ubuntu-devel.txt

=== slank is now known as slank_away
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
Monotokohey 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
xnoxbarry: no problem, it was a small script that we don't even use by default ;-)00:08
Monotokois it a licensing issue or something else?00:08
xnoxbarry: i have gnome-sudoku done as well but hoping robert_ancell will look into merging it upstream in gnome =)00:08
barryxnox: hey, as long as i can turn a row green, i am happy :)00:08
barryxnox: \o/00:08
xnox=))))))00:08
* xnox has a headhacke so zzzz now =)00:09
slangasekMonotoko: aren't these applications visible in the software-center without first enabling partner?00:10
Monotokoslangasek, she said she had an error while trying to install... something about the repos... so I installed the partner ones via SSH00:14
Monotokoand it seems to have worked00:14
Monotokobut if the error was something else I apologise00:14
cjwatsonMonotoko: As far as the Ubuntu installer is concerned, partner is enabled by default.00:15
cjwatsonMonotoko: 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
cjwatsonMonotoko: (If it was last Wed/Thu or thereabouts, it was probably that error.)00:17
smoserslangasek, 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
slangaseksmoser: 6/6 success or fail?00:22
slangasekbecause it failed consistently here for me, there was an obvious bug once I looked at it00:22
smoser6/6 success. it found the datasource in all, and imported ssh keys and such.00:27
smoserhttp://paste.ubuntu.com/1409242/00:27
smoser(console log, the portion that plymouth didn't eat)00:27
smoserbut i'll re-try00:28
slangaseksmoser: 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 nicely00:29
slangaseksmoser: so the new patch should work equally well for you00:29
smoserslangasek, its wierd.00:50
smoserthere has to be some relation to this and the plymouth issue.00:51
smoseras with your newly patched version (2.46) i see the cloud-init local messages in every one00:51
=== rickspencer3_ is now known as rickspencer3
arosenzul:  ping01: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
zularosen: pong02:53
=== cpg|away is now known as cpg
slangasekmlankhorst, 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
slangasekbryce, 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
dholbachgood morning08:01
pittiGood morning09:03
pittislangasek: some deps> yes, I also get it; I know why, but I didn't address that yet09:03
=== dholbach_ is now known as dholbach
mlankhorstslangasek: renamed libs are special09:18
mlankhorstsince only the -dev packages would conflict, I only added xorg-renamed-package on those09:19
mlankhorsthowever for mesa, everything would conflict, so they all provide it09:20
mlankhorstbut 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. :P09:22
=== henrix_ is now known as henrix
=== mcclurmc is now known as mcclurmc_away
tjaaltonstokachu: it is done09:52
mlankhorsthold on let me check if I can put up a 10.8 version instead..10:05
mlankhorstwoops 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
infinityxnox: Gah.12:48
xnoxinfinity: =))))12:48
infinityxnox: If your pkg-create-dbgsym changelog is accurate, DO NOT WANT.12:49
xnoxinfinity: why not? pitti, Daviey & me do want it.12:49
infinityxnox: xz -9 will take FOREVER to compress.12:49
cjwatsonYeah, surely it will kill our build queue.12:49
xnoxinfinity: do you want -612:49
infinityxnox: There was a reason we agreed on -6 or -6e12:50
infinityxnox: -6 is the default, even, for this same reason.12:50
xnoxinfinity: me didn't recall if it was which one it was. Will the xz -6 be ok?12:50
cjwatsonJust lose the -z612:50
cjwatsonOr the -z912:50
xnoxinfinity: -6e is not supported by dpkg in precise which we need in the retracers.12:50
infinityxnox: 6 is fine, which is the default, so just drop the -z9, as Colin says.12:50
xnox(dpkg-deb that is)12:50
infinityxnox: Don't do 6e anyway, I just looked up the CPU use tables.12:51
xnoxcjwatson: infinity: ack.12:51
xnoxcjwatson: infinity: can you block the upload from migrating? /me will be away from the keyboard for ~0.5h now.12:51
infinitySwitching to xz will slaughter ARM on some of the large packages anyway, but no need to make it worse. :P12:51
xnoxor I will fix it in an hour =)12:51
infinityxnox: I'll fix it right now.12:51
xnoxinfinity: thanks12:52
cjwatsonI don't suppose we can use xz just on fast architectures?12:52
cjwatson(I guess this was discussed ...)12:52
infinitycjwatson: If it looks awful, we can always back off.12:52
cjwatsonFair enough12:53
infinityxnox: Uploaded.12:54
infinitycjwatson: 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
didrockshey 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 #108558113:22
ubottuLaunchpad bug 1085581 in Compiz "new windows open below panel and launcher (raring staging ppa)" [High,New] https://launchpad.net/bugs/108558113:22
didrocksrebuilding the same on quantal doesn't show this kind of issue, running compiz built on 2012-11-12 doesn't show the issue as well13:22
didrocksrebuilding the same code today is experiencing that13:22
didrocks(but I don't know when the regression started)13:23
didrocksI tried (but maybe wrongly) to downgrade binutils and gcc, without any luck13:23
didrocksdoko 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
infinitydidrocks: Diff the build logs for new warnings?13:25
infinitydidrocks: And if it's plugins failing to load, that should be easy to trace, right?13:25
didrocksinfinity: they don't fail to load though13:26
didrocksit's like if they were not acting13:26
didrocksinfinity: so, let me try to send that in ppa13:26
didrocksand then do the diffing13:26
didrocksto ensure having the same env13:26
infinitydidrocks: Well, there's likely one of three options here.13:27
infinity1) The toolchain got stricter, and some bad code got a bit worse due to it.13:28
infinity2) The toolchain has a regression somewhere.13:28
infinity3) A build-dep had an SOVER bump and the new version of libfoo is broken.13:28
didrocksinfinity: apart from gcc and binutils (that I maybe missed something in the downgrade path), for the "toolchain", do you see anything else?13:28
infinitydidrocks: 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
didrocksinfinity: yeah, I'll do that as well13:29
infinitydidrocks: 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
didrocksinfinity: indeed, I'll try the libc6 road anyway. Boost is out because it didn't change since the last upload to raring13:30
infinitydidrocks: 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
didrocksinfinity: yeah, I'm going to diff the deps of compiz13:31
infinitydidrocks: Are the two plugins mentioned (place and grid) shipped in the main compiz package?13:31
didrocksinfinity: yeah, all plugins are in the main compiz source now13:32
didrocks(apart from unity)13:32
infinityNot the main source, I meant the main binary package.13:32
didrocksah, its in compiz-plugins-default13:32
infinity(Just trying to figure out what I should be drilling down to)13:32
infinityKay.13:32
didrocksand the other bin is in compiz-core, containing the main compiz bin13:32
=== yofel_ is now known as yofel
infinitySo, the only bumped dep I see is libdecoration0, but not an ABI bump.13:37
infinityNot terribly exciting, unless its headers broke.13:37
infinityOh, that comes from compiz.13:37
infinityNevermind.13:37
didrocksinfinity: so it seems that compiz-core is the guilty one13:39
didrocksinfinity: if I install locally built compiz-plugins-default and old-distro-build compiz-core, it's working13:40
infinitydidrocks: Due to the SOVER and ABI bump?13:40
infinityFiles in second .deb but not in first13:40
infinity-------------------------------------13:40
infinity-rw-r--r--  root/root   /usr/lib/libcompiz_core.so.0.9.913:40
infinity-rw-r--r--  root/root   /usr/share/doc/compiz-core/changelog.gz13:40
infinitylrwxrwxrwx  root/root   /usr/lib/libcompiz_core.so.ABI-20121130 -> libcompiz_core.so.0.9.913:40
infinityFiles in first .deb but not in second13:40
infinity-------------------------------------13:40
infinity-rw-r--r--  root/root   /usr/lib/libcompiz_core.so.0.9.8.513:40
infinity-rw-r--r--  root/root   /usr/share/doc/compiz-core/changelog.Debian.gz13:40
infinitylrwxrwxrwx  root/root   /usr/lib/libcompiz_core.so.ABI-20120927 -> libcompiz_core.so.0.9.8.513:40
seb128infinity, 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 out13:41
didrocksinfinity: oh, I'm just doing a 1:0.9.8.4+bzr3412-0ubuntu1 rebuild in fact13:41
infinitydidrocks: Or is this all rebuilding the old version?13:41
didrocksto remove this parameter13:41
infinityKay.13:41
didrocksso yeah, staying on the same version13:41
infinitySo, compiz-core is being misbuilt (or, more likely, has buggy code that a new toolchain is less forgiving about).13:42
infinityDefinitely diffing build logs would be a good next step.13:42
didrocksinfinity: can you rescore https://launchpad.net/~didrocks/+archive/ppa/+build/4035589 please?13:42
infinityYep.13:42
didrocksso that we have a clean ppa build13:42
didrocksthanks :)13:42
infinityIs that enough 9s?13:43
didrocksI will live with this :)13:43
didrocksI see no warning, nothing weird on my local build13:43
didrocksdiffing will be better13:43
infinityThat's disconcerting.13:43
infinityWhat's compiz's build time?  I'll throw it at a couple of local sbuilds.13:44
didrocksno change in dep13:45
didrocksinfinity: on a i7, it's 6-7 minutes13:45
didrocks25 minutes on a normal machine13:45
infinity6 it is, then.13:45
infinityWell, my i7 is only 2 cores, so maybe not 6. :P13:46
didrocks14:45:24   didrocks | no change in dep -> I meant, compiz-core still have the exact dep, so no soname bump13:46
didrocksinfinity: heh, should still be quicker than my old laptop :)13:46
infinityIntel(R) Core(TM) i7-2640M CPU @ 2.80GHz13:47
infinityYeah, it's not awful.13:47
infinityThe 16G of RAM and building everything in a tmpfs also helps.13:47
didrocksI saw worse :-)13:47
didrocksI feel so unpowered with 8G of RAM now! :)13:47
infinityI kinda want 32...13:48
didrocksheh13:48
infinitydidrocks: Oh, wait, you said a build in raring on 2012-11-12 was also okay?13:52
didrocksinfinity: right13:52
didrocksif you takes those debs (the one you currently have in raring), they are working fine13:53
didrockswell, more exactly, we now know that it's the compiz-core from that date which is fine contrary to one we can produce today13:53
didrocksI 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
infinityOkay, that rules out glibc 2.16.  It might implicate binutils 2.23.13:55
infinityglibc was a week or two before that, but binutils landed right in your window.13:55
didrocksI tried to downgrade it to 2.23-2ubuntu1 (and I removed ccache)13:55
infinitySo, I'd be inclined to try hard to downgrade binutils. :P13:55
infinitydidrocks: No, no.  To 2.22.90... from quantal.13:56
infinitydidrocks: If this is a binutils bug, it would have likely come with 2.2313:56
didrocksbut it landed the 6?13:56
infinitydidrocks: In proposed.  Your PPA doesn't build against proposed.13:57
didrocksit wasn't the PPA at the time13:57
didrocksjust a direct upload to proposed13:57
infinityOh, this 2012-11-12 build you speak of was in the archive?13:57
didrockslet me grab the build log :)13:57
seb128infinity, https://launchpad.net/ubuntu/+source/compiz/1:0.9.8.4+bzr3412-0ubuntu113:57
seb128didrocks, Get:9 http://ftpmaster.internal/ubuntu/ raring/main binutils i386 2.23-2ubuntu1 [2439 kB]13:58
infinityKay.13:58
didrocksSetting up binutils (2.23-2ubuntu1) ...13:58
didrocksyep13:58
infinityToolchain 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-5ubuntu513:58
infinityThat rules out most of the usual suspects, unless doko pulled in some breakage in a GCC SVN cherrypick.13:59
didrockscmake13:59
didrocksit is cmake ! :/13:59
infinityOh, right.  cmake.13:59
infinityIt's always cmake.13:59
didrocksthanks for the suggestion seb12813:59
seb128didrocks, yw!13:59
didrockscmake, 2 unity strikes in 1 upload :/13:59
infinitydidrocks: Did you find it in a log diff, or just manually?14:00
seb128see, I don't like autotools but cmake is in another league :p14:00
didrocksinfinity: manually up to now14:00
didrockslet's see the build logs if nothing relevant…14:00
seb128the ppa build is almost done, will be able to diff the build logs14:00
infinitydidrocks: Oh, you're blaming cmake without having actually found an issue yet? :)14:00
infinityI'm all for that.14:00
didrocksinfinity: ah no :)14:00
didrocksinfinity: manually -> just downgraded cmake14:01
didrocksand built14:01
infinityAhh.14:01
didrocksinstalled the new compiz-core14:01
infinityEffin' cmake.14:01
didrocksand it's working14:01
didrocksI'm mad TBH :)14:01
infinityWait.  I thought I saw some cmake spew scroll by in one of my logs..14:01
infinityOh, no, that happened in the old build too.14:02
infinityAnyhow, if you're down with blaming cmake, I can stop panicking about base toolchain malfunctions.14:03
didrocksinfinity: indeed :-)14:03
didrocksinfinity: well, at least, I'm happy it's scoped now14:03
infinityNow, if we could only remove cmake, and everything that {build-,}depends on it from the archive.14:03
bregma+114:03
didrocks;)14:03
ogra-cbadd a Provides: cmake to autotools ?14:04
pittiinfinity: I thought you had that power :)14:04
infinitypitti: I do.  It conflicts with my power to draw a paycheque.14:04
didrocks:)14:04
didrocksone cmake, 2 hairy unity issues…14:06
=== notgary_ is now known as notgary
tumbleweedxnox: isn't xz -9 a little excessive?14:07
tumbleweedoh infinity noticed14:07
infinitytumbleweed: You're living in the past, catch up on -changes.14:07
infinity:P14:07
didrocksinfinity: 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
infinityNo problem.  Always happy to wear skis for a coworker.14:08
xnoxtumbleweed: you should lock responding until finishing the daily catchup.14:08
didrocks:)14:08
xnoxtumbleweed: =)))))))14:08
tumbleweedxnox: that was actually a 15 minute catchup. I'm waiting for a build :)14:08
xnoxtumbleweed: ah, fair enough then.14:08
pittididrocks: 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
didrockspitti: so normally, there is a configuration to ask to be checked14:12
pittididrocks: I think that already has been done when we asked for the PPA14:12
didrockspitti: but for copying to the archive, this config was occuring to create another issue for copying the ddebs to the distro14:12
pittididrocks: ah, this package is not ever going to land in the archive14:12
pittiin Ubuntu, I mean14:12
didrockspitti: so normally, you just open a RT to add ddebs to the ppa14:13
infinitypitti: No build-dep needed, it's in the chroots.14:13
infinitypitti: But yeah, there's a config twiddle.14:13
pittididrocks: I mean, did you have to add distadfile to get the .ddebs into the .changes?14:13
didrocksno, you don't need it as infinity said14:14
infinitypitti: The config twiddle tells pkg-create-dbgsym to add it to changes.  Didn't you write that code? :P14:14
pittiinfinity: ah, ok; because it didn't seem to be installed in the https://launchpad.net/~daisy-pluckers/+archive/daisy-seeds/+packages builds14:14
infinityif [ "$add_to_files" = "1" ]; then14:14
infinity    dpkg-distaddfile "$ddeb" "$ddebsection" "$ddebpriority"14:14
infinityfi14:14
infinitypitti: Yeah, it's a PPA twiddle.14:15
pittiinfinity: ah, so I guess they missed that part of our request14:15
infinitypitti: But, we should get down to testing and fixing soyuz ASAP and get rid of these tiwddly hacks.14:15
infinityMaybe I can try to schedule that before Christmas holidays happen.14:15
pittiinfinity: write that code> argh, but this was years ago or so; don't expect my brain to work _that_ well :)14:16
mvocjwatson, 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
infinitystgraber / xnox: ^^14:17
xnoxmvo: yeah about that.14:18
infinitymvo: Props on revision 5801. :P14:18
pittiinfinity: ok, so I'll sent an RT to get that PPA ddebified14:18
infinitypitti: Which is a PPA that will never be copies to the archive, I assume?14:19
pittiinfinity: b-deping on p-c-d isn't sufficient then?14:19
infinitys/copies/copied/14:19
pittiinfinity: right14:19
xnoxmvo: 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
infinitypitti: There's no need to build-dep on it at all, it's in all the chroots anyway.14:19
pittiwe just need it for some test packages for daisy/apport/juju chamrs14:19
xnoxmvo: since if ubiquity is run offline there isn't much that can be done.14:19
infinitypitti: It just keys off a CurrentlyBuilding twiddle.14:19
mvoxnox: indeed, either way is fine with me14:19
pittiinfinity: right, but I wondered if an RT is mandatory for this14:19
infinitypitti: An RT, or a #webops ping.14:20
xnoxmvo: ok. I will send an email out and CC you on it, such that you are up to date.14:20
mvoxnox: 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 point14:20
infinityelif grep -qs '^Build-Debug-Symbols: yes$' /CurrentlyBuilding; then14:20
infinity    addtofiles="-a"14:20
infinityelse14:20
mvoinfinity: *coug* ;)14:20
mvo(re 5801)14:21
xnoxmvo: 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
mvoxnox: *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
infinityjcastro_: Lack of round tuits.14:23
cjwatsonhttp://people.canonical.com/~cjwatson/cross/armhf/raring/ for the interested/borderline-insane14:23
cjwatson(results of attempting to cross-build all of raring/main from amd64 to armhf)14:24
infinityjcastro_: By which, I assume you mean the archive portion, not the ISOs (which seem to be on old-releases)14:24
infinitycjwatson: Oh joy, this would be where we get our "fix five broken packages" from? :)14:24
cjwatsoninfinity: Aye14:24
jcastro_oh am I looking in the wrong place? http://old-releases.ubuntu.com/ubuntu/dists/14:24
infinityjcastro_: That depends on what you're looking for.14:25
infinityjcastro_: Images, or packages?14:25
jcastro_packages14:25
infinityjcastro_: If you want packages, you're looking in the right place, and correct that they're not archived yet.14:25
infinitycjwatson: Oh, hey, apache2 looks like an easy fix (famous last words).14:27
mdeslaurjcastro_: every time you ask a question like that, I always find out why by looking at askubuntu.com :)14:27
penguin42cjwatson: gawk just seems to be making the mistake of running a test suite on itself14:27
jcastro_mdeslaur: hey it's a legit question!14:27
mdeslaurhehe :)14:27
infinitypenguin42: Yeahp, most of these are simple fixes.  Just lots of them.14:27
cjwatsoninfinity: Possibly, yeah14:28
OdyXpitti, tkamppeter__ : fyi: security fix uploaded for Wheezy / cups 1.5.3 .14:28
penguin42it might work if you installed qemu :-)14:28
cjwatsonpenguin42: Yeah, let's not tell me about all of them14:28
cjwatsonpenguin42: It's deliberate this way14:28
pittiOdyX: thanks muchly for handling this!14:28
cjwatsonpenguin42: You can cross-build more if you use qemu-user-static, yes; but that won't help with bootstrapping arm6414:28
infinitycjwatson: Do you have simple destructions for reproducing the cross build environment?14:28
cjwatsongawk is probably a matter of honouring DEB_BUILD_OPTIONS=nocheck14:29
infinitynocheck, but it should probably also have an if HOST != BUILD guard.14:29
infinityAll testsuites should, IMO.14:29
infinity(Well, all testsuites that run native code)14:29
cjwatsonThen you can't run them under qemu if you have that set up.14:29
cjwatsonnocheck is sufficient, I think - sbuild sets that for host != build at the moment14:30
infinityOh, I suppose.14:30
infinityActually, glibc's is wildly perverse (and works in the qemu case).14:30
infinityIt tests if ld.so can be run. :P14:30
infinitycjwatson: So, yeah, if you have "this is how to reproduce this madness" steps somewhere, I'll pick off a bunch of these.14:32
infinitycjwatson: Since I'm assuming cross-build-whatever doesn't exist in the archive yet, etc.14:32
cjwatsoninfinity: 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-armhf14:32
cjwatsonThat should be close enough for government work, anyway14:32
cjwatsonThen sbuild --build=amd64 --host=armhf -d raring -c raring-armhf blah.dsc14:33
infinityOh, wait, can I just reuse the armhf chroots I already have?14:33
infinity(removing qemu to force failures, I guess)14:33
cjwatsonAre they full of x86 binaries?14:33
infinityNo, they're full of... Oh, --TARGET, not --arch.14:34
infinityDerp.14:34
cjwatsonRight14:34
cjwatson--arch=amd64 --target=armhf in fact14:34
cjwatsonIf you're on an i386 host14:34
infinityWhich I'm not, but yeah.14:35
cjwatsonOh, and please forward fixes to Debian with User: crossbuild@debian.org Usertags: cross14:35
infinityWill 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
tumbleweedyes14:36
infinity(base)adconrad@cthulhu:~$ mk-sbuild --arch=amd64 --target=armhf raring14:37
infinityE: /var/lib/schroot/chroots/raring-amd64 already exists; aborting14:37
infinityIndeed.14:37
cjwatsonYou can use --name=random-garbage or something if you want to make sure14:37
cjwatsonAnd move at the end14:37
infinityWhat should these actually be named when all is said and done?14:37
infinity-amd64-armhf or something?14:37
cjwatsonProbably something like that14:38
infinityWell, I mean, so sbuild finds them magically. :P14:38
cjwatsonI'm using -armhf because I have no native chroots here14:38
cjwatsonI 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 system14:38
infinityI'd certainly like to.14:39
infinityI realise I'm a weird corner case, but I do a lot of native armhf testbuilds on my laptop.14:39
infinityFor now, though, I can stop doing that.14:39
cjwatsonOne other thing: the build coordination is fairly bodgy at the moment, and I'm occasionally prodding it by hand14:39
infinityIt's not like I don't have a bunch of faster-than-qemu ARM kit.14:39
cjwatsonSo it's not *quite* completely automatic14:40
cjwatsonThough it's close14:40
cjwatsonMost of the BD-Uninstallable entries amount to "need to multiarch some stuff"14:40
cjwatsonThe bulk of which is complicated: python, perl, gobject-introspection14:41
cjwatsonThere 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: same14:41
mlankhorstwould 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
cjwatsonQuite a lot of -dev packages are coinstallable14:43
cjwatsonIn such a case I suppose you'd need to think about whether having the union of all installed headers would confuse things14:43
infinityProblematic if headers of the same name end up on the search path in different spots, otherwise generally okay.14:44
mlankhorstprobably not, libdrm_intel.pc would still not be available on arch14:44
infinityIsh.14:44
infinityBut yeah, you need to look at it case-by-case.14:44
mlankhorstso having a global i915_drm.h should be harmless14:45
mlankhorstshrug, I'll try building and find out14:45
infinitymlankhorst: Well, harmless, unless a configure script considers the existence of the header to mean something.14:45
infinitymlankhorst: But this is why we have arch-specific include paths.14:46
=== slank_away is now known as slank
shadeslayerchrisccoulson: I see that you're the one usually uploading ubufox, I was wondering if you know of a way to ship a systemwide firefox profile14:46
mlankhorstonly packages that care about libdrm are mesa and plymouth, and i think they properly use pkgconfig14:46
infinitymlankhorst: Famous last words. ;)14:46
infinitymlankhorst: For MA -dev packages, you really do want the headers in arch-specific paths, IMO, even if they're 99% the same.14:47
infinityThen you avoid worry about if it's a problem.14:47
infinitys/worry/worrying/14:47
mlankhorstmight actually break things though, most are lazy with path..14:47
infinityHrm?14:48
infinityGCC has the paths by default.14:48
infinityPeople 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
mlankhorstshrug we used to build libdrm_intel on arm14:49
infinitymlankhorst: You could follow glibc's lead, and put only arch-specific stuff in arch dirs, but that requires actually paying attention.14:50
infinitymlankhorst: (See 'dpkg -L libc6-dev')14:50
mlankhorstyeah probably will do that, wine build-deps for i386 is a good testcase btw..14:50
mlankhorsttons of -dev without m-a same..14:50
infinityThere's no harm (other than wasted disk space) in just shoving all your headers in the arch-specific path.14:51
infinityIf our toolchain didn't work with that, we'd be pretty screwed already.14:51
mlankhorstconsidering how some utils like to hardcode path for libdrm, would prefer not to change it14:52
infinityWell, wasted disk space, and possibly broken configure scripts, but testing for the latter is just some rdep rebuilds.14:52
dokocjwatson, what do you mean by "fixed'? the linker paths?14:52
infinitymlankhorst: Things hardcode the path to the HEADERS?14:52
cjwatsondoko: Yeah, the -rpath-link thing that we talked about at UDS14:53
cjwatsonOr rather the need for it14:53
cjwatsonI thought Steve was getting you a reduced test case for that?14:53
mlankhorstinfinity: cant remember where I saw -I/usr/include/libdrm though14:54
cjwatsondoko: Oh, possibly it was a cross-toolchain issue that Steve was going to talk with hrw about14:55
infinitymlankhorst: Eww, instead of #include <libdrm/foo.h>?14:55
cjwatsonThere's an item for it on foundations-r-improve-cross-compilation14:55
=== Tonio__ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio__
cjwatsonWhich I'm going to mark done because it's bug 92377914:55
ubottuLaunchpad bug 923779 in armel-cross-toolchain-base (Ubuntu) "cross-linker behaviour differs from native linked" [Undecided,Triaged] https://launchpad.net/bugs/92377914:55
cjwatsonhrw: Have you been able to get anywhere with that bug ^ ?14:56
mlankhorstinfinity: well libdrm fails without $(pkg-config --cflags libdrm) anyway..14:56
infinitycjwatson: Hrm, sbuild seems to want to use my raring-amd64 chroot by default for this.  That's a bit suboptimal.15:03
infinityAhh, I can feed it --chroot15:04
cjwatsoninfinity: Yeah, that's why my directions included -c15:04
infinityBingo.15:04
cjwatson(I have an sbuild-cross wrapper to make it less tedious)15:04
infinityLet's see how this goes.15:04
infinityHrm, except for the odd failure to umount my overlay, that seemed to go well.15:06
dokocjwatson, 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 trick15:06
dokoand the 4.diff is definitely wrong how to derive the multiarch name15:07
cjwatsoninfinity: Not a problem I've seen ...15:08
cjwatsondoko: Oh, so this might just be a matter of updating the -base packages?15:09
cjwatsonAgainst new binutils source?15:09
infinitycjwatson: No, it's a random schroot hiccup, I think.  Trying again.15:09
infinitycjwatson: What's the expected failure mode if I don't do the rpath-link twiddle?15:10
infinityGranted, my testcase of GNU hello was a bit simplistic, but it went fine without.15:10
cjwatsoninfinity: It's in bug 92377915:10
ubottuLaunchpad bug 923779 in armel-cross-toolchain-base (Ubuntu) "cross-linker behaviour differs from native linked" [Undecided,Triaged] https://launchpad.net/bugs/92377915:10
dokocjwatson, given that the toolchain is from april, probably yes15:11
cjwatsonI think it only fails when you have indirect library linkage; hello won't have that15:11
rbasakinfinity: around? Do you remember the conversation a long time ago about update-initramfs parameters when called from flash-kernel-installer.postinst?15:11
rbasakinfinity: 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 fails15:12
rbasakIs the solution just to bump d-i's kernel, or is there a better answer?15:12
rbasakI don't recall the details of that previous conversation and why we went with in-target update-initramfs -c -k $(uname -r)15:12
infinityrbasak: Wait, what's using $(uname -r)?15:14
infinityrbasak: That's going to be wrong more often than right.15:14
* rbasak looks15:14
infinityUgh, f-k-i does?  Eww.15:15
rbasakinfinity: I think it's http://paste.ubuntu.com/1410440/ line 7515:15
rbasakinfinity: IIRC, -k all didn't work or something like that? I'm sure I had a conversation with somebody along these lines15:16
infinityYeah, like I said, f-k-i.15:16
=== Quintasan_ is now known as Quintasan
infinityrbasak: Is this actually causing a problem?  Installing kernel packages should be generating a proper initrd anyway.15:16
rbasakinfinity: there is a problem. I might have the root cause wrong though. ATM, quantal highbank d-i netinst is broken.15:16
infinityOh 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) || true15:17
ogra_it cant cause a problem15:17
ogra_unless 7bin/ture is gone :)15:17
rbasak$(uname -r) doesn't match the installed kernel15:17
rbasakI think that's the issue15:17
infinityogra_: Yes, the problem is that it doesn't generate an initrd. :P15:17
ogra_*/bin/true15:17
infinityThis code is terribly wrong.15:18
infinityrbasak: 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 iirc15:19
infinityogra_: For which "that"?15:19
ogra_finding the latest kernel15:19
ogra_oh15: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 too15:20
infinityogra_: Except that we don't have linux-version in d-i.15:21
ogra_but in the target15:21
infinityOh, fair point.15:21
ogra_needs some chrooting etc15:21
infinityThat'd do the trick, then.15:21
ogra_but essentially just replacing uname -r with the value of $ latest_version should do15:21
infinityI do wonder if it's intentional that -c -k all doesn't work.15:22
infinityLet me dig into that.15:22
ogra_i think it is15:22
ogra_at some point in time -u did just work for creating them15:22
ogra_was so much easier15:22
mvostgraber: \o/15:24
infinityogra_: Reading the code, '-c -k all' should work.15:25
rbasakPlease 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 all15:26
ogra_iirc i tried it back then with rbasak and it didnt for him15:26
infinityogra_: 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 105648215:27
ubottuLaunchpad bug 1056482 in flash-kernel (Ubuntu) "/dev/mmcblk0p1 is not a block device when installing flash-kernel" [Undecided,Fix released] https://launchpad.net/bugs/105648215:27
rbasakit looks like I tried -k all a minute ago and it didn't work, but I'm going to reproduce from scratch to make sure15:27
rbasakWill be about 15 minutes I think15:27
* cjwatson greps old IRC logs15:27
cjwatsonI remember talking about this15:27
* ogra_ too15:27
ogra_bug 103526915:29
ubottuLaunchpad bug 1035269 in The Eilt project "highbank quantal installer regression" [Critical,Fix released] https://launchpad.net/bugs/103526915:29
infinityOh, hahahaha.15:29
ogra_thats it15:29
infinityOkay, so "-c -k all" totally rexec with "-c -k $ver" for all versions.  But the version list is from the state dir.15:29
infinityWhich is empty if you have no initrds.15:29
infinityThat should be fixed, but not for an SRU.15:29
ogra_funny15:29
infinityFor 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
infinityogra_: Yeah, this is for Q.15:30
cjwatsonNot as explicit as I remember15:30
infinityogra_: Where d-i/kernel skew is breaking ARM installers.15:31
* ogra_ isnt sure we had the f-k dep on linux-version back then15:31
ogra_have to check15:31
ogra_ah, yeah, its 3.0, we should15:31
infinityIt's basically the same version.15:31
infinityR's only one revision ahead.15:31
stokachutjaalton: awesome! thank you so much15:32
ogra_k15:32
infinityogra_ / 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
infinityIf it works, sure. :P15:33
* rbasak will try it in a moment15:33
* ogra_ wonders if the pipe will behave15:33
ogra_cjwatson, there must be something older15:36
ogra_flash-kernel (3.0~rc.4ubuntu20) quantal; urgency=low15:36
ogra_* seemingly -k all doesnt want to work with -c, use -k $(uname -r) for now15:36
ogra_ -- Oliver Grawert <ogra@ubuntu.com>  Fri, 10 Aug 2012 18:29:34 +020015:36
ogra_we surely discussed it before the upload date15:37
cjwatsonYeah, I failed to find it15:37
infinityogra_: 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
infinityogra_: 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
rbasakhttp://irclogs.ubuntu.com/2012/08/10/%23ubuntu-devel.html#t15:09 perhaps?15:41
ogra_heh awesome15:43
ogra_and it has the answer for my "in-target" question from above ... cjwatson pro-actively answered it back then already15:44
rbasakRunning two in-targets in a pipeline screwed up. I guess it's trying to do the setup and teardown twice concurrently15:44
cjwatsonYeah, I can believe that15:44
cjwatsoneither use a temporary variable or use   in-target sh -c '...'15:45
ogra_yeah, was just looking at the latter15:46
rbasakEverything seemed to stop working so rather than poke I just set off a reinstall15: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 that15:47
cjwatsontail -n1 please15:49
cjwatsonmay as well be POSIXy15:49
ogra_k15:50
rbasakack15:50
cjwatsonrbasak: command not executed> I think that's what you get if you omit the sh -c?15:50
cjwatsonOh, no15:50
cjwatsonThat's if chroot_setup fails15:51
cjwatsonSo, yeah, reboot :)15:51
infinityTemp variables are way more readable than nested sh -c15:51
rbasakcjwatson: 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 environment15:51
cjwatsonIt's rescueable by hand but not worthit15:51
rbasakYeah15:51
* ogra_ grumbles about linux-version 15:54
ogra_why doesnt it just ahve a --latest option15:54
infinityBecause it hates your freedom.15:57
ogra_heh15:57
rbasakogra_: a couple of minor corrections: latest_version=$(in-target --pass-stdout sh -c 'linux-version list | linux-versi15:57
rbasakon sort | tail -n1')15:57
ogra_oh, right, forgot about --pass-stdout15:58
rbasakthis 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
cjwatsonHeh, yes, I should have spotted that15:58
* rbasak learned about --pass-stdout the last time round15:58
infinityrbasak: 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
infinityrbasak: Since we know that one exists. :P15:59
* rbasak tries15:59
rbasakThough I wonder. Will f-k-i.postinst ever run with two kernel installed, OOI?15:59
ogra_rbasak, pretty unlikely but you never know16:01
cjwatsonOn 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 linker16:01
rbasakI've broken something. Is this because I used in-target apt-get install instead of apt-install?16:02
infinityOh, maybe.16:03
* rbasak reboots again16:04
ogra_btw, why dont we have the kernel version exported in some variable or sitting in some preseed value we could ask16:04
ogra_(by the code that selects the right kernel during installation i mean)16:06
infinityYou 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
infinityPlus, also fails with different installer types.16:09
infinitySo, don't do that. :P16:09
ogra_yeah, i was more thinking about a preseed template from base-installer or so16:09
ogra_it already has a bunch of kernel things16:10
ogra_well, rather initrd16:11
ogra_oh !16:15
ogra_base-installer/kernel/image16:15
ogra_i wonder if we could rely on that16:15
cjwatsonWon't work for server images which use live-installer16:16
ogra_ah, indeed16:16
rbasakOK it works for two kernels too16:18
rbasakTested from the network console shell thing16:18
ogra_great16:18
rbasaklatest_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 minute16:20
rbasakogra_: bug 108410616:23
ubottuError: Launchpad bug 1084106 could not be found16:23
rbasakIt's private but I'll make it public in a moment16:24
ogra_http://paste.ubuntu.com/1410585/16:27
ogra_just a final cross check16:27
infinityThat || true there annoys me.16:28
infinityFine for the SRU, since it was there before anyway.16:28
infinityBut... If that fails, the system likely won't boot. :P16:28
ogra_well, thats raring atm16:28
infinitySeems silly to short it.16:28
ogra_let me drop it there then16:28
ogra_(note that one comes from debian)16:28
infinityKeep it in Q, on the off chance it had a purpose I can't divine.16:28
infinityBut, yeah, drop it in R. :P16:29
infinityAnd we'll find out!16:29
ogra_in-target update-initramfs -u || true16:29
ogra_thats the original line16:29
rbasaklgtm. Unless the version has spaces in it :-P16:29
infinityrbasak: That would be a neat trick.16:29
ogra_hard to do :)16:29
unshadowHi 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 setup16:30
infinity*rimshot*16:30
ogra_most are using a 5,1 one nowadays though16:30
infinityunshadow: And yes, this is the wrong channel for that.16:30
infinityOh look, our first build failure in the shiny new daily-upstart PPA.16:31
infinityOff to a great start.16:31
infinityjodh: *slow clap*16:31
jodhinfinity: you spotted it, so you get to help fix it :)16:43
infinityjodh: If by "spotted", you mean "got emailed about it", sure.  I spotted it.  As did all your teammates. ;)16:44
infinityjodh: Public shame fixed many bugs.16:44
infinitys/fixed/fixes/16:44
jodhinfinity: share the love I say16:44
jodhinfinity: 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
infinityBAD: wrong content in file 0x95464e0 (output), expected 'UPSTART_INSTANCE=16:48
infinity' got 'PWD=/16:48
infinity'16:48
infinityat tests/test_job_process.c:682 (test_run).16:48
infinityThat's some failure.16:48
jodhinfinity: something is causing the environment to be different to that expected. It w16:50
infinitySeems odd to be that strict about what you expect the environment to be.16:50
infinityI'd call that a broken test.16:50
infinityAssuming 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
jodhinfinity: 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
infinitySo, it's actually a bug to have PWD in the env?  Hrm.16:53
jodhinfinity: no - it's a bug to have PWD in the environment array at that index.16:53
jodhinfinity: I think I've just worked out what is causing this behaviour! Thanks for being the sounding board :)16:56
infinity:P16:57
=== allee_ is now known as allee
=== deryck is now known as deryck[lunch]
arosenzul: you aroudn?17:44
zularosen: in a meeting17:45
zularosen: should be available about in a hour17:45
natschilHello. Does the program that mounts things in nautilus for ubuntu completely ignore fstab?17:50
natschilI 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
mspencerpitti: png re. bug 65727517:54
ubottuLaunchpad 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/65727517:54
pittislangasek: actually, I think "set gnutarget elf32-littlearm" might just work; thanks for this!17:54
pittimspencer: hello17:54
mspencerpitti: 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
mspencerpitti: 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
mspencerpitti: The UserInterface.ui_question_file function only shows an open file dialog.17:59
cjwatsondoko: 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
cjwatsondoko: Was that the version you were looking at?18:00
pittimspencer: it doesn't need to use the ui_question_file() method, that's only for hooks18:01
pittimspencer: well, of course you can use it if it works for you; I thought you could set a title there?18:01
pittimspencer: so I think it's best for now to add new Gtk.* code to the place where you do the saving18:02
natschilAnybody 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
slangasekpitti: really?  I still didn't get it working here, glad it's working for you :)18:03
mspencerpitti: Don't I need to use the ui_ methods so it works with the apport-cli and apport-gtk?18:03
sarnoldnatschil: 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 mounting18:03
pittislangasek: at least the output now is identical for both qemu-arm gdb and gdb-multiarch18:04
sarnoldnatschil: I think all the programs it runs are in /lib/udev/18:04
slangasekpitti: huh, would love to see the full command you're running18:04
pittimspencer: yes, if you want to implement it in those other two UIs as well18:04
mspencerpitti: Yes, the title can be set, but the button says 'Open' and there is no place to type a file name.18:05
pittislangasek: 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-seeds18:05
sarnoldmspencer: iirc, some dialogs don't show a place to type until you've started typing18:05
natschilsarnold: Of course udev is involved somewhere, but it isn't what's responsible for the mounting.18:06
pittislangasek: so that we can use those for testing retracer rollouts, daisy branches, etc18:06
pittislangasek: I now took the "sleep 10" raring core dump18:06
natschilsarnold: I know this because I created an udev rule to set MODE to something permissive, but that changed nothing.18:06
pittislangasek: but otherwise the exact same command line as yesterday18:06
sarnoldnatschil: oh, damn :/18:06
natschilI 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
pittislangasek: it's still not a "good" trace, though, I need more armhf ddebs18:08
slangasekpitti: hmm, same commandline but different test case?  Because I still get 'wrong size gregset struct in core file' unconditionally18:09
mspencersarnold: But where the File chooser dialog is created the type defaults to an Open dialog.18:10
pittislangasek: 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 PPA18:11
mspencerpitti: 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
sarnoldmspencer: so it's not just a misleading title then :(18:14
mspencersarnold: No, this is actually an Open dialog.18:14
sarnoldmspencer: sorry for the distraction then :)18:16
pittimspencer: yes, if you want to implement it in all three, this would make most sense18:16
mspencerpitti: That's what I'll do, thanks for your advice.18:18
cjwatsonnatschil: udisks2 in current versions of Ubuntu; I don't know the details of how you might remove showexec though, so this is just a pointer18:20
natschilcjwatson: http://www.kirsle.net/blog/kirsle/rant--arrogant-developers suggests that the options have become hardcoded18:20
slangasekpitti: sorry, I'm still not following how you got this to work; I'd really like to understand why I got stuck here18:21
cjwatsonnatschil: 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
natschilcjwatson: the reason: exposing mount options to end users is apparently not a useful thing to do18:21
natschilthe arrogance.18:21
natschilit astounds me.18:21
cjwatsonThe code does not seem to bear that out.18:21
cjwatsonAt least not entirely; there is definitely some degree of support for configuration there.18:22
evbdmurray: http://www.mariterra.co.uk/page/location18:22
cjwatsonI 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
natschilcjwatson: but where? neither gconf nor dconf editors seem to show anything of that sort.18:22
natschilcjwatson: I think I will download the source code.18:23
cjwatsonIt at least seems to be trying to pick some of it up from fstab ... perhaps it's picky18:23
cjwatsonAnyway, I'm not going to stare at this any longer :)18:23
pittislangasek: for the xeyes crash it looks like this now: http://paste.ubuntu.com/1410821/18:23
natschilcjwatson: probably. Those developers are idiots18:23
cjwatsonnatschil: Please take the rants elsewhere.18:23
cjwatsonThey are not appropriate here.18:23
natschilcjwatson: 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
pittislangasek: and with "qemu-arm -L /tmp/sandbox usr/bin/gdb" I'm getting an identical trace18:26
cjwatsonnatschil: 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-devel18:26
slangasekpitti: oh, cool; so there was just a problem with that particular test case we were working with yesterday18:26
slangasek(the nux one)18:26
pittislangasek: at least I hope so, yes18:27
pittiraring armhf ddeb indexes are back, BTW18:27
pittiquantal's should be produced over night18:27
natschilcjwatson: 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
cjwatsonIt hasn't been called devicekit for quite a while ...18:28
slangasekpitti: sweet18:28
natschilcjwatson: 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
cjwatsonAnd we use UUIDs absolutely everywhere in Ubuntu, so I do not think that this is a systemic failure18:29
cjwatsonIt is often useful to distinguish between "fails for me" and "fails for everyone"18:29
cjwatsonThis is a developer channel, not user support, so please take a more productive line18:29
natschilcjwatson: what is it called nowadays?18:29
cjwatsondevicekit-disks became udisks became udisks218:29
cjwatsonish18:29
pittislangasek: 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 more18:30
* cjwatson -> dinner18:31
=== deryck[lunch] is now known as deryck
slangasekpitti: 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
infinityxnox: FWIW, you can stop fretting about iptables, the latest kernel upload fixes it (see the successful powerpc retry)18:59
slangasekmlankhorst: 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
seb128slangasek, 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
slangasekseb128: hmmm, we ought to fix it19:46
seb128slangasek, that's https://bugs.launchpad.net/bugs/1034090 for which I uploaded a SRU fix today19:46
ubottuLaunchpad 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
slangasekwell, by "fix" I mean either that the incompatibility needs to be reverted *or* an update like g-s-d is needed, yeah19:47
seb128slangasek, right, the fix is in the queue, I'm wondering if we should ensure both get updated in locked steps in some way19:47
slangasekin the latter case, there should also be a breaks19:47
seb128so xserver-xorg-lts-quantal needs to Breaks gnome-settings-daemon (<< 3.4.2-0ubuntu0.6.1)19:48
seb128http://launchpadlibrarian.net/124872994/gnome-settings-daemon_3.4.2-0ubuntu0.6.1_source.changes19:48
seb128is the upload19:48
seb128there 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
mlankhorstslangasek: it's required for -nc to work19:51
mlankhorstelse it will fail to start19:51
slangasekmlankhorst: and that's something that's relied on by some software in precise?19:51
mlankhorstyeah19:51
slangasekmlankhorst: 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
mlankhorstslangasek: well I tend not to explain those specific things since I autogenerate the entire stack19:53
=== henrix is now known as henrix_
slangasekmlankhorst: ok - I'm not really happy about changelogs being autogenerated, but we'll roll with it.  how about the Breaks, then?19:55
mlankhorstentire stack is generated by running xorg-pkg-tools/lts-stack, I'll take a look at the breaks..19:55
slangasekmlankhorst: 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
seb128slangasek, mlankhorst: thanks19:55
mlankhorstslangasek: might be best to accept the current version to build the rest, then I'll reupload?19:56
slangasekmlankhorst: yep, fine with me19:56
mlankhorstand the script is automated because it's the only way I prevent human mistakes from being a problem :/20:00
slangasekmlankhorst: 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
mwhudsonhm20:12
mwhudsonwhat is stdin for an upstart job?  /dev/null?20:12
slangasekunless you use a different 'console' option, yes20:13
slangasek(or use a redirect in the script itself)20:13
mwhudsonwell yes, the latter point had occurred to me :-)20:14
mwhudsonhmm20:15
mwhudsonalthough this upstart job says "console output:20:15
mwhudsonoh nevermind20:16
slangasekin that case, IIRC stdin is also attached to the console20:16
mwhudsonit's other bits of my code doing something odd20:16
mwhudsonslangasek: yeah, that's what the docs say20:16
mwhudsoni think i am just going to go and hate bash a bit, brb20:16
mwhudsonwhile read line ; do20:19
mwhudsoner mischan20:19
=== glebihan_ is now known as glebihan
argeswhats the process for adding a patch to a package that doesn't have a patch system set up yet?20:47
penguin42arges: I just had a look at edit-patch, I wondered whether that might set ione up, but it doesn't seem to20:51
argespenguin42, 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
slangasekcyphermox: 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
cyphermoxah, it does. In the file I wrote that it will be listed in /var/log/syslog when NM changes it21:09
cyphermoxif you want to query it, it's sending a USR1 signal to dnsmasq21:09
slangasekcyphermox: USR1 causes dnsmasq to echo it to syslog?21:09
cyphermoxyes21:09
cyphermoxit causes dnsmasq to write statistics data to syslog, and that includes the servers21:09
infinityHuh, so it does.21:10
infinityHandy.21:10
* infinity tries to remember that for when it'll be useful.21:10
cyphermoxindeed. it's documented in the manpage, not sure if there should be more obvious docs for this21:11
cyphermoxslangasek: seen the other SRU for dnsmasq though, since it's required for these changes?21:13
cjwatsonarges: 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
argescjwatson, ok i'll do that then for bug 1071209 . thanks22:20
ubottuLaunchpad bug 1071209 in memtest86+ (Ubuntu Raring) "memtest86 test #7 false positives (random number sequence error)" [Medium,In progress] https://launchpad.net/bugs/107120922:20
cjwatsonarges: Yes.  If you look at memtest+'s .diff.gz, you'll see it already has some patches applied this way.22:21
argescool fixing it now22:22
=== cpg|away is now known as cpg
dokocjwatson, 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
cjwatsondoko: Um, you mean about -cross-toolchain-base?  Right now I'm not looking at the arm64 cross-toolchain at all, only armhf23:39
stgraberhallyn: 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
slangasekstgraber: why's this?23:47
stgraberhallyn: 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 starting23:47
stgraberslangasek: ^ that's why23:47
slangasekcyphermox: SRU for dnsmasq> hmmm no, sorry, my question came from a completely different context of resolvconf bug reports23:48
stgraberbasically 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
cyphermoxslangasek: ok..23:48
stgraberwe 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 sequence23:48
slangasekstgraber: console* and setvtrgb don't happen pre-virtualfilesystems; and I would assert that suppressing plymouth and ureadahead in a container is a wrong fix23:50
slangasekstgraber: 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 handling23:52
slangasekstgraber: so, can you please file a bug against plymouth about this :)23:53
stgraberwell, 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 pts23:54
slangasek"containers aren't allowed to access block devices" - not universally true :)23:55
slangasekand 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 contexts23:56
stgraberslangasek: so, I have plymouthd running, how do I get it to show me something?23:56
slangasekstgraber: did 'plymouth show-splash' get called?  (/etc/init/plymouth-splash.conf)23:57
stgraberslangasek: I called show-splash manually, so yeah23:58
slangasekstart plymouthd; call 'plymouth show-splash'; then call, e.g., 'plymouth ask-for-password --prompt 'open sesame: '23:58
stgraberok, the ask-for-password just returns and nothing is shown on /dev/lxc/console (my current tty)23:59
slangaseker, ok, that's weird23:59
slangasek(and a bug)23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!