[03:43] <pitti> Good morning
[03:44] <pitti> infinity, xnox: if you install the hook as "source_plymouth.py" it will apply to any binary package of the "plymouth" source
[03:44] <pitti> ah right, xnox said that
[03:45] <pitti> bdmurray: saw your mail, will look and reply
[03:49] <infinity> pitti: Right, my complaint was exactly that it was keying off filename. ;)
[03:50] <infinity> pitti: (which is what leads to the bug where you can't have it in a library package)
[03:51] <infinity> And if the library is the lowest common denominator of your source package stack, that seems the sensible place to have the source-wide hook.
[03:51] <pitti> right, you can't put a source_ hook into a lib pacakge, but certainly a hook for that lib package
[03:51] <infinity> Anyhow, I think xnox is just going to move it from libplymouth to plymouth and call it good enough.
[04:09] <pitti> cjwatson: the perl transition now caused a number of failures due to a new warning "push on reference is experimental" on stderr; is that expected and should the tests be adjusted to ignore this, or should this be fixed (or suppressed)?
[04:28] <cjwatson> pitti: tests should be fixed not to do that; if they are really sure they want to use that feature then there's a switch available in perl to suppress the warning.  http://search.cpan.org/dist/perl-5.20.0/pod/perldelta.pod#New_Warnings
[04:28] <slangasek> xnox: it's in the library package because that's the base package that all other packages depend on, so ensures that it's always present.  A simple Replaces: would have sufficed to handle the file conflict (without even a Breaks:)  But if you want to move it from the libplymouth package to the plymouth package, that seems ok
[04:28] <pitti> cjwatson: oh wow, didn't expect you at that hour :)
[04:28] <pitti> cjwatson: ah wait, debconf
[04:28] <cjwatson> travelling today
[04:30] <slangasek> :)
[04:54] <infinity> slangasek: Using replaces that way is generally considered wrong, though.
[04:55] <infinity> slangasek: Since it can lead to missing files (though, I guess in a library ABI bump, the odds of going backwards are slim).
[04:59] <slangasek> infinity: as the only replaced file here was an apport hook, going backwards doesn't break the package's main functionality anyway
[04:59] <infinity> slangasek: True.
[06:39] <dholbach> good morning
[06:40] <doko> jamespag`, please could you have a look at the mysql-5.5 autopkg test failure? blocks perl (and mysql-5.6 autopkg tests always failed)
[06:50] <pitti> wgrant: nevermind mangling the utopic langpack cronjob; I did a workaround yesterday for updating the touch langpacks straight out of the upstream trunks
[06:52] <LocutusOfBorg1> Hi doko do you think debian 727330 can be closed? The package build also on ppc64el and arm64
[06:54] <LocutusOfBorg1> bdrung, you there?
[06:56] <LocutusOfBorg1> I would like to merge vlc master-daily (ppa) with the debian git, to fix the FTBFS
[07:37] <jfi_> Hello, what is the correct way to checkout the utopic branch of a package? bzr branch lp:ubuntu/utopic/<pkg> retrieves the trusty branch.
[07:39] <geser> jfi_: which package? have you checked if it's listed on http://package-import.ubuntu.com/status/ having issues?
[07:40] <jfi_> geser, the pkg that I am trying to checkout (to fix a major bug) is: psensor (https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/psensor/utopic)
[07:40] <jfi_> geser, the pkg (psensor) is in this list
[07:41] <geser> http://package-import.ubuntu.com/status/psensor.html#2014-04-08%2014:18:53.940182
[07:43] <pitti> doko: libtbfs-perl apparently needs to be rebuilt for new perl? it's uninstallable
[07:44] <pitti> doko: lintian4python, adequate, and liblingua-en-numbers-ordinate-perl succeed again with fixed adequate
[07:44] <jfi_> geser, hum, it means that the bzr repository is corrupted for this package and I need to report a bug to get some attention about it?
[07:45] <pitti> doko: hmm, seems https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735623 is in the way for libtfbs-perl, as its build-dep pdl fails on powerpc; we might just remove it from powerpc then?
[07:46] <geser> jfi_: yes, it's at least out-of-date (which explains why you got the trusty version from the utopic branch). I'm not sure what's the correct process to get this fixed
[07:46] <Saviq> mardy, hey, I got "Ubuntu One" greyed out in accounts after account removal
[07:46] <Saviq> mardy, guys in London saw that last week, too, anything I can get you to debug? how can I recover?
[07:47] <mardy> Saviq: weird, it gets greyed out once there is an U1 account
[07:47] <mardy> Saviq: can you do "account-console list" and see if there's still an U1 account?
[07:47] <Saviq> mardy, yeah, ssweeny saw that the account didn't get removed properly
[07:47] <Saviq> mardy, hmm no, empty
[07:48] <Saviq> mardy, ah now it's back, but doesn't open...
[07:48] <mardy> Saviq: how did you make it come back? did you exit from system settings?
[07:48] <Saviq> mardy, yes
[07:48] <doko> pitti, now synced pdl, although this won't fix things. I'll check to demote/remove pdl/libtfbs-perl
[07:49] <Saviq> mardy, it's meant to work via trusted sessions now is it?
[07:49] <mardy> Saviq: yes
[07:49] <Saviq> mardy, so ok, the fact that doesn't open seems to be our fault (testing silo)
[07:49] <mardy> Saviq: so, you click, but nothing happens?
[07:49] <Saviq> mardy, yeah, looks like a problem in our silo
[07:49] <pitti> doko: only rdepends of libtfbs-perl is med-bio-dev (only a recommends), so removing that on powerpc seems fine
[07:50] <Saviq> mardy, and I can't reproduce the greyed-out with another phone...
[07:50] <jfi_> geser, Thanks for pointing me to the pkg import page. I am going to submit my patch as a debdiff and try to find the best way to report the bzr/lp issue.
[07:50] <Saviq> mardy, ok, will report back if I see it again, for now, as you were ;)
[07:52] <doko> pitti, otoh, maybe just lets ignore the test results on powerpc?
[07:52] <doko> Result: FAIL
[07:52] <doko> Failed 3/124 test programs. 0/1775 subtests failed.
[07:52] <pitti> doko: hm, I'd avoid sourceful changes and just remove it from ppc -- who cares..
[07:53] <pitti> but either way
[07:53] <pitti> but like that, as soon as it gets fixed in Debian it'll automatically come back
[07:53] <doko> $ apt-cache rdepends pdl
[07:53] <doko> pdl
[07:53] <doko> Reverse Depends:
[07:53] <doko>   pdl:i386
[07:53] <doko>   science-viewing
[07:53] <doko>   science-numericalcomputation
[07:53] <doko>   science-astronomy
[07:53] <doko>   libtfbs-perl
[07:53] <doko>   libpdl-stats-perl
[07:53] <doko>   libpdl-netcdf-perl
[07:53] <doko>   libpdl-linearalgebra-perl
[07:53] <pitti> doko: oh, you mean pdl
[07:53] <doko>   libpdl-io-matlab-perl
[07:53] <doko>   libpadre-plugin-pdl-perl
[07:54] <pitti> I was thinking of libtfbs; pdl is already not available on powerpc, so no need to change anything there
[08:02] <doko> pitti, ok, done, and libtfbs-perl uploaded
[08:05] <highvolt1ge> dayangkun:
[08:30] <pitti> doko: cool, thanks! still looking into orafce, I have a reproducer and filed an upstream bug now (https://github.com/orafce/orafce/issues/15)
[09:18] <tkamppeter> doko, is printer-driver-brlaser seeded in Utopic now (bug 1355136)?
[09:19] <pitti> tkamppeter: I thought we had some magic to auto-install printer driver packages?
[09:23] <tkamppeter> pitti, for  Ubuntu packages of printer drivers?
[09:23] <tkamppeter> pitti, I see a lot of Recommends: for printer drivers in ubuntu-desktop.
[09:23] <pitti> tkamppeter: ubuntu or openprinting.org, etc.
[09:23] <pitti> yes, I know; but that has  always felt like a workaround
[09:23] <pitti> we install video codecs and other stuff on demand, for printer drivers this would be even more appropriate
[09:24] <tkamppeter> pitti, there is a mechanism to auto-install drivers via OpenPrinting, but these are LSB packages or PPDs directly from manufacturers.
[09:24] <pitti> tkamppeter: ah, I thought we had something similar for ubuntu packages
[09:25] <pitti> probably mixed it up with ubuntu-drivers-common for other hw
[09:29] <tkamppeter> pitti, can you add printer-driver-brlaser to ubuntu-meta when it is not yet done so (bug 1359137, bug 1355136). Thanks.
[09:32] <pitti> tkamppeter: seeded to platform.utopic desktop-common, so all the metapackages will pick it up on next rebuild
[09:34] <tkamppeter> pitti, thank you very much.
[09:51] <Saviq> jodh, hey, could you please help mzanetti with an upstart job based on the file bridge, he's not getting delete or change events, just create
[09:51] <Saviq> mzanetti, can you give more details ↑?
[09:52] <mzanetti> jodh: have this job for a test: http://paste.ubuntu.com/8112758/
[09:52] <mzanetti> jodh: doing a "start unity8-filewatcher" works fine... but doesn't get executed when doing touch/rm ~/.local/share/applications/foo.desktop
[10:27] <zyga> mvo_: hey, do you have a moment to look at interesting apt related case?
[10:27] <zyga> mvo_: https://code.launchpad.net/~roadmr/checkbox/ppppcc-glmark2-es2/+merge/231788
[10:27] <zyga> mvo_: look at the dependencies there
[10:28] <zyga> mvo_: is that the right way to handle this?
[10:44] <jodh> mzanetti: hmm - looks like there might be a problem with globs coupled with tilde expansion. Please can you raise an upstart bug. Meantime, you could use something like http://paste.ubuntu.com/8113277/
[10:45] <mzanetti> jodh: hey, thanks! yes, I'll try your suggestion and file a bug
[10:48] <mzanetti> indeed, hardcoding /home/phablet/ makes it work
[10:49] <mzanetti> I wonder if/how url-dispatcher-update.conf works then
[11:10] <mvo_> zyga: I need a moment to look into the detail (a bit busy right now due rtm/debconf)
[11:19] <Saviq> mzanetti, we've had it *not* work from time to time, too
[11:19] <Saviq> mzanetti, so that could explain it
[11:20] <kdeuser56> does partman allow reusing partitions somehow?
[11:23] <mzanetti> Saviq: ok... this should improve the situation: https://code.launchpad.net/~mzanetti/unity8/update-launcher-on-appdate/+merge/231866
[11:24] <Saviq> mzanetti, I think James suggested FILE=~/.local/share/applications MATCH=*.desktop
[11:24] <mzanetti> Saviq: not directly, but I agree worth a try
[11:25] <Saviq> mzanetti, although manual does not list that as a possibility...
[11:26] <mzanetti> Saviq: well, let me try. would be better than hardcoding to phablet
[11:26] <Saviq> mzanetti, you could also try .local/share/applications/*.desktop
[11:26] <Saviq> mzanetti, ~/ is implicit
[11:27] <Saviq> mzanetti, ah and it needs to have a trailing slash if it's a dir
[11:30] <zyga> mvo_: sure, no rush
[11:34] <mzanetti> Saviq: nope... both not working
[11:34] <Saviq> mzanetti, :|
[12:31] <Mirv> mlankhorst: hey there! the SDK team still has a regression with the new LLVM 3.5, so unfortunately the x86 tests are now again failing with LLVM error https://launchpadlibrarian.net/182951835/buildlog_ubuntu-utopic-i386.ubuntu-ui-toolkit_1.1.1206%2B14.10.20140822-0ubuntu1_FAILEDTOBUILD.txt.gz
[12:46] <doko> Riddell, ScottK: why aren't you working on the smokeqt ftbfs, but trying to work around it?
[12:46] <doko> pitti, so just mysql-5.5 is failing ...
[12:47] <doko> dobey, jamespag`: mysql-5.5 ping
[12:55] <tvoss> mlankhorst, mind jumping over to #ubuntu-ci-eng
[12:55] <tvoss> ?
[12:55] <tvoss> mlankhorst, seems like we have another llvm related issue
[12:56] <pitti> tvoss: "LLVM ERROR: Do not know how to split the result of this operator!
[12:56] <pitti> tvoss: by any chance?
[12:57] <Mirv> tvoss: pitti I just filed bug #1360241
[12:58] <Mirv> pitti: that exactly
[12:59] <pitti> ack
[12:59] <mlankhorst> pitti: again?
[12:59] <mlankhorst> where this time
[12:59] <seb128> bah, why was the llvm version change reverted?
[12:59] <mlankhorst> i moved back to llvm 3.5 because my original testcase worked
[13:01] <mlankhorst> should I revert again for now? :P
[13:01] <mlankhorst> doko: ^
[13:01] <seb128> yes
[13:01] <seb128> it's friday afternoon, not likely it's going to be resolved properly today
[13:01] <doko> I'm afk now
[13:02] <pitti> OOI, why don't we build with gcc like everything else?
[13:02] <doko> built what?
[13:02] <pitti> I seriously doubt that some .1% performance difference is noticeable in things like telephony-service or indicators?
[13:03] <doko> no, it's not using clang, it's the jit
[13:03] <pitti> doko: the bug that tvoss pointed to (UI toolkit etc.)
[13:04] <Mirv> pitti: I think it's mesa using LLVM failing on OpenGL tests, not that we use llvm to compile software?
[13:04] <pitti> or are these like 'test guinea pigs' for a future complete migration to llvm?
[13:04] <pitti> Mirv: ah, ok; thanks
[13:04] <mlankhorst> it's llvmpipe that's regressed, but on i386 only.
[13:04] <mlankhorst> it's the swrast
[13:04] <Mirv> and on x86 only, but since it's in unit tests UITK fails to build
[13:05] <mlankhorst> even more specific, isn't it i386 only?
[13:05] <mlankhorst> never seen an issue on amd64 related to it
[13:05] <pitti> I've seen it on arm and arm64, too
[13:05] <mlankhorst> odd, not me
[13:05] <doko> Mirv, mlankhorst so what about ignoring this test when it is i386 only?
[13:06] <mlankhorst> afaik it's in arch specific code
[13:06] <Mirv> bzoltan mentioned he wouldn't like to start selectively going through the tests and disabling them on x86, but sure that's one option
[13:06] <Mirv> (but bzoltan isn't on this channel)
[13:06]  * Mirv needs to afk
[13:07] <doko> anyway, I'm afk now
[13:07] <mlankhorst> fwiw updating mesa won't help, the problem is in llvm
[13:07] <doko> we need somebody ro report this ...
[13:07] <mlankhorst> do we have someone working on llvm?
[13:08] <doko> should be the desktop team, they are using llvmpipe
[13:08] <Riddell> doko: I'll be looking at it now
[13:08] <mlankhorst> fwiw I think I will push the revert for now, i still want 3.5 but they're annoying
[13:08] <mlankhorst> no need to stall everything while we find a more permanent solution
[13:09] <doko> sure
[13:12] <mlankhorst> ok uploaded
[13:18] <seb128> doko, desktop team is using llvmpipe? where?
[13:19] <seb128> don't thing we are
[13:19] <seb128> but we are not looking at llvm for sure
[13:19] <pitti> . o O { hot potato }
[13:20] <seb128> indeed ;-)
[13:20] <seb128> if it's a desktop issue I just vote for staying on 3.4 which works
[13:20] <seb128> if somebody wants 3.5 they can deal with the update and the issues it creates...
[13:29] <zbenjamin> ogra_: ping, didn't we have gdbserver on the image by default?
[13:31] <ogra_> zbenjamin, hmm i thought we seeded it once ... but i cant see it ...
[13:32] <zbenjamin> ogra_: yeah it seems to be gone
[13:32] <ogra_> (and we are getting very short on space ... we need to start gatekeeping what goes in soon)
[13:32] <ogra_> (else i would just re-add it )
[13:32] <ogra_> (and start dropping debug tools for the final product)
[13:32] <zbenjamin> ogra_: well for developer expirience it should go in, it would be a bit of a dealbreaker if a developer needs to void hos warranty
[13:33] <pitti> ubuntu touch images aren't going to be a developer platform anyway
[13:33] <zbenjamin> ogra_: we would force devs to make the image writeable
[13:33] <ogra_> we are at 493 of 500MB allowed for the rootfs
[13:33] <zbenjamin> pitti: why not?
[13:33] <ogra_> pitti, err
[13:33] <pitti> it's already way bigger than it should be, and still doesn't even have the basic dev tools
[13:34] <ogra_> pitti, it should have all debug tools you need for click package development
[13:34] <zbenjamin> pitti: i don't need gdb or gcc, we need gdbserver
[13:34] <ogra_> i.e. we have strace
[13:34] <pitti> well, for development you need quite a bit more than that :) for getting crash reports those are enough, yes
[13:35] <ogra_> gdbserver and valgrind were added ... i know valgrind was dropped again because it pulled in libc6-dbg
[13:35] <ogra_> not sure why gdbserver is gone now
[13:35] <zbenjamin> ogra_: valgrind is not supported by the SDK yet anyway
[13:35] <ogra_> zbenjamin, and never will be on the image ...
[13:35] <zbenjamin> pitti: compiling will happen on the host, as well as debug information can be on the host, what else would you need on the phone?
[13:35] <zbenjamin> ogra_: fine for me ;)
[13:36] <ogra_> way to big :)
[13:36] <pitti> zbenjamin: my thought exactly :)
[13:36] <pitti> zbenjamin: well, this will become more interesting in a converged world when devs will actually develop *on* the phone; but still a bit far out
[13:37] <pitti> (looking forward to that, though! :) )
[13:37] <ogra_> pitti, by that time the desktop and phone installs should already be identical ;)
[13:37] <ogra_> so we will have solved the issue already ;)
[13:37] <pitti> no more carrying laptops around to family or friends, just plug in phone into their laptop or TV
[13:38]  * ogra_ just wants a system-image install on his laptop ... 
[13:38] <ogra_> full release upgrade in 10 min and so on ;)
[13:38] <ogra_> and no more upgrade breakage possible
[13:38] <pitti> ogra_: I doubt you'd stay happy for very long with the current images, though :)
[13:38] <ogra_> pitti, well thats the plan
[13:39] <pitti> ogra_: (sure, sure -- just Friday trolling)
[13:39] <ogra_> true for the current qualiity though :)
[13:39] <pitti> ogra_: no vim, no mutt, no cookies!
[13:39] <ogra_> we ship vi-runtime
[13:39] <ogra_> ;)
[13:39] <ogra_> or vim-runtime
[13:39] <ogra_> and who needs mutt ... use dekko !
[13:39] <ogra_> the best since sliced bread ;)
[13:40] <pitti> ogra_: more seriously, do we actually have an email client? I looked for one the other week and didn't find one
[13:40] <pitti> (in the store)
[13:40] <ogra_> yeah, dekko
[13:40] <ogra_> a fork of trojita
[13:40]  * pitti installs
[13:40] <ogra_> the current version has issues with creating a new account though (afaik, i use an old config )
[13:41] <ogra_> you can find DanChapman (teh dev) in #ubuntu-app-install if you have questions/issues
[13:41] <ogra_> err
[13:41] <ogra_> #ubuntu-app-devel
[13:41] <ogra_> sorry
[13:42] <ogra_> pitti, soo ... i asked you before but my question always drowned in other discussions we had ... i have that whishlist bug for RZM to add a popup for low diskspace ...
[13:42] <ogra_> *RTM
[13:43] <ogra_> is there a backend i could easily use ? (i knwo i asked you in malta. but forgot what the solution was)
[13:43] <pitti> ogra_: oh the dekstop that's {gnome,ubuntu}-settings-daemon; we don't have that on touch, so I don't think so
[13:43] <pitti> ogra_: but it's not terribly difficult to call df, I figure
[13:44]  * pitti checks how g-s-d is doing that, whether there's some clever kernel notification or so
[13:45] <pitti> ogra_: wow, how big is that? has been downloading for like 4 mins now
[13:45] <pitti> it comes with all my mails pre-included :)
[13:47]  * pitti doesn't get that far, no "continue" button after entering password; anyway, something to try later on
[13:47] <ogra_> pitti, lol, yeah
[13:47] <ogra_> oh. you could create an account ?
[13:49] <pitti> ogra_: ah, asked Dan in #u-a-d; thanks for pointing out!
[14:49] <smoser> hi, server team has 4 packages in New queue for utopic that we'd like to see let in. (python-lxc, openstack-granite, and percona-xtradb-cluster-5.6 and  percona-xtradb-cluster-galera-3.x )
[14:49] <smoser> anyone able o help us out ?
[15:26] <pitti> mvo_, cjwatson: FYI, latest click upload mightily regresses its tests
[15:26] <pitti> (no email notification, as it's a train upload)
[15:43] <mvo_> pitti: oh? do you have a url? i check it out
[15:43] <pitti> mvo_: https://jenkins.qa.ubuntu.com/job/utopic-adt-click/29/ARCH=amd64,label=adt/
[15:48] <mvo_> thanks pitti
[16:26] <Riddell> doko: I conclude the smokeqt issue is to do with gcc 4.9 as one of the errors goes away when you force using gcc 4.8 (can't just set enviornment variables, I suspect smokegen isn't smart enough) but there's another error I can't work out
[16:26] <Riddell> doko: see e-mail
[17:54]  * Elbrus is wondering about the gnustep-gui transition
[17:54] <Elbrus> I thought it had to be done before the import freeze, but now I see that gnustep-gui is imported into proposed
[17:55] <Elbrus> reading http://people.canonical.com/~ubuntu-archive/transitions/html/gnustep-gui.html says no action is taken to rebuild anything after that
[17:56] <Elbrus> how can the rebuilds of all the dependecies be scheduled?
[17:57] <Elbrus> cjwatson: could you do this somewhat automated? (in Debian I would be requesting binNMU's but I was told that does not exist (yet) in Ubuntu
[18:06] <mvo_> pitti: I did a 0.4.31.2 now that should fix the failures (it did for me locally at least :)
[19:25] <Unit193> Linked to a couple dsc files on LP 992068 and LP 1358770
[21:13] <Noskcaj> To rebuild a package in trusty, do i just file an SRU as normal or is there a easier way?
[21:15] <jtaylor> its like a normal sru
[21:22] <Noskcaj> ok