[01:11] <catbus1> Does anyone know when 14.04.2 will be released?
[01:13] <Sarvatt> catbus1: https://wiki.ubuntu.com/DraftReleaseSchedule feb 5th
[01:14] <Sarvatt> which is actually cutting it pretty close because the lts backport X stack *just* got in :D
[01:15] <catbus1> Sarvatt: thank you.
[01:45] <ari-tczew> cyphermox: around?
[02:03] <cyphermox> ari-tczew: yes
[02:03] <ari-tczew> cyphermox: hi. I saw the stuff is moved to -release. do you still need a help?
[02:04] <cyphermox> no, that's covered I guess
[02:04] <cyphermox> unless you want to merge the other vpn plugins, I'm not sure when I'll get around to those
[02:05] <ari-tczew> cyphermox: I can take those. The question is, should do I just merge from Debian, or additionally upgrade to new upstream release?
=== doko_ is now known as doko
[02:06] <cyphermox> I think they're already at their newest release, but that's up to you
[02:06] <cyphermox> I would merge + update if it's worth updating
[02:08] <cyphermox> Logan_: hey, btw n-m-iodine migrated to -release if you didn't notice yet :)
[02:08] <Logan_> I saw :)
[02:09] <cyphermox> great.
[02:10] <cyphermox> I'm not sure if iodine is the plugin I never ever managed to make work properly ;)
=== timrc is now known as timrc-zzz
[06:50] <pitti> Good morning
[06:53] <Unit193> Howdy.
[07:49] <dholbach> good morning
[08:16] <LocutusOfBorg1> hi dear developerz
[08:16] <LocutusOfBorg1> does anybody know which kernel will land on vivid?
=== anthonyf is now known as Guest44978
[08:53] <alkisg> mvo, stgraber: hi, could I ping you about LP #1415785 ? update-manager blacklists ltsp, and removes it on dist-upgrades (normal upgrades, not release upgrades), and that breaks ltsp installations. I'd like to help in fixing + SRU'ing this for 14.04 and 12.04...
[08:53] <ubottu> Launchpad bug 1415785 in update-manager (Ubuntu) "Please remove all ltsp* blacklisting" [Undecided,New] https://launchpad.net/bugs/1415785
[08:54] <mvo> alkisg: thanks, if you could prepare a diff and the sru test instruction I'm happy to sponsor it for you
[08:55] <alkisg> Thank you mvo, will do
=== dendroba` is now known as dendrobates
[09:16] <infinity> mlankhorst: Does libevdev need a utopic->trusty backport too, or will my copying the trust/universe version to trusty-updates/main be enough to make xserver-xorg-input-evdev and xserver-xorg-input-synaptics happy?
[09:21] <mlankhorst> infinity: I didn't update it at least
[09:21] <mlankhorst> and works locally
[09:22] <infinity> mlankhorst: Alright.  We'll see how that goes, then.  I think those are the only two not built now.
[09:22] <mlankhorst> ah k
[09:27] <Odd_Bloke> I'm hitting "libgcc1 : Depends: gcc-5-base (= 5-20150128-0ubuntu1) but it is not installable" when building arm64/ppc64el images; is this (likely to be) a transient problem, or should I report a bug?
[09:30] <mlankhorst> do you have -proposed enabled?
[09:31] <Odd_Bloke> mlankhorst: Shouldn't do; Ctrl-F of the build log (https://launchpadlibrarian.net/196091740/buildlog_ubuntu_vivid_arm64_cpc_FAILEDTOBUILD.txt.gz) suggests proposed isn't mentioned anywhere.
[09:33] <Odd_Bloke> It is in http://ports.ubuntu.com/dists/vivid/main/binary-ppc64el/Packages.bz2.
[09:34] <cjwatson> Odd_Bloke: It's a component mismatch.  Fixing.
[09:35] <mlankhorst> ah
[09:36] <cjwatson> Odd_Bloke: Retry your build once "rmadison gcc-5-base" says "vivid" rather than "vivid/universe" (give it maybe half an hour or so)
[09:36] <Odd_Bloke> cjwatson: Thanks, will do.
[09:38] <Odd_Bloke> For my understanding, does this mean that someone uploaded gcc-5-base in to universe when it should have been uploaded to main?
[09:38] <cjwatson> Odd_Bloke: Components are overridden centrally, not in general up to the uploader.  New packages tend to land in universe.
[09:39] <cjwatson> So if they're dependencies of stuff in main then we need to adjust the overrides to account for that.
[09:39] <cjwatson> Often this requires an explicit signed-off main inclusion request, but in this case that wasn't necessary since gccgo-5 is obviously just a newer version of stuff already in main.
[09:39] <cjwatson> (that's the source package building gcc-5-base right now)
[09:40] <Odd_Bloke> Right, got it.
[10:08] <Odd_Bloke> cjwatson: Not sure if what you've done will cover it, but "gcc-5-base | 5-20150128-0ubuntu1 | vivid-proposed/universe | armhf" just popped up in the rmadison output as well.
[10:09] <cjwatson> Odd_Bloke: It'll be easier to check after an archive cycle or two when our reports update.
[10:09] <Odd_Bloke> Cool.
=== lilstevie is now known as lilstevie|Old
=== alkisg is now known as work_alkisg
[11:36] <mlankhorst> doko: are you there?
[11:39] <mlankhorst> I did some testing on 10.4.2 vs 10.4.2 with llvm-3.6, results look good. r600 with experimental llvm had no regressions compared to !llvm, swrast i386 and amd64 look good too..
[11:43] <mitya57> sil2100: hi, I am going to upload oxide-qt to landing-005, do you know if there should be any differences against the archive version?
[11:44] <mitya57> I see two patches in d/patches, but not sure if that's all or they are still needed
[11:45] <sil2100> mitya57: hah, hey, we just briefly talked about that with tsdgeos - not sure about that, but from Mirv's e-mail I somehow felt that some changes were needed, I think Timo added hack_qt540.patch to make it buildable
[11:45] <sil2100> And made some packaging changes
[11:45] <sil2100> So this might need rebasing on the newer oxide
[11:46] <sil2100> As I didn't hear anything about those being ported upstream
=== _salem is now known as salem_
[11:49] <mitya57> sil2100: I see that Timo had two patches but looks like the second one is no longer needed.
[11:51] <mitya57> I don't see any other packaging changes
[11:53] <mitya57> sil2100: Ok, I have something that I can upload and see if it builds
[11:54] <sil2100> mitya57: thanks :) oxide is really huge, we might need to bump the PPA size limit in case a re-upload is needed
[11:54] <cjwatson> Let me check the current size limits
[11:56] <cjwatson> ubuntu/landing-005 already has a 20GiB limit.  It seems unlikely that you'll run into trouble.
[12:00] <mitya57> yes, should be no problem
[12:02] <mitya57> uploaded
[12:24] <rbasak> infinity: around for the mysql chat?
=== MacSlow is now known as MacSlow|lunch
[12:43] <mlankhorst> doko: I've uploaded mesa 10.4.2-2ubuntu2
[12:47] <doko> mlankhorst, so from your point is it ok to make 3.6 the default?
[12:50] <mlankhorst> yeah looks like it
=== pfsmorigo_ is now known as pfsmorigo
[12:53] <mlankhorst> and pushed the changes for it :p
[12:54] <mitya57> sil2100: btw I just committed your qtbase change to bzr, so that it's again in sync with ppa
[12:58] <jrwren> ~
[13:07] <pitti> cyphermox: oh, now I understand what you meant by NM 0.9.10 having veth support -- when I start/stop LXC containers I get a ton of "you are now connected to vethDH32FO" notifications
=== didrocks1 is now known as didrocks
[13:34] <shadeslayer> mvo: did you notice the synaptic upload got rejected
=== MacSlow|lunch is now known as MacSlow
[14:09] <cyphermox> pitti: yeah. I'm considering patching that out of nm-applet or something
[14:15] <sil2100> mitya57: thanks! That was one thing I wasn't sure about, if we are using a bzr branch to keep track of the current ongoing work or not
[14:24] <mitya57> sil2100: the 5.4 packaging is in qtFOO-opensource-src branches, while 5.3.2 is in qtFOO-opensource-src_532
[14:25] <sil2100> ah, ok, saw the _532 but still wasn't sure if the trunk ones are supposed to have our 'experimental' bits in it
[14:31] <pitti> cyphermox: should they even be considered connections that NM has to care about?
[14:32] <cyphermox> pitti: they are already not managed, all you really do is connect/disconnect, and if you really want you could change settings (not that it wouldn't break things)
[14:32] <pitti> (brb)
[14:38] <cyphermox> that's why I'm thinking explicitly ignoring the virtual devices in nm-applet, since one probably shouldn't touch them, but NM isn't breaking them
[14:38] <cyphermox> pitti: ^
[14:38] <pitti> cyphermox: *nod*, thanks
[14:39] <pitti> ah, and I see lxcbr0 now, too
[14:39] <pitti> with an option to disconnect it
[14:39] <cyphermox> yep
[14:39] <cyphermox> they all come up as virtual devices, and pretty clearly separated in nm-applet so hiding those should be trivial
[14:40] <cyphermox> I'd do the same for VLANs, tunnels, bridges, bonds
[14:40] <cyphermox> not usually that common on desktop machines, or at least not in a case where you actually want to touch them
=== timrc-zzz is now known as timrc
[15:35] <lefteris> hi there, i want to make an sru in update-manager
[15:36] <lefteris> i read the wiki for sru and says that firstly must branch and apply the fix to the development branch (vivid)
[15:38] <lefteris> i am using ubuntu 12.04; should i download ubuntu 15.04 for building the source and testing it
[15:38] <infinity> lefteris: Working on the branches isn't strictly required, you can just file a bug and attach patches.
[15:39] <infinity> (against the source from the archive)
[15:39] <lefteris> or i can to build the source to the presice
[15:42] <lefteris> infinity: hello, firtsly; thanks for your help
[15:47] <lefteris> my actual question is: if i want to debuild the source code from vivid branch must have ubuntu 15.04 or i can to do this from precise; i am aksing because debuilding source code of vivid require python3-all 3.3.0-2 and in precise is available the python3-all 3.2.3-0ubuntu1.2
[15:47] <lefteris> sorry, my question may be stupid, but i am new to making sru's
[15:49] <cjwatson> lefteris: For your test build, you should use a clean 15.04 build environment, but that doesn't involve upgrading your base system.  https://wiki.ubuntu.com/SimpleSbuild
[15:49] <cjwatson> lefteris: If you set that up then you can also use an schroot environment for running "debuild -S" easily enough
[15:51] <cjwatson> lefteris: Though in this particular case it probably doesn't actually matter just for building the source package; I'd be inclined to use "debuild -d -S" to ignore build-dependencies, and then compare the source packages with debdiff on the old and new .dsc files to make sure that didn't introduce anything unexpected
[15:51] <cjwatson> lefteris: But for building the binary packages you should definitely use sbuild or similar, not try to get it to build on your 12.04 base system.
[15:51] <LocutusOfBorg1> dholbach, kbuild sync from debian/experimental? (bug 1408285) :D
[15:51] <ubottu> bug 1408285 in kbuild (Ubuntu) "Please sync kbuild, virtualbox and virtualbox-guest-additions-iso from debian/experimental" [Undecided,Confirmed] https://launchpad.net/bugs/1408285
[15:52] <dholbach> let me take a look
[15:52] <LocutusOfBorg1> :)
[15:53] <lefteris> cjwatson, infinity: thank you very much for your help
[15:54] <lefteris> cjwatson: οκ, i got it; thank you
[16:05] <LocutusOfBorg1> thanks dholbach :)
[16:05] <dholbach> anytime
[16:16] <pitti> dobey: look! "autopilot PASS" with --setup-commands ubuntu-touch-session :)
[16:17] <pitti> dobey: thanks for the report
[16:17] <balloons> woot!
[16:18] <pitti> seems vivid's upstart changed behaviour a bit
[16:18] <pitti> that was in qemu, testing in LXC now for completeness
[16:19] <dobey> pitti: nice :)
[16:20] <pitti> wow, that fails with http://paste.ubuntu.com/9939333/, but I'm not sure that's my fault
[16:21] <pitti> yep, python3 -c 'import psutil' reproduces it
[16:22] <dobey> fun
[16:25]  * pitti files a Debian bug
=== work_alkisg is now known as alkisg
[16:33] <pitti> dobey: ok, bug sent, so running in LXC is broken for now; but qemu at least works fine now
[16:37] <ovidiu_calbajos> hello all, do you know if the libc6 has been patched already for the ubuntu 12.04 openvz image?
[16:38] <infinity> ovidiu_calbajos: You might need to elaborate on what you mean.
[16:40] <ovidiu_calbajos> hi infinity, well one of my clients tries to update the libc6 library on his machine and doesn't get any update, also i couldn't find anything related to libc6 + openvz + ubuntu 12.04 + ghost vulnerability on the internet
[16:40] <pitti> I suppose the recent security fix?
[16:40] <zyga> tseliot: hey
[16:40] <pitti> ah yes, ghost
[16:40] <infinity> ovidiu_calbajos: Oh.  openvz rolls their own libc.  We know nothing about that, here.
[16:40] <zyga> tseliot: are you the right person to talk about graphics, drivers and such?
[16:40] <infinity> ovidiu_calbajos: The libc6 that we provide for 12.04 has been updated.
[16:41] <ovidiu_calbajos> infinity: indeed I saw the update on the 12.04 but I didn't see it on openvz
[16:41] <ovidiu_calbajos> thank you for your time
[16:41] <infinity> ovidiu_calbajos: In other words, this is a question for openvz, not for Ubuntu.
[16:42] <ovidiu_calbajos> infinity: thanks again, I will try to contact them :)
[16:47] <zyga> tseliot: I want to ask you about a potential candidate for GPU stress tests
[16:47] <zyga> tseliot: and if you have heard of the tool or others like it http://wili.cc/blog/gpu-burn.html
[17:05] <tseliot> zyga: I'll have a look and let you know
[17:08] <zyga> tseliot: thanks
[17:27] <tseliot> zyga: I think that would be limited to the nvidia binary driver, as it involves using CUDA (I had a quick look)
[17:32] <dobey> pitti: awesome. i guess i'll need to grab the deb from vivid to install on the host, or it will just update when i run the tests and work?
[17:33] <pitti> dobey: right, you need vivid's autopkgtest package (but you need that anyway if you want to do anything on the touch platform)
[17:33] <zyga> tseliot: do you know of other tools that we could use for stress testing GPUs?
[17:33] <pitti> dobey: note that ATM the fix is only in git, I didn't upload to Debian/Ubuntu yet
[17:34] <pitti> dobey: you can of course check out git if you want and run /your/checkout/dir/run-from-checkout
[17:34] <pitti> dobey: or just grab the fixed setup script and copy it to your machine :) (http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/plain/setup-commands/ubuntu-touch-session)
[17:34] <dobey> pitti: do i need it on the host or just in the vm though?
[17:35] <pitti> dobey: it's unrelated to the VM; just on the system where you call adt-run
[17:35] <pitti> dobey: i. e. --setup-commands <path to that script>
[17:35] <dobey> pitti: ok. i wasn't sure if it was using the one on the host or in the vm for that
[17:36] <pitti> dobey: the VM doesn't have anything special (it can be any VM, or you can use a schroot, or a phone, or whatever)
[17:36] <dobey> anyway, copied the new script onto my host and trying a run now :)
[17:37] <tseliot> zyga: that would be tests that involve using OpenGL. I think checkbox already uses the phoronix test suite, which, in turn, relies on some OpenGL tests.
[17:44] <zyga> tseliot: I don't recall if we use any stress tests from pts
[17:45] <zyga> tseliot: and we definitely don't have anything for opencl (or cuda)
[17:45] <zyga> tseliot: so in general, the tool I've likned to is suitable for nvidia but not applicable for amd/intel, is that accurate?
[17:46] <tseliot> zyga: opencl would work with both fglrx and nvidia. I'm not sure we support opencl with open drivers. Cuda is nvidia only AFAIK
[17:46] <tseliot> mlankhorst, Sarvatt: ^
[17:46] <dobey> pitti: well, my tests still fail, but with a different error now :)
[17:46] <tseliot> tjaalton: ^
[17:46] <dobey> ** (run.py:17865): WARNING **: Unable to find keyfile for application 'com.canonical.payui_payui_15.01.last'
[17:46] <dobey> not sure how to fix that though
[17:46] <pitti> dobey: ok, that's not my bug then :) is that gsettings? missing schema?
[17:47] <dobey> pitti: i think it's ubuntu-app-launch complaining
[17:47] <dobey> i guess it can't find the .desktop file for some reason
[17:47] <pitti> dobey: ah, bug 1333215
[17:47] <ubottu> bug 1333215 in ubuntu-app-launch (Ubuntu) ""Unable to find keyfile for application": clicks installed in current session don't create UAL cache, and UAL does not look for .desktop files in click pkgdir" [High,Triaged] https://launchpad.net/bugs/1333215
[17:49] <zyga> tseliot: right about cuda, I don't know the current opencl story, I know all three vendors do their own drivers but they are not open IIRC
[17:50] <pitti> dobey: you could work around it by "click install"ing it manually on the phone, restarting, and then running adt-run --click com.ubuntu.whatever (i. e. name instaed of a local .click file)
[17:50] <dobey> pitti: oh i guess so
[17:50] <dobey> pitti: well this is in qemu so phone won't help i guess :)
[17:50] <pitti> dobey: I tried that with the calculator in qemu and it worked fine though
[17:50] <pitti> dobey: hm, I wonder what I did differently then
[17:50] <dobey> i wonder why the hooks aren't run when the package is installed in qemu?
[17:51] <pitti> dobey: oh, which autopkgtest version do you have?
[17:51] <pitti> dobey: it's not specific to qemu or lxc; it's a bug which affects all click packages
[17:51] <dobey> pitti: 3.0.1
[17:51] <pitti> dobey: eww old; try the current vivid one, I think I added a workaround for this some moons ago
[17:52] <pitti> dobey: you can just download the deb and install it on anything >= precise
[17:52] <dobey> oh i thought it was the latest. it was a month ago when i installed it anyway :)
[17:54] <pitti> dobey: hm, trusty has 2.14, utopic has 3.6, vivid 3.9.3; so 3.0 isn't actually that easy to get :)
[17:54] <dobey> i should set up a recipe for backports of it in my ppa
[17:54] <dobey> pitti: vivid only got 3.9.3 yesterday :)
[17:54] <dobey> or well, tuesday
[17:55] <dobey> oh, when did i install 3.0.1
[17:55] <dobey> weird
[17:56] <dobey> whenever the last time you told me to install the latest version was, i guess :)
[17:56] <dobey> i guess i should set up a backport recipe for it, to make life easier
[17:56] <pitti> git! git! git! :-)
[17:57] <dobey> is there an upstream import of it into bzr? :)
[17:57] <pitti> Date:   Thu Jul 3 07:47:54 2014 +0200
[17:57] <pitti>     Fix workaround for LP #1333215
[17:57] <ubottu> Launchpad bug 1333215 in ubuntu-app-launch (Ubuntu) ""Unable to find keyfile for application": clicks installed in current session don't create UAL cache, and UAL does not look for .desktop files in click pkgdir" [High,Triaged] https://launchpad.net/bugs/1333215
[17:58] <pitti> dobey: so the workaround for it was quite some time ago, but it landed in 3.1
[17:58] <pitti> so 3.0.1 is only just a teensy bit too old
[17:58] <dobey> well, whatever. SRU it or set up a backports PPA if you want people to always use the latest version :)
[17:58] <pitti> vila has something like that
[17:59] <pitti> git import -> LP recipe
[17:59] <vila> git clone <url> trunk
[18:00] <vila> bzr branch trunk feature
[18:00] <pitti> vila: no, I mean your "crack of the day" autopkgtest PPA
[18:00] <vila> me too ;-)
[18:00] <vila> cd autopkgest ; git pull
[18:00] <vila> cd ../vila
[18:00] <vila> bzr pull
[18:00] <vila> test
[18:00] <vila> bzr push
[18:01] <vila> trigger recipe
[18:01] <pitti> ah, ok; I thought you set up an automatic bzr import (these work rather well)
[18:01] <vila> bzr-git seems to work far better when dealing with a local repo than with a remote repo
[18:02] <pitti> no, I mean LP does it all for you
[18:02] <pitti> e. g. https://code.launchpad.net/~pitti/python-dbusmock/trunk is an automatic import of git
[18:03] <vila> I don't do git push either (which is nice ;)
[18:03] <dobey> and launchpad uses bzr-git
[18:03] <dobey> manually pulling/pushing/etc seems like a pain in the ass for building a PPA package
[18:04] <vila> pitti: oh, for a backports PPA, sorry, missed that bit
[18:04] <dobey> pitti: lol. anyway, i updated and still get the keyfile error :-/
[18:04]  * pitti uploads autopkgtest 3.9.4 to Debian sid, will auto-import into vivid tomorrow
[18:04] <pitti> dobey: meh; I wonder if your click is slightly different than the calculator then
[18:05] <pitti> dobey: feel free to open another bug and attach (or point to) click source and binary, then I can have a look on Monday?
[18:05] <pitti> (systemd hackfest tomorrow, and EOD today, sorry)
[18:05] <dobey> oh
[18:06] <dobey> pitti: yes, payui isn't an actual app
[18:06] <dobey> pitti: so not your bug. i'll talk to ted about it
[18:06] <tjaalton> zyga, tseliot: enabling opencl in mesa needs some packages moved to main first, and there is a plan to enable it once the MIR is done
[18:06] <pitti> dobey: hm, still sounds related (or even identical) to #1333215?
[18:06] <dobey> pitti: nope
[18:07] <dobey> pitti: this doesn't have a "desktop" entry in the manifest, so there is no .desktop file in ~/.local/share/applications/ (and there isn't supposed to be)
[18:07] <dobey> pitti: so will have to figure out something special cased for this in our ap tests
[18:07] <dobey> pitti: so i'll talk to ted and leo about it
[18:08] <pitti> ah, ok; cheers!
=== alkisg is now known as work_alkisg
=== anthonyf is now known as Guest89771
=== work_alkisg is now known as alkisg
=== mwenning is now known as mwenning-rr5
=== alkisg is now known as work_alkisg
[19:39] <Noskcaj> Laney, Are you planning to package pinta 1.5 somewhere?
=== neunon_ is now known as neunon
=== Bluefoxicy_ is now known as Bluefoxicy
=== danwest_ is now known as danwest
=== liam_ is now known as Guest91492
=== SpamapS_ is now known as SpamapS
=== salem_ is now known as _salem
=== work_alkisg is now known as alkisg
=== beisner- is now known as beisner
=== alkisg is now known as work_alkisg
=== jdstrand_ is now known as jdstrand
=== lionel_ is now known as lionel