[00:29] <Muchachao> hi guys
[01:43] <ScottK> Noskcaj: I didn't merge it.  I did a mistaken sync.
[02:41] <saiarcot895> Are the official armhf Ubuntu builders running on native hardware or is it emulated?
[03:01] <slangasek> juliank: has bug #753682 been *properly* fixed now?
[03:01] <slangasek> juliank: I have a staged merge of gnu-efi, but was waiting for resolution of this bug
[05:37] <pitti> Good morning
[05:53] <pitti> RAOF: hey Chris
[05:53] <pitti> RAOF: do you have 5 mins to review/accept the postgresql SRUs (lucid/precise/trusty)? people keep pinging
[06:01] <RAOF> pitti: Howdie.
[06:57] <dholbach> good morning
[06:59] <dholbach> Noskcaj, can you please take a look at jquery, python-wsme and libgtop2 is still unresolved as well
[07:17] <Noskcaj> dholbach, I've looked at wsme, will get to the others soon
[07:17] <dholbach> thanks Noskcaj
[07:18] <Noskcaj> wsme breaks trying to debuild -S for me, and we should have had those depends since three versions ago
[07:18] <Noskcaj> The old delta was more than i realised
[07:20] <zyga> good morning
[07:50] <dholbach> Noskcaj, what's breaking?
[07:51] <dholbach> Noskcaj, the problem with the (build)depends is that some are in main and some are in universe - so if we want them in main, we need to follow https://wiki.ubuntu.com/MainInclusionProcess and maintain them in main
[07:51] <Noskcaj> dholbach, It says a heap of files have been modified, no matter what i do
[07:52] <Noskcaj> I understand the problem (have done MIRs before), i've not got time to really look into it till school tomorrow ;)
[07:53] <dholbach> ok... I was just commenting on "we should have had those depends since three versions ago" :)
[07:56] <dholbach> Noskcaj, if you get -3 from from proposed and install all (new) build-deps, "debuild -S -us -uc" should work
[09:01] <pitti> hey jodh, good morning
[09:09] <jodh> pitti: hi
[09:46] <rbasak> jamespage: is anyone taking care of the haproxy component mismatch?
[09:47] <rbasak> Maybe just delegate haproxy-doc to universe?
[09:47] <rbasak> relegate
[10:08] <jamespage> rbasak: not that I am aware of
[10:08] <jamespage> rbasak: its a new js depends right?
[10:16] <flexiondotorg> cjwatson, Can you tell me where I can find the code (file/library) that actually masters the official sanctioned Ubuntu flavour isos?
[10:16] <cjwatson> flexiondotorg: lp:ubuntu-cdimage is the top level
[10:16] <flexiondotorg> I had a quick grep of lp:ubuntu-cdimage
[10:16] <flexiondotorg> File?
[10:16] <cjwatson> etc/crontab
[10:16] <cjwatson> I'm not going to walk you through it file by file, but you can trace it from there
[10:17] <cjwatson> It calls out to Launchpad to build live filesystems (squashfs, etc.)
[10:17] <rbasak> jamespage: yeah, but looks like it's only for haproxy-doc.
[10:17] <rbasak> Unless I missed something.
[10:17] <cjwatson> The top level of that is in lp:launchpad-buildd, basically lpbuildd/livefs.py
[10:17] <flexiondotorg> What does it use to make the iso mkisofs or xorriso?
[10:17] <flexiondotorg> I'm just looking for how it is invoked.
[10:17] <cjwatson> xorriso nowadays
[10:18] <cjwatson> that stuff is in the debian-cd branch linked from configs/devel in lp:ubuntu-cdimage
[10:18] <flexiondotorg> cjwatson, Thanks.
[10:18] <cjwatson> CONF.sh, tools/boot/utopic/*
[10:19] <jamespage> rbasak: indeed it is only the docs
[10:19] <rbasak> jamespage: so, docs to universe? I can't see anyone wanting that in production anyway.
[10:20] <jamespage> rbasak:sure
[10:43] <pitti> mlankhorst: do you have a wiki page/spreadsheet/similar where you collect feedback for the new X.org in the PPA?
[10:44] <pitti> mlankhorst: I just upgraded/rebooted, and so far unity, video, glxgears, external  monitor are fine, I don't notice any difference
[10:44] <mlankhorst> pitti: I'm asking for emails for now, easiest way :P
[10:44] <pitti> mlankhorst: ack, I'll mail you on Friday or so, when I've run them for some time
[10:49] <cjwatson> jibel,pitti: I don't suppose it would be possible to get an extra autopkgtest executor or two?  The queues seem to have been backed up somewhat of late
[10:50] <pitti> cjwatson: it would be much more helpful if qemu wouldn't freeze all the time with current guest kernels :/
[10:51] <pitti> the current retry-o-mania after wasting an hour or so is a nuisance
[10:52] <jibel> the timeout is 50min when the kernel upgrade freezes :(
[10:52] <pitti> cjwatson: not sure if we can easily get more hardware in the lab; a better option would be to switch to using HP cloud instances, vila is currently working on that (not in the context of -proposed testing, but it's not too different)
[10:52] <pitti> jibel: it's not just kernel upgrades, I've seen it on other dist-upgrades to proposed, to
[10:52] <pitti> o
[10:53] <cjwatson> OK, well thought it was worth asking
[10:55] <pitti> jibel: or at least I thought I did
[10:55] <jibel> pitti, we could decrease install timeout
[10:56] <pitti> jibel: 20 or 30 mins would certainly do, too; but large packages like libo certainly take some time to fetch/download/install their deps
[10:56] <pitti> jibel: we could try with 20, and if we see "honest" timeouts with that, we'll increase again?
[10:58] <jibel> pitti, 20 min sounds good. LO fails all the time anyway. maybe the kernel itself will be a problem.
[10:58] <pitti> jibel: I suppose it happens with the kernel upgrade as they are particualrly big or have lots of files (linux-headers); it doesn't even get to rebooting the VM, so I think it's rather dying on I/O errors?
[10:58] <pitti> jibel: no, kernel should be fine; build timeout is 100.000 s
[10:58] <pitti> jibel: --timeout-install is just for dist-upgrade to -proposed and installing the test deps
[10:59] <pitti> jibel: btw, the other day I tried to reproduce that locally, but I never saw qemu freeze
[10:59] <pitti> jibel: it downloads the -proposed bits, reboots to the -proposed kernel, and happily goes on
[11:02] <pitti> jibel: http://paste.ubuntu.com/7903813/ ?
[11:10] <flexiondotorg> cjwatson, Other than the slightly different xorriso configuration for amd64+mac iso, is there anything significantly different in the iso contents?
[11:11] <doko_> Sweetsha1k, https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859 needs a MIR
[11:29] <Sweetsha1k> doko_: should that read "libixion (b-d of libreoffice)"? otherwise that subject doesnt make too much sense to me ...
[11:30] <doko_> Sweetsha1k, no, liborcus, see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[11:31] <cjwatson> flexiondotorg: http://askubuntu.com/a/40480/3228
[11:31] <Sweetsha1k> doko_: ah, ok. It starts to make sense now. ;)
[11:33] <jibel> pitti, +1
[11:57] <pitti> jibel: committed; can you roll this out, s'il te plaît ?
[12:14] <jibel> pitti, done, I also disabled 'set -x' at the end of the script to stop polluting the console with a list of packages
[12:14] <om26er> Hi! I was not able to find ubuntu's packaging branch for accountsservice, can anyone link please ?
[12:17] <om26er> the one i found is 2 years old https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/accountsservice/utopic
[12:20] <pitti> xnox: is bug 1320534 still an issue for you? I've used schroots for weeks under systemd
[12:21] <xnox> pitti: well, i just removed /dev/shm mount.
[12:21] <xnox> pitti: do you have /dev/shm in your sbuild/schroot under systemd?
[12:22]  * xnox does clean run test.
[12:22] <pitti> I wouldn't know why not, but let me try again
[12:23] <xnox> om26er: use source package + debdiff workflow $ pull-lp-source accountsservice, modify / add new changelog entry, generate source package and debdiff the two *.dsc, attach a patch to a bug report on launchpad.
[12:23] <xnox> om26er: there are pleaora of packages that are not available as branches.
[12:23] <pitti> jibel: oh, I'm just dist-upgrading a local VM: unpacking linux-headers indeed takes awfully long and pretty much kills the VM
[12:23] <xnox> om26er: what specifically do you want to modify in accountsservice?
[12:24] <pitti> jibel: but that's without an overlay on memory but onto the actual disk
[12:24] <om26er> xnox, I want to backport this fix https://bugs.freedesktop.org/show_bug.cgi?id=78279
[12:25] <om26er> xnox, It allows me to write to accountsservice over ssh, right now its not allowed.
[12:25] <xnox> om26er: well, create a debdiff as per above and open a bug on launchpad (if there isn't one already) and attach patch to it.
[12:27] <om26er> xnox, I will propose to the ubuntu's source branch, which I assume is the same ?
[12:31] <xnox> om26er: no, there is no source branch for ubuntu that matches the archive.
[12:32] <xnox> om26er: archive is authoratative, please create a patch on the bug report.
[12:32] <om26er> xnox, aah, ok, I will attach the debdiff then
[12:32] <doko> tseliot, are you aware of https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.96.1 ?
[12:32] <xnox> om26er: both patches and branches end up in the same sponsors review queue.
[12:33] <om26er> xnox, I'll try with a patch pilot to get it landed early.
[12:33] <pitti> xnox: oh, /dev/shm is not bind-mounted by default, I see; I now booted systemd, uncommented /dev/shm/ from /etc/schroot/default/fstab, now I have /dev/shm/ in my sid schroot
[12:33] <pitti> tmpfs on /var/lib/schroot/mount/utopic-amd64-8e585e3f-4774-431e-87d8-f0afdb607c60/dev/shm type tmpfs (rw,nosuid,nodev)
[12:33] <tseliot> doko: err... I hadn't noticed. pitti ^ ImportError: No module named 'aptdaemon.pkutils'
[12:34] <tseliot> pitti: does it look familiar? https://launchpadlibrarian.net/177412602/buildlog_ubuntu-utopic-amd64.ubuntu-drivers-common_1%3A0.2.96.1_FAILEDTOBUILD.txt.gz
[12:35] <pitti> tseliot: no, not at all; supposedly something in aptdaemon changed?
[12:35] <tseliot> it seems like it
[12:35] <xnox> pitti: hm, not /etc/schroot/default/fstab, but rather it is the default in /etc/schroot/sbuild/fstab and it's not a bindmount but a fresh tmpfs.
[12:36] <xnox> pitti: and mounting/creating a tmpfs fails when booted under systemd.
[12:36] <xnox> tmpfs           /dev/shm        tmpfs   defaults        0       0
[12:37] <pitti> xnox: ah, that's different then; /me tests that
[12:38] <pitti> xnox: how do I tell a schroot to use the sbuild profile?
[12:38] <doko> who is currently caring about qtbase-opensource-src ? needs a merge from Debian
[12:39] <xnox> doko: that would be Mirv i think.
[12:39] <doko> not online
[12:39] <pitti> xnox: err sorry, above line is already a tmpfs mount, not a bind mount
[12:39] <pitti> xnox: so sbuild would automatically use the "sbuild" profile, while "schroot" would use "defualt"?
[12:39] <xnox> doko: oh, qt4? probably ScottK, Mirv, Riddell, or myself...
[12:39] <doko> no, qtbase-opensource-src
[12:39] <ScottK> xnox: That's Qt5.
[12:40] <ScottK> Or mitya57
[12:40] <xnox> pitti: i'm fuzzy as to how the profiles are selected =) but yeah, changes to sbuild thingy make sbuild use those options.
[12:40] <xnox> pitti: hence on the bug report, i've attached the failed sbuild log
[12:41] <pitti> xnox: ah, there's a profile= option for chroot.d/*
[12:41] <pitti> xnox: ok, now I get it
[12:41] <xnox> doko: what specifically needs merging? there is a point release jump there....
[12:42] <doko> xnox, yes, the point release. there are a lot of dep-waits
[12:42] <xnox> *sigh* ok.
[12:46] <pitti> xnox: hah, mystery solved. Followed up
[12:48] <tseliot> doko, pitti: aptdaemon.pkcompat seems to be a little broken: http://pastebin.ubuntu.com/7904535/
[12:49] <doko> barry, could you provide the MIR's for LP: #1349832 ?
[12:49] <xnox> pitti: so..... mk-sbuild should be fixed? or should add /dev bind-mount to sbuild profile?
[12:49] <xnox> ... or both?
[12:50] <pitti> xnox: I suppose the symlink is a consequence of https://wiki.debian.org/ReleaseGoals/RunDirectory
[12:50] <pitti> xnox: you could change your sbuild fstab to bind-mount /run/shm instead
[12:50] <pitti> xnox: or just rbind-mount the whole /dev/
[12:51] <pitti> /dev/shm/ isn't in /etc/schroot/sbuild/fstab by default, so I don't see how to fix the package
[12:51] <pitti> perhaps adding a commented-out bind mount if that's a common case?
[12:51] <xnox> pitti: why does it work when booted with upstart?
[12:52] <xnox> pitti: is /run/shm missing?
[12:52] <xnox> pitti: is /run/shm missing? under systemd that is?
[12:52] <pitti> jdstrand: (really you this time :) ) I'd like to do bug 1341083; as ufw is also in Debian (but older), how wuold you like to handle this? I upload to Ubuntu and when you update Debian you take the Ubuntu package? or submit someplace else?
[12:52] <doko> barry, xnox: wait, why was python3-venv seeded?
[12:53] <pitti> xnox: under systemd /dev/shm/ is the actual mount, and /run/shm doesn't exist (in git a symlink to /dev/shm/ was added)
[12:53] <doko> we really don't want pip in main
[12:53] <pitti> xnox: but in general stuff uses /dev/shm/, and /run/shm/ should be phased out
[12:54] <xnox> doko: did i over-seed it?! =)
[12:54] <pitti> where "stuff" is really just "libc"
[12:54]  * xnox checks
[12:54] <xnox> pitti: and breaking everyones existing sbuild chroots setup with mk-sbuild =)
[12:54] <xnox> pitti: is symlink to /dev/shm in systemd in utopic-proposed?
[12:55] <pitti> xnox: why everyone's?
[12:55] <jdstrand> pitti: if you file a Debian bug and point to the Ubuntu bug, that would be good
[12:55] <pitti> xnox: no, not yet; if it helps I can cherry-pick that, but AFAICS this wouldn't change this bug
[12:55] <pitti> jdstrand: do you want me to just upload (after testing, of course), or a MP?
[12:55] <jdstrand> pitti: I can also do the upload to Ubuntu if there is a debdiff
[12:55] <xnox> pitti: for the past 5 years or so mk-sbuild was recommended and preffered way to setup sbuild chroots advertised to all developers. I understand that you probably set them up some old-school way =)
[12:55] <jdstrand> pitti: an mp would be fine
[12:56] <pitti> xnox: yes, that's what I use as well
[12:56] <xnox> pitti: horum.
[12:56] <pitti> xnox: but /dev/shm/ isn't in sbuild/fstab by default, so I wonder why this breaks everyone's setups?
[12:56] <cjwatson> I've been using mk-sbuild and deleting the profile=sbuild bit for some time :)
[12:56] <pitti> yeah, me too
[12:56] <jdstrand> pitti: I would like to examine the unit file, both for my own edification and to make sure I understanding what it is doing
[12:56] <xnox> pitti: i'm confused a little. let me try something out here.
[12:56] <pitti> jdstrand: ack; I'll just attach it to the Ubuntu bug then?
[12:57] <jdstrand> pitti: sound sperfect
[12:57] <pitti> jdstrand: cheers
[12:57] <jdstrand> typo notwithstanding :)
[12:57] <jdstrand> pitti: thanks!
[12:57] <pitti> jdstrand: I suppose the Debian package has an init.d script, so it's not that important there; but a native unit is still nicer
[12:58] <jdstrand> pitti: it does-- there is logic in debian/rules on which to use
[12:58] <pitti> jdstrand: ah, we should install the init.d script in either case though, for proper LSB dependencies
[12:59] <pitti> otherwise a sysvinit script could never depend on ufw (not sure whether that has a practical meaning, but still)
[13:02] <jdstrand> pitti: that handling is many years old, so I don't doubt it should be fixed, especially in light of recent changes
[13:03] <doko> xnox, removed
[13:05] <doko> bdmurray, cjwatson, slangasek: please subscribe foundations to python-idna and python3-dateutil bug reports
[13:06] <cjwatson> doko,bdmurray,slangasek: done
[13:16] <barry> doko, xnox didn't know it was seeded.  all straightened out now?
[13:17]  * barry sees it was via email
[13:25] <doko> barry, yes
[13:25] <tvoss> pitti hey there
[13:27] <om26er> xnox, looks good https://launchpadlibrarian.net/181062108/debdiff.patch ?
[13:27] <om26er> attached to https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1349813
[13:37] <doko> tvoss, any update on LP: #1349834 ?
[13:37] <tvoss> doko, haven't gotten to it, yet. I plan on patching out those build-deps from net-cpp
[13:38] <xnox> om26er: looks good, assigned for pitti to review =)
[13:39] <pitti> jdstrand: attached, working well now and the packaging got quite a bit simpler
[13:39] <pitti> tvoss: hello
[13:40] <jdstrand> pitti: thanks! :)
[13:40] <om26er> xnox, thanks.
[13:40] <pitti> om26er, xnox: yes, LGTM
[13:40] <tvoss> pitti, un-"hello there" :)
[13:41] <pitti> tvoss: /me undoes the warm handshake and hug then, too!
[13:41]  * tvoss still hugs pitti
[13:45] <tseliot> pitti: I have a one line patch for aptdaemon which fixes the issue http://paste.ubuntu.com/7904992/
[13:45] <tseliot> pitti: shall I proceed with the upload? Do I have to update some bzr tree after that?
[13:46] <pitti> tseliot: oh, nice! please upload, I can commit that to Vcs-Bzr:
[13:46] <tseliot> pitti: yes, please. I'll take care of the upload, you'll deal with bzr
[13:47] <pitti> tseliot: yep, will grab the diff from LP; thanks!
[13:48] <doko> jamespage, LP: #1346056 probably needs some server love
[13:49] <jamespage> doko, ack
[13:50] <tseliot> pitti: ok, aptdaemon_1.1.1+bzr973-1ubuntu4 is in. We'll also have to rebuild ubuntu-drivers-common
[13:54] <doko> jamespage, infinity: about the jquery, ... libv8-3.14 component mismatches ... do we want this in main?
[13:54] <jamespage> doko, v8 is a nack from the security team
[13:54] <jamespage> so no
[13:58] <juliank> tseliot: Wow, something's gone wrong somewhere. There's no aptdaemon_1.1.1+bzr973-1 in Debian, why is there an aptdaemon_1.1.1+bzr973-1ubuntu4 in Ubuntu?
[13:59] <tseliot> juliank: I'm not really sure, all I know is that aptdaemon_1.1.1+bzr973-1ubuntu3 was breaking ubuntu-drivers-common
[13:59] <juliank> Does not matter much, not going to package a bzr snapshot in Debian anyway.
[13:59] <tseliot> juliank: mvo seems to be the uploader of 1.1.1+bzr970-1ubuntu1
[14:00] <juliank> But apparently mvo mixed up 0ubuntu1 and 1ubuntu1
[14:01] <juliank> slangasek: I asked you yesterday already: Do you still need gcc 4.6 & GNU_EFI_USE_MS_ABI support for gnu-efi (what for?) or can this be dropped, and the package synced from unstable?
[14:03] <pitti> xnox: would you mind filing a Debian bug for bug 1326327 and CC: pkg-systemd-maintainers@lists.alioth.debian.org ?
[14:03] <juliank> And if anyone here is interested in elilo, go and take it over in Debian or it will be removed.
[14:04] <cjwatson> I don't think anyone here cares about elilo
[14:04] <xnox> juliank: why not just take the patch into debian? the reasoning is entirely valid.
[14:04] <xnox> juliank: http://launchpadlibrarian.net/151318291/gnu-efi_3.0u%2Bdebian-1ubuntu1_3.0u%2Bdebian-1ubuntu2.diff.gz
[14:04] <cjwatson> (any more)
[14:04] <juliank> xnox: I don't see the point in that patch. And I don't know if it even works anymore in 3.0v
[14:04] <xnox> juliank: cjwatson: we do care about building shim on precise though, and that patch was backported all the way back to precise.
[14:05] <cjwatson> sure, I was talking about elilo not gnu-efi
[14:05] <xnox> cjwatson: ah, noticed now. sorry.
[14:06] <xnox> juliank: but to answer (what for?) ->  to build src:shim on precise (12.04) which has gcc-4.6 as the default toolchain.
[14:13] <juliank> xnox: That makes sense for precise then, but for utopic?
[14:16] <xnox> juliank: at the time we had to backport everything to precise. I don't know if we will continue to backport e.g. gnu-efi to precise, if shim changes.
[14:17] <xnox> juliank: anyway, i think that gcc-4.6 should be supported by gnu-efi, at least because of mac os =)
[14:17] <xnox> juliank: and not cause a static compile time #error =)
[14:18] <xnox> and because of 12.04 still being used for another 3 years.
[14:18] <juliank> xnox: But I'm not sure it works, and I don't want to risk breaking things. gnu-efi was broken in unstable for a long time already because it used stub va_* functions. Now I switched it to use gcc builtins which is the only thing that works.
[14:19] <xnox> juliank: please do not sync, and override/drop changes in ubuntu =) and update package as you see fit in Debian.
[14:20] <xnox> juliank: and the patch we carry is not useless in ubuntu.
[14:26] <xnox> pitti: If we were playing chess, I'd now say "check" ;-) bug 1320534 updated
[14:28] <doko> zul, LP: #1349500 please remove the six code
[14:28] <zul> doko:  ack
[14:34] <doko> bdmurray, cjwatson, slangasek: please subscribe foundations to libisocodes bug reports
[14:35] <arges> @pilot in
[14:39] <cjwatson> doko,bdmurray,slangasek: done.  thanks for going through these
[14:48] <pitti> hallyn: FYI, I just created https://github.com/lxc/lxc/pull/285 to unbreak LXC under systemd
[14:50] <doko> dobey, any update on ubuntu-sso-client?
[14:51] <pitti> hallyn: do you think it's ok to upload that to utopic? I'd also like to add a systemd unit to set up the lxc bridge and load the AA policies, so that LXC works OOTB
[14:51] <hallyn> pitti: loks fine to me
[14:53] <hallyn> pitti: merged into git.  Do you want to push it to utopic?
[14:54] <pitti> hallyn: ah cool, thanks!
[14:54] <pitti> hallyn: yes; as I said, if you don't mind I'd like to add an lxc-net script with the guts of /etc/init/lxc-net.conf and create a systemd unit for this
[14:54] <hallyn> pitti: yup, that'd be awesome
[14:55] <pitti> bug 1312532 FTR
[14:55] <hallyn> then I'll ake a look at it and learn a thing or two
[14:55] <hallyn> fwiw I created a pair of cgmanager .service files yesterday.  seemed to be working <shrug>
[14:55] <pitti> hallyn: ah, gretat
[14:55] <pitti> great, even
[14:55] <pitti> hallyn: I had to stop cgmanager under systemd as it breaks LXC
[14:56] <hallyn> how does it do that?
[14:56] <pitti> http://paste.ubuntu.com/7905528/
[14:56] <hallyn> but yeah the systemd job is disabled by default so should help there
[14:56] <pitti> hallyn: well, I suppose it's not actually cgmanager's fault, but LXC trying to talk to cgmanager when systemd does the cgroup management or so (I don't know the details)
[14:56] <pitti> hallyn: indeed, yes
[14:57] <hallyn> huh
[14:57] <hallyn> pitti: 0.28-2 also was missing the patch which made cgmanager remount it's / private,
[14:57] <hallyn> so you ended up with extra cgroup mounts on th system.
[14:57] <hallyn> so 0.28-3 should be a huge improvement all-around under sytemd
[14:57] <pitti> cool, looking forward to it
[14:58] <pitti> and plusgood for getting in sync with Debian, eases bug fixing all aronud
[14:58]  * hallyn is gonna have to disable the touchpad on this laptop.  it's huge!  why does eveyrone thing I want huge phones and huge touchpads?
[14:58] <pitti> hallyn: +1
[14:58] <hallyn> pitti: plusungood for burning bridges along the way :(
[14:59] <pitti> hallyn: you mean like the heated discussions at plumber's about who wants to own the cgroup management?
[14:59] <pitti> *sheesh*, these happen all the time, and IIRC that still was still surprisingly technical
[15:01] <pitti> xnox: thanks for clarifying bug 1320534, sorry for closing prematurely
[15:02] <xnox> pitti: hm, now i can't find where does mk-sbuild get /run/shm from.
[15:02] <pitti> xnox: I'm honestly not aware that I ever changed the "sbuild" profile fstab, so I never ran into that
[15:02] <pitti> xnox: how do you mean? isn't mountall creating /run/shm?
[15:02] <dobey> doko: i didn't get a chance to poke at it yet. i think i would probably just disable the tests at this point, i don't have time to debug squid. and my plate is full with getting things done for the phone beta :-/
[15:03] <xnox> pitti: let me ask the question properly.
[15:03] <pitti> xnox: oh, in my sid schroot /run/shm is an empty dir, so I figure debootstrap?
[15:03] <doko> dobey, ok, if I upload doing just that?
[15:04] <xnox> pitti: in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674755#53 mbiebl syas that ubuntu-dev-tools should be fixed to use /dev/shm instead. But i see nothing in mk-sbuild that fiddles with /run/shm vs /dev/shm.
[15:04] <LocutusOfBorg1> simple question, is gsoap blocking the virtualbox migration, right?
[15:04] <xnox> pitti: unless it's copying host settings, we change init, new host != container, caboom.
[15:05] <dobey> doko: sure
[15:05] <cjwatson> LocutusOfBorg1: the blocker there is gridsite
[15:05] <LocutusOfBorg1> I see
[15:05] <LocutusOfBorg1> interesting, the debian rebuild was successful
[15:07] <xnox> pitti: so in my newly created mk-sbuild utopic, on utopic. shm is a symlink to /run/shm. What made it so?
[15:07] <slangasek> juliank: yes, and I asked you in response whether Debian bug #753682 has been properly fixed
[15:08] <xnox> slangasek: not gonna update gnu-efi in precise? =)
[15:09] <slangasek> juliank: in my last merge I was still maintaining compatibility with gcc-4.6 because precise uses it, and we've had to update gnu-efi wholesale in SRU before in support of shim
[15:10] <slangasek> juliank: so I think we should keep that patch as the only delta for now; I'm otherwise happy to update gnu-efi as soon as #753682 is properly fixed (which I'll verify by rebuild-testing the gnu-efi revdeps like shim)
[15:11] <pitti> xnox: good question; perhaps some sysvinit postinst?
[15:11] <hallyn> wgrant: hey, do you have a strategy for typing on your t440s without moving the mouse around?  The "disable touchpad while typing" doesn't sem to be working
[15:11] <xnox> pitti: horum.
[15:12] <xnox> pitti: infinity what makes /dev/shm a symlink to /run/shm?
[15:13] <wgrant> hallyn: I always disable that option, since I manage to not touch the touchpad while typing.
[15:13] <wgrant> hallyn: But indeed, it seems to not work. Odd.
[15:14] <hallyn> I guess my ogre hands aren't dainty enough or something :)
[15:14] <xnox> pitti: initscripts.postinst ?
[15:14] <pitti> xnox: bingo
[15:16] <xnox> pitti: does your merge address that mess? =)
[15:17] <pitti> xnox: hm, that creates the dirs, but not the symlinks
[15:18] <juliank> slangasek: You did? I did not notice that
[15:18] <slangasek> juliank: ok, lost to scrollback then :)
[15:18] <slangasek> juliank: or I was talking to a ghost due to my IRC proxy lying to me about your presence ;)
[15:18] <xnox> pitti: it totally does.
[15:19] <pitti> xnox: I must be blind then; I only see mkdirs
[15:19] <om26er> arges, Hi!
[15:19] <arges> om26er: hi
[15:19] <juliank> slangasek: Yeah, must be a ghost. The last thing I have received from you before today was on Dec 18
[15:19] <xnox> pitti: if the 38 states state machine detects, RUNACTION LINKRUN or LINKDEV, either /run/shm is symlinked to /dev/shm, or /dev/shm is symlinked to /run/shm
[15:20] <xnox> pitti: grep for "compat_link"
[15:20] <juliank> that is, the last thing you wrote and mentioned juliank
[15:20] <pitti> xnox: yes, that's defined, but nothing is using it
[15:20] <om26er> arges, since you are the pilot, can you land my change ?
[15:20] <om26er> bug 1349813
[15:20] <pitti> xnox: ooh, silly me!
[15:21] <pitti> Version: 2.88dsf-53.2ubuntu1
[15:21] <pitti> xnox: I have my proposed merge installed
[15:21] <juliank> slangasek: And yes, that bug is properly fixed in 3.0v-5. I replaced all the va_* stuff in efistdarg.h with definitions using gcc builtins
[15:21] <arges> om26er: looking
[15:21] <pitti> xnox: was looking again in my utopic chroot, and that indeed does all that
[15:21] <juliank> That's the only way to get it working with -nostdinc
[15:21] <xnox> pitti: =))))))))
[15:21] <pitti> xnox: so I guess that makes it a "yes" :)
[15:21] <pitti>  xnox | pitti: does your merge address that mess? =)
[15:21] <xnox> \o/
[15:22] <xnox> pitti: so, when are we landing that?
[15:22] <pitti> xnox: as soon as someone sends enough beer to slangasek to review my merge
[15:22] <xnox> slangasek: we want pitti's merge to stop us from going on witch-hunts of insanity =)
[15:23] <pitti> . o O { why don't we have a font for U+1F37A BEER MUG ? }
[15:23] <slangasek> juliank: perfect, thanks
[15:23] <slangasek> pitti: on the list for this week :)
[15:23] <pitti> slangasek: you are speaking about creating a glyph for BEER MUG, of course
[15:24] <slangasek> naturally
[15:24] <arges> om26er: i noticed that no bug was mentioned in the changelog entry (i'm adding the one you posted)
[15:25] <om26er> arges, oops! forgot about that.
[15:31] <kentb> Hi, I'm looking for sponsorship on a package upgrade if anyone has some time to look at it.  Thanks!  https://bugs.launchpad.net/ubuntu/+source/sblim-sfcb/+bug/1335907
[15:32] <arges> om26er: ok sponsored for utopic!
[15:33] <om26er> arges, wow, thanks
[15:34] <shadeslayer> chrisccoulson: ping
[15:34] <shadeslayer> chrisccoulson: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1274605
[15:34] <shadeslayer> could someone *please* look at that
[15:37] <LocutusOfBorg1> cjwatson, https://github.com/bagder/curl/commit/5fcef972b289bdc7f3dbd7a55a5ada0460b74b2d
[15:38] <LocutusOfBorg1> this seems to be the problem, right?
[15:38] <LocutusOfBorg1> I still don't catch if it a mistake or not, but should be the source of the problem of gridsite
[15:38] <cjwatson> ah, interesting.  I'd be inclined to change gridsite to just use the new names
[15:39] <LocutusOfBorg1> and the problem is in curl 7.37.1, the debian rebuild happened before, so we didn't get a build failure in debian
[15:39] <LocutusOfBorg1> maybe curl made a mistake
[15:39] <cjwatson> well, it failed to provide compatibility, true
[15:39] <cjwatson> I guess I could backport that commit
[15:40] <LocutusOfBorg1> what?
[15:40] <LocutusOfBorg1> this is the commit that introduced the build failure...
[15:40] <LocutusOfBorg1> AFAICS
[15:40] <LocutusOfBorg1> I'm dropping a line on that commit
[15:41] <pitti> hallyn: would something like http://paste.ubuntu.com/7905830/ be acceptable for upstream?
[15:41] <cjwatson> LocutusOfBorg1: oh, gridsite and curl are trying to define mutually recursive includes, I see
[15:42] <LocutusOfBorg1> yes
[15:43] <cjwatson> which would be because CURLOPT_WRITEDATA is now a real symbol rather than a #define
[15:43] <LocutusOfBorg1> I still don't get it
[15:43] <LocutusOfBorg1> curl.h has
[15:43] <LocutusOfBorg1> #define CURLOPT_FILE CURLOPT_WRITEDATA /* name changed in 7.9.7 */
[15:43] <LocutusOfBorg1> and it is included before the define
[15:44] <LocutusOfBorg1> htcp.c:65:27: error: 'CURLOPT_FILE' undeclared (first use in this function)
[15:44] <LocutusOfBorg1>  #define CURLOPT_WRITEDATA CURLOPT_FILE
[15:44] <cjwatson> it's a real symbol rather than a #define, so gridsite's #ifndef fires
[15:44] <cjwatson> because CURLOPT_WRITEDATA isn't #defined, it's an actual proper symbol now
[15:44] <LocutusOfBorg1> oh yes
[15:45] <LocutusOfBorg1> I missed the ifndef
[15:45] <LocutusOfBorg1> anyway, if you got the problem I think my work is done ;) if you want I can try to fix it, I would like to see gsoap finish its transition
[15:45] <hallyn> pitti: there's not some systemd-network-ish way that it would be properly done for the .service files?
[15:46] <cjwatson> LocutusOfBorg1: I've got it, thanks
[15:46] <hallyn> i think the patch is fine (apart from a /usr/share/lxc/$script sourcing /etc/default - i dont' know if that breaks some standards.  and you know how i love an drespect standards)
[15:46] <cjwatson> I did the rest of the transition a day or two ago
[15:48] <LocutusOfBorg1> yes I see, thanks to you :)
[15:51] <LocutusOfBorg1> BTW thanks for the buildd stack migration
[15:51] <cjwatson> mostly not me :) but yeah it's pretty cool
[15:51] <cjwatson> so much less hassle
[15:52] <LocutusOfBorg1> after 6 years I can start build on armhf packages depending from haskell suite
[15:52] <cjwatson> surprised that didn't work before.  did it hate the hardy kernel?
[15:52] <LocutusOfBorg1> don't know
[15:53] <LocutusOfBorg1> something like haskell-blabla-0b15202 is not coinstallable with haskell-blabla2-f212
[15:53] <LocutusOfBorg1> something like a bad haskell transition
[15:53] <cjwatson> nothing to do with scalingstack then
[15:53] <cjwatson> it's using the very same chroots
[15:53] <LocutusOfBorg1> why is it working now?
[15:53] <LocutusOfBorg1> I was wondering something qemu related
[15:54] <cjwatson> what series are you building these against?
[15:54] <cjwatson> no, installability won't be affected by qemu
[15:54] <LocutusOfBorg1> ok let me see one thing
[15:54] <LocutusOfBorg1> BTW I got already two segmentation fault in gcc
[15:54] <LocutusOfBorg1> https://launchpadlibrarian.net/181061819/buildlog_ubuntu-trusty-armhf.boinc_7.4.0~nightly1~~git20140730%2Br21925~r184~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
[15:54] <LocutusOfBorg1> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[15:54] <LocutusOfBorg1> Segmentation fault (core dumped)
[15:54] <LocutusOfBorg1> since the upgrade
[15:55] <LocutusOfBorg1> the second one is here
[15:55] <LocutusOfBorg1> https://launchpadlibrarian.net/181036546/buildlog_ubuntu-utopic-armhf.hedgewars_0.9.21~alpha~7716~ubuntu14.10.1_FAILEDTOBUILD.txt.gz
[15:55] <LocutusOfBorg1> you see, now the installation part has been successful
[15:55] <LocutusOfBorg1> (I'll try to search a build log with the failure)
[15:55] <cjwatson> I'm sure the segfault was fixed by the kernel/qemu upgrade, yes
[15:56] <cjwatson> oh, that's since the upgrade?
[15:56] <cjwatson> well, did that fail before as well?
[15:56] <LocutusOfBorg1> no
[15:56] <LocutusOfBorg1> never
[15:56] <cjwatson> in general we can't fix qemu failures
[15:56] <cjwatson> at best we can escalate them
[15:57] <cjwatson> but qemu-user is fundamentally pretty unreliable - if it works, celebrate, if not, sorry
[15:57] <LocutusOfBorg1> btw the uninstallability problem of haskell stack was only with ppa builders
[15:57] <cjwatson> don't believe that :)
[15:58] <LocutusOfBorg1> https://launchpadlibrarian.net/132287908/buildlog_ubuntu-quantal-armhf.hedgewars_0.9.18-0.2~ubuntu12.10.1~ppa1_FAILEDTOBUILD.txt.gz
[15:58] <cjwatson> LocutusOfBorg1: with -proposed disabled, it's possible that you were unlucky and hit a brief period when it was broken in utopic
[15:58] <cjwatson> LocutusOfBorg1: oh come on you're seriously comparing quantal to utopic? :)
[15:58] <cjwatson> it was probably just uninstallable in quantal
[15:58] <cjwatson> since that predates proposed-migration, it would not at all surprise me
[15:58] <cjwatson> but quantal isn't worth investigating now
[15:59] <LocutusOfBorg1> https://launchpadlibrarian.net/140105253/buildlog_ubuntu-saucy-armhf.hedgewars_0.9.18-0.3~saucy1_FAILEDTOBUILD.txt.gz
[15:59] <LocutusOfBorg1> I can try to rebuild a package, let me reproduce
[15:59] <cjwatson> oh, wait, there's a qemu failure there, it's not package-level uninstallability
[15:59] <cjwatson> qemu: Unsupported syscall: 257
[15:59] <cjwatson> ghc: timer_create: Function not implemented
[16:00] <cjwatson> right, so I believe that is one of the set of things fixed by the upgrade
[16:00] <cjwatson> good, that makes sense now
[16:00] <LocutusOfBorg1> yes, there was a bug against it
[16:00] <LocutusOfBorg1> https://bugs.launchpad.net/qemu/+bug/1042388
[16:00] <cjwatson> anyway, it's great that that's fixed, but armhf virtual PPAs are still basically best-effort
[16:00] <LocutusOfBorg1> I think it can be closed now
[16:00] <LocutusOfBorg1> cjwatson, I'm not complaining ;)
[16:01] <cjwatson> I don't know whether that deals with the problem pitti had in that bug trail, so reluctant to close
[16:02] <LocutusOfBorg1> last thing, with the new format 0.4 {debupstream} isn't working anymore? deprecated?
[16:03] <cjwatson> LocutusOfBorg1: do you have a link to a recipe build where that fails?
[16:03] <cjwatson> LocutusOfBorg1: 0.4 didn't work *at all* before the upgrade
[16:03] <LocutusOfBorg1> yes
[16:03] <LocutusOfBorg1> https://launchpadlibrarian.net/181034312/buildlog.txt.gz
[16:03] <LocutusOfBorg1> bzr: ERROR: bzrlib.errors.BzrCommandError: Invalid deb-version: {debupstream}~7716~ubuntu14.10.1: Invalid version string '{debupstream}~7716~ubuntu14.10.1'
[16:06] <cjwatson> LocutusOfBorg1: odd, looks like that should work.  I can't investigate fully now, but please file a bug against launchpad-buildd
[16:06] <xnox> we never upgraded launchpad to 0.4 recipes
[16:07] <xnox> it needs newer something rather, that it doesn't have.
[16:07] <cjwatson> xnox: yes we did
[16:07] <cjwatson> xnox: on Monday
[16:07] <xnox> i'm so out of date =)
[16:08] <cjwatson> scalingstack brought us lots of shiny
[16:08] <xnox> oh, we are on scaling stack now?! =)
[16:08] <xnox> awesome.
[16:08] <cjwatson> yup
[16:08] <smoser> hey..
[16:09] <cjwatson> it actually works and the builders have stopped falling over every ten minutes
[16:09] <smoser>  there no equivalent to /etc/udev/rules.d/70-persistent-net.rules for block devices
[16:09] <smoser> is that correct ?
[16:09] <smoser> i know i could do things based on disk id or path with udev and guarantee links or something to the kernel device name in /dev
[16:09] <xnox> jodh: we should try building procenv and upstart in virtualised ppas, as they should be awesome shiny now, instead of acient xen kernels.
[16:10] <smoser> but is there anything that could explicitly guarantee that 'sda' was the name given to some block device and 'sdb' was to another.
[16:10]  * LocutusOfBorg1 opens a bug report
[16:10] <pitti> hallyn: re (sorry, was out for supermarket); this is the preparation for writing units which also call lxc.net
[16:11] <pitti> hallyn: I don't know about systemd-network in particular, but it's very simple, and we don't want to build it in Debian/Ubuntu for now
[16:13] <LocutusOfBorg1> https://bugs.launchpad.net/launchpad-buildd/+bug/1350430 cjwatson :)
[16:14] <doko> seb128, gtk+3.0 unconditionall build-depends on mir, which is not avail on powerpc and ppc64el
[16:14] <seb128> doko, good observation
[16:15] <Laney> wait
[16:15] <Laney> since when?
[16:15] <seb128> Laney, since robert_ancell uploaded the Mir backend earlier today
[16:15] <doko> 3.12.2-0ubuntu5
[16:15] <jodh> xnox: I've already got a virt build of procenv: https://code.launchpad.net/~jamesodhunt/+recipe/procenv-daily. Odd that it's set to build daily but hasn't since the 5th though.
[16:15] <Laney> seems subideal
[16:15] <seb128> indeed
[16:15] <seb128> that's a bug
[16:15] <seb128> those happen ;-)
[16:16] <seb128> let me have a look, it's probably easy to change
[16:16] <seb128> Laney, ^ or did you start looking (don't want to dup work)
[16:17] <Laney> no you can, this laptop is too crappy to build gtk reasonably
[16:17] <seb128> k
[16:17] <Laney> patch headers would be welcomed too at the same time
[16:17] <seb128> noted
[16:17] <Laney> ty
[16:17] <seb128> Laney, how is the hackfest btw? ;-)
[16:17] <Laney> not enough power!
[16:18] <Laney> but yeah, pleasant, there's quite a few people still here
[16:19] <pitti> slangasek: ah, so I'm not objecting to building systemd-sysv, I just seemed to remember that the other day you said you don't want it yet; but that was probably in the trusty time frame
[16:21] <LocutusOfBorg1> wow
[16:21] <LocutusOfBorg1> the new buildd stack makes the build get stuck
[16:21] <LocutusOfBorg1> https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6224439
[16:21] <xnox> jodh: it builds daily, if there was any change in all the involved branches.
[16:21] <xnox> jodh: this is not travis-ci =)
[16:22] <infinity> 509 upgraded, 24 newly installed, 0 to remove and 0 not upgraded.
[16:22] <infinity> Need to get 468 MB of archives.
[16:22] <infinity> It's always pleasant to see a massive transition finally go through.
[16:22] <infinity> cjwatson: Congrats.
[16:22] <xnox> jodh: you can cron API to push "build now" for you =)
[16:22] <jodh> xnox: thus, it should be labelled "built daily on change", not "built daily" since it's currently misleading :)
[16:24] <jodh> xnox: regardless, you are right - we now see 3.13.0-32-generic in uname! :)
[16:24] <cjwatson> LocutusOfBorg1: you know that #launchpad is the right place to ask about PPA builder problems, right?
[16:26] <LocutusOfBorg1> cjwatson, now I know ;)
[16:26] <LocutusOfBorg1> thanks
[16:28] <cjwatson> infinity: only took weeks
[16:28] <xnox> jodh: wow launchpad build on virt PPAs =)
[16:28] <xnox> jodh: ehm upstart that is =)
[16:29] <xnox> jodh: we should probably bump numbers in the recipes.
[16:29] <jodh> xnox: omg green ticks everywhere! :-)
[16:30]  * jodh thinks green ticks are better than red leeches :)
[16:30] <xnox> cjwatson: it feels like double Christmas!
[16:36] <hallyn> pitti: looks good then
[16:37] <zul> doko:  done
[16:41] <slangasek> pitti: right, could have been in trusty :)
[16:59] <doko> zul, https://launchpadlibrarian.net/181072252/buildlog_ubuntu-utopic-i386.python-retrying_1.2.1-1ubuntu1_UPLOADING.txt.gz
[17:00] <doko> no dependencies on python{,3}-six
[17:00] <doko> echo six > requirements.txt
[17:03] <doko> zul: swift autopkg test fails
[17:03] <zul> doko:  ack
[17:11] <hallyn> jodh: wgrant: aha!
[17:11] <hallyn> syndaemon in unity is called with -t, which doesn't stop mouse movement.  dropping that flag fixes it
[17:11] <hallyn> now i can type
[17:32] <hallyn> pitti: so were you going to push that apparmor fix for lxc for systemd to utopic yourself?
[17:33] <doko> zul: ??? http://launchpadlibrarian.net/181073883/python-retrying_1.2.1-1ubuntu1_1.2.1-1ubuntu2.diff.gz
[17:33] <zul> doko:  crap sorry about this
[17:51] <doko> xnox, did you already look at llvm-defaults?
[17:51] <roadmr> mitya57: about bug 1349927, Would you agree to setting this bug as a duplicate of bug 1295835? I can also move it to qtchooser if it makes more sense.
[18:15] <arges> @pilot out
[18:27] <slangasek> xnox: hey, were you going to remove the Essential: yes flag from init, then?
[18:27] <slangasek> xnox: or maybe you've already done so and it's waiting in utopic-proposed?
[18:28] <mitya57> roadmr: feel free to mark as duplicate
[18:28] <roadmr> mitya57: thanks
[19:34] <slangasek> barry: hi, are you aware of bug #1349478?  it's a top crasher on the phones currently
[19:35] <barry> nope haven't seen that one yet
[19:35] <slangasek> barry: can I assign it to you?
[19:36] <barry> slangasek: already done :)
[19:36] <slangasek> cheers
[19:37] <barry> slangasek: i think this is the one that ogra_ pointed me to yesterday.  it can only happen if the directory /var/lib/system-image doesn't exist or has bogus perms.  which makes sense in the testing environment, but not on live devices (nothing changed here).  well, i guess something changed if this is happening on installed devices.
[19:41] <Noskcaj> doko, Thanks for fixing jquery
[19:51] <slangasek> barry: I don't know if the submissions are from installed devices or not - there are plenty of test environments proportional to installed devices right now :)
[19:52] <barry> slangasek: true :)  i'm almost positive this is related to LP: #1301995 which fixed this for log files when run as non-root
[19:52] <barry> guess where it's run as non-root?
[19:53] <slangasek> barry: well, "from the apport hook", but I'm not sure if that's the answer you were looking for :)
[19:53] <barry> slangasek: nope ;)
[19:53] <barry> anyway, should be an easy fix.  i'll try to swing around to it asap
[20:00] <Noskcaj> infinity, Could you merge wxwidgets3.0 soon please? I've got a merge waiting on it
[20:15] <Unit193> Howdy.  So is there a specific date that tasksel updates Ubuntu tasks from seeds?  Or would I have to poke someon/Colin about that?
[20:25] <doko> mlankhorst, online?
[20:42] <arges> hallyn: do we use q35 machine type much for qemu/tools that use qemu in ubuntu?
[20:43] <hallyn> q35?
[20:43] <hallyn> i think qemu64 used to be the default.  haven't heard of q35 i dn't think
[20:43] <arges> hallyn: yea machine type q35 vs i440fx (which seems to be the default for most tools virt-install/uvtool)
[20:43] <hallyn> oh.  yeah, I don't think we do
[20:44] <arges> <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
[20:44] <hallyn> jamespage: smoser: do you kno wof any places where we use q35 (on purpose) machine type under qemu?
[20:44] <arges> ok
[20:44] <hallyn> arges: why do you ask?
[20:44] <arges> hallyn:  trying to get virt-test working with Ubuntu, and it runs each test on i440fx and on q35
[20:45] <arges> didn't know how widely used q35 was; since it doubles the tests
[20:46] <smoser> hallyn, no. only if by default.
[20:46] <hallyn> feh, seems i've not enabled kvm in the bios
[20:46] <arges> well regardless if i440fx is default and most people use it we'll start there.
[20:46] <hallyn> sounds good
[21:53] <k1l_> hi there, since we got a lot of users complaining they are not prompted for the LTS -> LTS upgrade from 12.04 to 14.04 can someone tell me when the LTS upgrade path will be opened?
[22:04] <asomething> Is there a script  to do a rebuild of a list of reverse dependencies in a ppa?
[22:32] <doko> xnox, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756564  any idea about that?
[23:02] <xnox> doko: yes, i've seen that happen when libraries are either split badly (e.g. /lib /usr/lib and or multiarch symlinks are broken and/or non-existant) and then cmake goes south and does "statically link everything" which usually fails and fails the builds or worse succeeds the builds =(
[23:02] <xnox> doko: i'll look into it tomorrow.
[23:02] <xnox> slangasek: done, stuck in alpha2 block.
[23:03] <xnox> doko: i do have llvm-defaults locally, but haven't uploaded it yet. Would be stuck in alpha2 block I think, and I haven't rebuilding everything yet.
[23:32] <xnox> i wonder how long it takes a panda to build ghc =)
[23:32] <xnox> or maybe llvm 3.5 is hung ;-)
[23:45] <xnox> doko: what specifically breaks? as cmake FindFLTK should find /usr/lib/fltk/FLTKConfig.cmake, include it direct and get all the shared and static paths.
[23:45] <xnox> doko: i'll experiment more locally here, but do you have example cmake using package that uses FLTK and doesn't get shared FLTK?