[00:14] <cjwatson> Noskcaj: gucharmap branch> I'm afraid I have no idea
[00:16] <cjwatson> jtaylor: that means your autoreconf isn't sufficient.  Note that there are configurations where autoreconf doesn't update config.{guess,sub} and you need to update them separately - see spectemu for the first example of doing that that comes to mind
[00:17] <cjwatson> jtaylor: or indeed openssh
[00:23] <cjwatson> Riddell: if you have a test package for kde4libs/armhf then I can try it on a porter box
[00:54] <cjwatson> doko_: I stole your hfsutils merge to help unblock merges.u.c
[01:15] <cjwatson> Riddell: Looks like kde-baseapps 4:4.14.0-whatever didn't get uploaded?  Looking at the ark dep-wait
[02:34] <sarnex> hi. i'm trying to pull the latest wine source from the ubuntu wine ppa, apply one patch, and uploaded the patched version to my own PPA. every time I try it, the one of my PPA does not contain my patch. how can i fix this?
[04:25] <pitti> Good morning
[04:26] <pitti> doko_: yes, will do; current autopkgtest machines are annoying, they are heavily overloaded with other bits and the qemus keep timing out :(
[05:12] <pitti> ok, tests work better again, I cleaned up some old stale processes on those; /dev/shm was full or almost full on these
[05:36] <pitti> doko_: so for gcc-4.9, the only package which fails but isn't forced is kde-runtime, which is still uninstallable on i386 (some problem with phonon); so I suppose you might want to ask the release team to override that, too?
[05:36] <pitti> ScottK: ^
[05:42] <ScottK> pitti: Looks like it's caught up in the VLC transition.
[05:44] <pitti> ScottK: right; that's fine in -proposed, but I suppose britney needs some hinting to not block gcc on it
[05:44] <ScottK> It'd pass the test (which is what britney appears to block on) if phonon-backend-vlc were installable in proposed.
[05:45] <ScottK> I could force the test, but why not make it pass instead.
[05:45] <pitti> even better :)
[05:47] <ScottK> Test build going now.
[05:54] <ScottK> pitti: I just uploaded phonon-backend-vlc 0.7.80-0ubuntu2.  Once it's built/published on the relevant archs, would you please requeue kde-runtime for retesting.
[05:55] <pitti> ScottK: my pleasure, thanks for fixing!
[05:55] <ScottK> Thanks.
[05:56] <ScottK> Off to bed for me then.
[06:44] <dholbach> good morning
[06:49] <highvolt1ge> o/
[06:57] <Ozzyboshi> hello chat i want to fork an existing project licensed under gpl3, do you know if i am forced to license my forked project on the same license?
[06:58] <pitti> Ozzyboshi: yes, you can't change the license without permission of all current copyright holders
[06:59] <Ozzyboshi> pitti, ok so gpl2+ for example is not allowed because the main project is gpl3 right?
[07:00] <pitti> Ozzyboshi: correct; the other way around would work
[07:01] <Ozzyboshi> pitti, thank you a lot
[07:01] <Unit193> http://metadata.ftp-master.debian.org/changelogs/main/c/cryptsetup/unstable_changelog FWIW, Debian added a lot of the Ubuntu delta for cryptsetup.  Might be handy to review the systemd/systemd-shim support and merge?
[07:54] <doko> Riddell, I would appreciate it if you could check for work arounds which are not necessary anymore, when uploading new KDE packages, e.g. kde4libs
[08:01] <Riddell> doko: I know therer's a failure on arm but I need to faff around to set up my arm machine again to check if that gcc-4.7 workaround is still needed
[08:02] <doko> Riddell, https://launchpad.net/ubuntu/+source/kde4libs/4:4.14.0-0ubuntu2/+build/6286729
[08:02] <doko> now needs an update for the symbols files
[08:04] <Riddell> doko: ah hah, thanks.  although it'll probably still need to be built locally else it'll need uploads for every library in that package
[08:05] <doko> Riddell, currently doing that. but please check the other packages for old GCC usage and other workrounds
[08:05] <Riddell> thanks doko
[08:41] <Riddell> doko: now for a challenge, smokeqt is broken, no change in the code since it compiled fine, compiling with older gcc doesn't help, i've no idea on that one
[08:47] <pitti> doko: gcc-4.9 is "valid candidate" now \o/
[08:47] <doko> pitti, alreay migrated
[08:48] <pitti> doko: yeah, just saw the "jenkins fixed" mail for kde4libs
[08:54] <TJ-> Riddell: The bug is that in QT 5 QDir::operator=() has two overloads, but the code doesn't make clear which one is required. In QT 4.8 there was only one ::operator=() so there was no ambiguity
[08:55] <Riddell> TJ-: mm, but smokeqt uses Qt 4
[08:57] <TJ-> Riddell: it does? I saw something that pointed to the QT5 issue, since its been pretty common; let me re-read the build log
[08:59] <doko> TJ, Riddell: can you check with gcc-snapshot?
[09:01]  * Riddell tries
[09:06] <Riddell> doko: I just install gcc-snapshot and compile as normal with gcc-4.9 ?
[09:06] <doko> no
[09:07] <doko> PATH=/usr/lib/gcc-snapshot/bin:$PATH, and use gcc and g++. Maybe you need to set the LD_LIBRARY_PATH too
[09:08] <Riddell> ah gotcha
[09:16] <Riddell> doko: nope, no change
[09:16] <doko> Riddell, ok, and 4.8?
[09:17]  * Riddell tries again
[09:19] <Riddell> doko: much the same, http://paste.kde.org/ptikq0thn (snapshot) http://paste.kde.org/pwcqhqtnu (4.9) http://paste.kde.org/pxkjlsi9i (4.8)
[09:20] <doko> Riddell, interesting
[09:25] <LocutusOfBorg1> sorry what is missing for the wx2.8 migration?
[09:25] <cjwatson> ScottK: Thanks for phonon-backend-vlc.  I identified that last night, but I had to fix vlc/powerpc first and then had to sleep.
[09:28] <doko> Riddell, my guess is that something in the build dependencies (c++ headers) changed
[10:09] <cjwatson> doko: Can I steal your graphicsmagick merge?
[10:10] <cjwatson> Actually, might be a sync, let's see
[10:14] <cjwatson> doko: Yeah, it's a sync, I'll JFDI
[10:23] <doko> cjwatson, steal whatever you want ;)
[10:23] <doko> - (subst)_ZN11KColorUtils3mixERK6QColorS2_{qreal}@Base 4:4.3.4
[10:23] <doko> + _ZN11KColorUtils3mixERK6QColorS2_f@Base 4:4.14.0-0ubuntu3
[10:23] <doko> +#MISSING: 4:4.14.0-0ubuntu3# (subst)_ZN11KColorUtils3mixERK6QColorS2_{qreal}@Base 4:4.3.4
[10:23] <doko> Riddell, ^^^ I don't nderstand why this fails
[10:25] <zbenjamin> ogra_: did the new adbd land in image r202?
[10:25] <ogra_> zbenjamin, nope
[10:25] <Riddell> doko: something to do with qreal not being the same on armhf?
[10:26] <apachelogger> doko: qreal is double on some architectures and float on others, so qreal != f
[10:26] <apachelogger> a random guess that is
[10:26] <zbenjamin> ogra_: strange since i upgraded i cannot connect anymore
[10:26] <cjwatson> qreal is f on armhf though
[10:26] <zbenjamin> ogra_: setting a pw did not help
[10:26] <ogra_> zbenjamin, i wouoldnt land that without a loud and noisy announcement to the ML
[10:26] <cjwatson> Is it actually being substituted properly?
[10:26] <ogra_> zbenjamin, adb didnt change in months
[10:26] <doko> cjwatson, how would I check this?
[10:27] <cjwatson> not sure
[10:27] <zbenjamin> ogra_: ok...
[10:28] <doko> hmm, subst isn't documented?
[10:28] <zbenjamin> ogra_: hm adbd is even running on the phone, but my adb devices list is always empty
[10:29] <ogra_> adb kill-server;; adb device
[10:29] <ogra_> try restarting the local server
[10:30] <ogra_> or re-plug the cable
[10:30] <cjwatson> doko: IIRC it's specific to some KDE tools
[10:34] <zbenjamin> ogra_: did not help, maybe i should reflash my device
[10:36] <doko> Riddell, how do I enable this subst logic when calling dh_makeshlibs directly?
[10:37] <Riddell> doko: we use these tools to update symbols files http://pkg-kde.alioth.debian.org/symbolfiles.html
[10:44] <mlankhorst> ppisati: can you grab the mesa packages from utopic, or is it important this bug is fixed in trusty?
[10:45] <doko> mlankhorst, updated llvm-3.5 to rc3. can you give it a try on i386 again?
[10:46] <zbenjamin> ogra_: was there any change on the usb drivers? i had the device until now on a USB hub, that does not seem to work anymore
[10:47] <mlankhorst> doko: ok
[10:47] <ogra_> zbenjamin, nope, no kernel related changes in the recent time
[10:48] <ogra_> (all devices work fine for me with 202 fwiw)
[10:48] <zbenjamin> ogra_: ok then its on my hardware
[10:48] <zbenjamin> ogra_: reattaching the whole hub worked, weird all other devices worked fine except the phone
[10:49] <zbenjamin> ogra_: thx for helping
[10:49] <ogra_> well, do the other devices draw any power ?
[10:49] <ogra_> could be a power issue
[10:49] <zbenjamin> ogra_: now its gone again
[10:49] <mlankhorst> doko: was there a bug about the llvm error?
[10:49] <ogra_> since you are constantly charging over that port
[10:49] <zbenjamin> ogra_: other devices are mouse and keyboard
[10:49] <ogra_> right
[10:49] <ogra_> how is the battery level ?
[10:50] <zbenjamin> ogra_: of the phone? 100%
[10:50] <doko> mlankhorst, I don't know, at least I didn't file one
[10:50] <ogra_> (and you should see reasons for the disconnect in syslog)
[10:50] <mlankhorst> ok
[10:50] <mlankhorst> well i remember the test, should be fine without bug
[10:52] <zbenjamin> ogra_: thx, at least now i know where its coming from
[11:03] <shnatsel> Is making a merge request against lp:ubuntu/lsb the right way to submit a patch to Ubuntu's lsb package? It's an Ubuntu-specific change.
[11:03] <shnatsel> The package is native, so it's just the changes in a branch and not a quilt patch in debian/patches
[11:06] <cjwatson> infinity: Can I steal your libpreludedb merge for Perl 5.20?
[11:08] <cjwatson> xnox: Can I steal your openbabel merge for Perl 5.20?
[11:12] <Saviq> tvoss, hey, could you give a quick look at my assessment in the comments for bug #1359258
[11:19] <tvoss> Saviq, done
[11:20] <ScottK> cjwatson: No problem.  Your powerpc FTBFS fix was certainly harder than my no change rebuild.
[11:28] <cjwatson> ScottK: discovered after the fact that it was already fixed similarly in git, but there you go
[12:03] <Saviq> tvoss, thanks
[12:25] <mlankhorst> doko: it no longer fails with the same error, but I'm uncertain if it's really fixed
[12:41] <junrrein> Hi Ubuntu people, I got a question. Is there a reason that the libglib2.0-bin (2.40) package in Trusty doesn't include the gapplication binary? (http://goo.gl/qYnmtu). It is a part of "official" (gnome) 2.40 release though. And is there a chance of an update to the Trusty package to include it? (I understand why it would not be reasonable)
[12:42] <junrrein> For reference, the binary is included in the Utopic package (http://packages.ubuntu.com/search?suite=utopic&arch=any&searchon=contents&keywords=gapplication)
[12:46] <mlankhorst> doko: ok I checked against the working version of my tests, they work correct..
[12:46] <doko> mlankhorst, nice!
[12:47] <mlankhorst> so I'll upload llvm 3.5 again, but I'll revert again if it fails for others. :P
[12:47] <mlankhorst> and add a explicit dependency on >= rc3
[12:48] <Laney> mlankhorst: can you check the autopkgtest that failed before?
[12:49] <mlankhorst> Laney: yeah I did, the current version of my failing autopkgtest doesn't work at all either way, but reverting to the working version shows the expected results
[12:49] <mlankhorst> online_accounts_ui right?
[12:50] <Laney> ubuntu-system-settings-online-accounts
[12:50] <mlankhorst> yeah
[12:50] <mlankhorst> that one works for me now(TM)
[12:50] <Laney> good luck
[12:50]  * Laney lunch
[13:23] <hallyn> desrt: hey, just wondering, were you planning to in the next 2-3 weeks look at the systemd-shim AbandonScope/StopScope (or whatever htat one is called) implementation?  It's on my list, and will stay there, but I won't be able to work on it this week or next, so was curious if it was on your list at all.
[13:26] <desrt> hallyn: i've never even heard of it :)
[13:27] <hallyn> ok :)
[13:27] <hallyn> Basically on logout, either it asks for AbandonScope to simply remove the cgroup if empty, or something like StopScope to kill any tasks in the cgroup to force full logout
[13:28] <hallyn> I'll just leave it on my list then - thx
[13:36] <Esokrates> slangasek: can you have a look at https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1359689?
[13:43] <roadmr> hello! I tried to boot a 14.10 ISO under virtualbox, I get this corrupted display: http://people.canonical.com/~roadmr/utopic-vbox.png anyone else seen this?
[13:44] <Esokrates> roadmr: yeah, press host + f7 after that host +f1
[13:45] <roadmr> Esokrates: awesome, that worked :) thanks
[13:46] <caribou> I'm working on bug #1321425
[13:46] <caribou> this relates to another bug :
[13:46] <caribou> bug #1328556
[13:47] <caribou> the first bug is fixed by setting OPTIONS="--hintpolicy=ignore"
[13:47] <caribou> but the second bug needs to be fixed for that
[13:47] <caribou> my question is : should irqbalance be set to OPTIONS="--hintpolicy=ignore" as a default ?
[13:48] <caribou> or should this be configured by the user ?
[13:49] <Esokrates> roadmr: this happens as well for other utopic spins (kubuntu), so it has to be some generic component
[13:55] <roadmr> Esokrates: oh... interesting, I'll keep an eye on it. Not that I really know how to fix it :/
[13:55] <Esokrates> roadmr: maybe someone should open a bug report for that
[13:56] <roadmr> Esokrates: oh there's no bug report? I can open one for sure
[13:56] <Esokrates> roadmr: I do not know any bug report ... maybe there is one?
[14:03] <roadmr> Esokrates: hmm I looked at bug reports and didn't find any that apply.
[14:06] <Esokrates> roadmr: any idea which components fault it could be? x? or virtualbox itself? it has to be a combination though, since trusty works find in virtualbox
[14:12] <roadmr> Esokrates: yes... it would be interesting to try the utopic iso on e.g. kvm
[14:13] <roadmr> Esokrates: other than that, I'd start by filing the bug on X (or maybe even linux) and triaging from there. It can always be moved to another component/package
[14:23] <Esokrates> roadmr: yeah with kvm its a little different ... can't tell though since I am 1.) on an old kernel 2.) kvm outdated
[14:40] <slangasek> Esokrates: saw your bug report come in on this; but this is not the behavior I see in utopic
[14:40] <slangasek> Esokrates: so I don't have a reproducer for this here currently
[15:19] <Esokrates> slangasek: that can't be ... how did you set up encryption?
[15:19] <Esokrates> slangasek: i tested this on various machines using various settings ... always reproducible
[15:20] <Esokrates> slangasek: even if i use the ubiquity predefined encryption scheme it is like that
[15:22] <Esokrates> slangasek: would you mind setting up utopic in a vm and see that it's really like that? I spend quite some time to be really sure this is reproducible
[15:33] <Esokrates> slangasek: I can definitely rule out that it's only me
[15:33] <slangasek> Esokrates: I have full-disk encryption with cryptsetup and plymouth on my laptop; the root fs is encrypted, so the prompting happens in the initramfs; this worked just fine the last time I rebooted, plymouth has not been changed in utopic since then.  And testing in a VM is not an indicator, VMs have terrible video drivers and there are all kinds of problems with plymouth on them.  Please run 'apport-collect 1359689' fro
[15:34] <Esokrates> slangasek: I have tested this on real setups ... the virtual machine was only for the screencast
[15:36] <Esokrates> slangasek: maybe it's not plymouth alone, but other stuff that has been updated since then
[15:36] <Esokrates> slangasek: I can only assure you that currently it's broken which will annoy and confuse users
[15:48] <shadeslayer> cjwatson: ping
[15:48] <shadeslayer> cjwatson: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/casper/utopic/view/head:/scripts/casper-bottom/25configure_init#L31 < needs to take into account SDDM
[15:49] <shadeslayer> rm -f /root/etc/rc?.d/[SK]??[gksx]?ddm maybe?
[15:49] <shadeslayer> or well
[15:49] <shadeslayer> rm -f /root/etc/rc?.d/[SK]??[gksx]?[d]dm maybe?
[15:50] <cjwatson> shadeslayer: I would just add another /root/etc/rc?.d/[SK]??sddm argument rather than trying to cram it all into a single wildcard
[15:50] <shadeslayer> okie
[15:53] <shadeslayer> cjwatson: http://paste.ubuntu.com/8107219/
[15:54] <cjwatson> shadeslayer: lgtm, will upload for you
[15:54] <shadeslayer> (Y)
[15:56] <cjwatson> done
[16:03] <cjwatson> Unit193,ochosi: tasksel finally updated, sorry for the delay
[16:09] <Esokrates> slangasek: how do we proceed? I think this is an serious issue, I have tested this on all real hardware I have at home and additionally in virtual machines, so I am absolutely sure. would you mind trying it on your own again? (install to some usb disk using that instruction: http://askubuntu.com/questions/293028/how-can-i-install-ubuntu-encrypted-with-luks-with-dual-boot)
[16:11] <slangasek> Esokrates: I asked you to run apport-collect, and you haven't done so.  I will look at it, but the fact that VMs are useless for plymouth troubleshooting due to VM-specific issues means that I have to be in a position to dedicate a piece of real hardware for testing, so it's going to be a while.
[16:12] <Esokrates> slangasek: oh sorry, yeah I will do the apport-collect
[16:12] <slangasek> Esokrates: thanks
[16:21] <Laney> mlankhorst: I think you typoed the Depends of libgl1-mesa-dri
[16:21] <Laney> libllvm-3.5 → libllvm3.5
[16:34] <ochosi> cjwatson: thanks a bunch!
[16:36] <mlankhorst> oh..
[16:37] <mlankhorst> probably *looks*
[16:37] <Laney> mlankhorst: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mesa ...
[16:38] <mlankhorst> thanks
[16:38] <Laney> np
[16:38] <Laney> please could you retry gst-plugins-bad1.0 after this is fixed?
[16:38] <mlankhorst> iamnotacoredev
[16:39] <Laney> it's in universe, but yeah, same difference for you IIRC :P
[16:39] <Laney> might be on from the train anyway
[16:42] <mlankhorst> uploaded
[16:55] <cjwatson> Riddell: how desperate are you for KDE to finish building on arm64/powerpc in the next couple of hours?  I really want to start copying in perl 5.20 before I have to finish for the day in preparation for travel tomorrow, but I'm waiting for a bunch of non-virt PPA builds; I could rescore them but KDE is the main thing I'd be queue-jumping
[16:56] <cjwatson> It looks like there aren't *that* many other builds left, but a lot of them must be long.  I have 151 pending builds out of 166 total in the farm, and the first of mine on arm64 is currently scheduled to start in 4 hours
[16:57] <cjwatson> oh, maybe that's misleading, actually, I have some due to start in an hour
[16:57] <cjwatson> so maybe it's not a problem ...
[17:00] <Esokrates> slangasek: seems like apport-collect attatched useless information
[17:10] <bdmurray> pitti: it looks like there are still issues with ddebs and main / universe - Failed to fetch http://ddebs.ubuntu.com/pool/main/c/compiz/compiz-plugins-dbgsym_0.9.11+14.04.20140409-0ubuntu1_i386.ddeb 404  Not Found
[17:10] <slangasek> Esokrates: mm, yes, this is definitely not the set of information I expect when running apport-collect against a bug on the plymouth package - the plymouth hook is supposed to populate a lot of hardware-related info (proc/cmdline, proc/fb...)
[17:11] <Esokrates> slangasek: i ran the command you advised me
[17:11] <bdmurray> pitti: Packages.gz lists it as in main but afaik its in universe
[17:12] <slangasek> Esokrates: ok.  it appears that the plymouth package in utopic is missing the apport hook, investigating
[17:13] <Esokrates> slangasek: ok, ping me when you have a solution/alternative
[17:14] <slangasek> xnox: ^^ you apparently removed the apport hook from the plymouth package, please put it back
[17:15] <Esokrates> slangasek: any way to add that hook without recompiling stuff?
[17:16] <slangasek> Esokrates: you can extract it from the source package and drop it into place at /usr/share/apport/package-hooks/source_plymouth.py
[17:16] <Esokrates> slangasek: which source package?
[17:16] <slangasek> the plymouth source package
[17:17] <Esokrates> slangasek: when it is fixed you mean?
[17:18] <Esokrates> slangasek: or should I use the hook from an older package?
[17:19] <slangasek> Esokrates: the hook hasn't changed; you asked how to add the hook without recompiling, that's how you do it - it's still in the source package
[17:20] <Esokrates> slangasek: why is the hook missing then in the binary package?
[17:23] <Esokrates> slangasek: where is the hook exactly in the source? which file?
[17:29] <slangasek> Esokrates: I'm sorry, I really don't have time to help with this right now
[17:29] <Esokrates> slangasek: no problem, can we talk another time about the root problem?
[17:30] <slangasek> well, probably best to use the bug report for this, as I can't commit to a specific time :)
[17:30] <Esokrates> slangasek: (I hope in a few days the hook will be fixed by updates, then I will rerun the apport-collect)
[17:32] <bdmurray> Esokrates: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/plymouth/trusty/view/head:/debian/libplymouth2.apport that's the code in the hook
[17:32] <bdmurray> Esokrates: so just download it and put it where slangasek said
[17:33] <Esokrates> bdmurray: thanks a lot
[17:46] <Esokrates> slangasek, bdmurray: all done now, thanks a lot for your patience
[18:25] <infinity> cjwatson: Steal away, if yuo didn't already.
[19:28] <ajalkane> Can anyone give me some indicators where to start off with fixing this bug: https://bugs.launchpad.net/hud/+bug/1165420 (Unable to access indicators from HUD)
[19:45] <Unit193> cjwatson: Great!  Thank you very much.
[19:53] <xnox> slangasek: yes i have, please explain why is it in the library package?
[19:53] <xnox> slangasek: it cause uninstallability and all buildd chroots broke, cause libplymouthN conflicted with libplymouthN+1 yet both are needed to be installed during rebuild / binNMUs.
[19:53] <xnox> slangasek: is it ok to place the hook in "plymouth" package rather than "libplymouthN+1" ?
[20:00] <infinity> xnox: Apport hooks in library packages (unless ABI versioned) definitely seems like a mistake.
[20:00] <infinity> Though, ABI versioning it would fix that mistake just as well as moving it to the plymouth package.
[20:01] <xnox> infinity: well the hook was "source_plymouth" or some such, and thus covers all binaries coming from src:plymouth, not just libplymouthN
[20:01] <xnox> infinity: i could just move it into the apport package =)
[20:02] <infinity> Ick.
[20:02] <xnox> or make them .deb metadata =)))
[20:03] <infinity> xnox: Which is effectively versioning it with the package name.
[20:03] <infinity> xnox: If you just install it with the library package name, that fixes the conflict.  Why complicate things?
[20:04] <xnox> doesn't cover everything that the hook used to do.
[20:05] <infinity> Oh, you mean apport chooses what to trigger for based on the filename?
[20:05] <xnox> e.g. $ ubuntu-bug plymouth, used to collect all plymouth data from that hook.
[20:05] <infinity> That's unclever.
[20:05] <xnox> yes.
[20:05] <infinity> In that case, though, I guess moving it to the plymouth binary is the least of current evils.
[20:05] <xnox> if it's named source_$srcname.py, it's triggered for all binaries from $srcname.
[20:12] <labsin> I'm having issues with the propertary ATI drivers and i386 apps. FI steam and the ubuntu-emulator
[20:13] <labsin> I get no HWA
[20:14] <labsin> It seems to be a problem with the existance of both /usr/lib32/fglrx/libGL.so.1.2 and /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0
[20:14] <labsin> the first is from fglrx-updates and the second is from libgl1-mesa-glx:i386
[20:15] <labsin> If I set LD_LIBRARY_PATH to /usr/lib32/fglrx the issue is gone.
[20:17] <labsin> But wat is a permanent solution. I can't seem to remove  libgl1-mesa-glx:i386
[20:18] <labsin> And if/where I should post a bug report
[20:18] <infinity> labsin: Please file a bug on whatever package is providing the fglrx driver (assuming it's from Ubuntu, not upstream), and make tseliot aware of it.
[20:19] <infinity> labsin: The proprietary driver packages are supposed to do clever/icky things to divert the mesa libGL out of the way, but maybe he missed a case.
[20:20] <labsin> infinity, ok
[20:26] <mlankhorst> ooh mesa 10.3-rc1 released..
[20:28] <tinoco> please, would anyone know arm64 repository location ?
[20:28] <tinoco> W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/binary-arm64/Packages  404  Not Found [IP: 91.189.91.15 80]
[20:31] <tinoco> nm, http://ports.ubuntu.com/ubuntu-ports/dists/
[20:31] <tinoco> tks
[20:34] <mlankhorst> infinity: hey can i get a ffe for mesa 10.3-rc1 for next week? :P
[20:35] <infinity> mlankhorst: Ask me next week. :P
[20:35] <mlankhorst> I rather get some testign done first
[20:35] <infinity> mlankhorst: More seriously, what's upstream timetable for final release and point-releases?  Are we likely to have 10.3.1 by release?
[20:36] <mlankhorst> yeah
[20:36] <infinity> mlankhorst: Cause .0 releases from mesa are pretty... Raw.
[20:36] <mlankhorst> it's imrpvoed a lot lately
[20:36] <infinity> I'll believe that when I see it.
[20:36] <infinity> I'd still be more comfy with approving if I know we'll be able to get a .1 or .2 in.
[20:36] <mlankhorst>  ]
[20:37] <mlankhorst> yeah I'll take a look, should be fine
[20:40] <labsin> infinity, filed: https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1307466
[20:41] <labsin> sorry https://bugs.launchpad.net/ubuntu/+source/fglrx-installer-updates/+bug/1359960
[20:59] <Sarvatt> mesa 10.3 final is september 5th, point releases are every 2 weeks after unless its an emergency and they go out faster, well in time for final freeze
[21:21] <robert_ancell> mterry, is the "surfaceflinger" seat type in lightdm still used anymore? I'd like to drop if it now
[21:21] <robert_ancell> not
[21:22] <mterry> robert_ancell, no it's not
[21:22] <robert_ancell> ok, it's dead :)
[21:22] <mterry> rip