[06:14] <pitti> Good morning
[06:43] <pitti> apw: mvo just ran into "lightdm not starting under systemd", and for him it was a simple reason; can you please again give me the contents of /etc/X11/default-display-manager?
[06:43] <pitti> apw: the current value ought to be /usr/sbin/lightdm, but it seems older systems had /usr/bin/lightdm there (sbin vs. bin)
[06:45] <mvo> pitti: seems to be working now
[06:46] <pitti> mvo: thanks
[07:02] <Saviq> mardy, hmm so apparently I'm still getting the password prompts for google accounts on login, any idea what could be causing those, and how could I get rid of them? anything I can do to debug?
[07:04] <mardy> Saviq: I suspect that they might not be coming from online accounts, but from GOA
[07:04] <dholbach> good morning
[07:04] <mardy> Saviq: try "dpkg -l *evolution*" and see if there is something about GOA
[07:05] <Saviq> mardy, not installed
[07:06] <Saviq> mardy, lemme log in again and try and find out more about those prompts
[07:19] <Saviq> mardy, hmm! it's gcr-prompter
[07:21] <Saviq> bug #1044549
[07:47] <rbasak> pitti: spamassassin needs a (trivial) merge, but what was the purpose of https://launchpadlibrarian.net/167650114/spamassassin_3.4.0-1_3.4.0-1ubuntu1.diff.gz ?
[07:47] <rbasak> pitti: FTBFS or something else?
[07:48] <rbasak> And is there a matching Debian bug?
[07:48] <pitti> rbasak: it failed its tests as it ran the tests with python but didn't test-depend on it
[07:48] <pitti> rbasak: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740171
[07:49] <pitti> yay for not applying simple patches in four months when uploading :/
[07:50] <rbasak> pitti: ah - in debian/tests/control. I mistook that for debian/control. Thanks!
[07:50] <rbasak> pitti: you want me to take the merge?
[07:50] <pitti> rbasak: please :)
[07:56] <geser> what's the current preferred fix for code linking with -lgfortran where gcc is 4.8 while libgfortran is 4.9 and gcc not finding -lgfortran? wait till gcc-4.9 is default again?
[08:05] <rbasak> pitti: uploaded.
[08:10] <Laney> @pilot out
[08:10] <Laney> @pilot in
[08:10] <Laney> good start
[08:10] <Laney> ..
[08:13] <LocutusOfBorg1> thanks infinity
[08:13] <LocutusOfBorg1> appreciated a lot
[08:15] <pitti> rbasak: thanks
[08:19] <apw> pitti, $ cat /etc/X11/default-display-manager
[08:19] <apw> /usr/sbin/lightdm
[08:22] <pitti> apw: ok, so that wasn't it; thanks
[08:22] <apw> will double check when i get my next kernel it is still there
[08:31] <apw> b 3
[08:40] <brendand> any core-dev around?
[08:43] <pitti> brendand: probably better to just ask your question
[08:43] <brendand> pitti, that's my question? i need to subscribe them to a merge proposal :)
[08:44] <pitti> brendand: I can do that
[08:45] <brendand> pitti, thanks - anyway it turns out i don't have permissions to do that at the moment, so i need to wait for someone to appear from the core apps team
[08:49] <dholbach> seb128, do you think anyone can respond to https://twitter.com/WyllieChilunSGS/status/482131496254599168?
[08:50] <Laney> dholbach: I will
[08:50] <dholbach> thanks Laney
[09:00] <pitti> mvo: did you see the "more PEP-8 fun" in https://jenkins.qa.ubuntu.com/job/utopic-adt-python-apt/27/ARCH=i386,label=adt/console ?
[09:01] <mvo> pitti: no I haven't, let me have a look now
[09:13] <jtaylor_> infinity, LocutusOfBorg1: sorry I did not check vtk properly
[09:13] <jtaylor_> infinity, LocutusOfBorg1 you reverted the tcl 8.6 change
[09:14] <jtaylor_> infinity, LocutusOfBorg1 that breaks a bunch of rdepends, please apply the trusty diff again
[09:14] <jtaylor_> brb 30 min
[09:35] <LocutusOfBorg1> mmm let me see
[10:02] <mapreri> what's up with MoM? it says "Generated at 2014-06-24 21:44:15 UTC."...
[10:04] <cjwatson> mapreri: I'm working on it
[10:04] <cjwatson> It tends to have trouble when people manage to upload packages that don't unpack
[10:04] <mapreri> ah, great
[10:29] <Laney> jamespage: you interested in looking at bug #1251563?
[10:30] <jamespage> Laney, can do - has the merge been done yet?
[10:32] <Laney> Doesn't look like it
[10:33] <jamespage> Laney, OK - on my list
[10:34] <Laney> jamespage: thanks!
[10:36] <jamespage> cjwatson, OK if I pickup the net-tools merge?
[10:38] <cjwatson> jamespage: Fine from my point of view, though I believe it's technically doko's
[10:38] <jamespage> cjwatson, oh - yes indeed it was :-) did not read far enough up...
[10:50] <doko> mvo, could you have a look at https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-python-apt/lastBuild ?
[10:53] <bluesabre> Greetings sponsors!  Please let me know if you are able to upload the following package to trusty-proposed so that we can begin SRU verification.  We'd like to deliver these fixes for 14.04.1
[10:53] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871
[10:53] <bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
[11:03] <caribou> Laney: just saw your update regarding bug #1296755
[11:04] <caribou> Laney: the backport needs to be done from the Saucy package as it has an older version (3.0.1) than Trusty (3.1°
[11:06] <Laney> caribou: saucy doesn't have the fix though
[11:06] <Laney> or do you want #12?
[11:07] <caribou> Laney: not yet as this is one of the tasks of this bug
[11:07] <caribou> Laney: but it's been lo long in the waiting queue that now saucy is going EOL
[11:08] <caribou> Laney: & Trusty has a more recent version & I'm not sure it can be backported as such
[11:08] <caribou> Laney: so yes, #12 would do it
[11:08] <Laney> well, it can if it'll work
[11:09] <caribou> Laney: I need to recheck as I vaguely remember some dependancy issues b/w trusty & precise
[11:10] <caribou> Laney: & I have another round of fixes for it lined up. Let me check first
[11:10] <caribou> Laney: maybe it would be simpler just to backport 3.1
[11:11] <Laney> caribou: I think so, if you're up for taking a look at the trusty package on precise and seeing what (if anything) needs changing to make that happen
[11:11] <caribou> Laney: sure, doing it right now.
[11:12] <Laney> let me know - we could still sneak in an SRU for 13.10 if this is too hard
[11:15] <jtaylor_> doko:  you uploaded blt with tcl/tk 8.6 even though you know it breaks stuff? oO
[11:15] <jtaylor_> in debian
[11:16] <jtaylor_> we haven't even got a fix yet in utopic
[11:21] <caribou> Laney: yep, got a failed dependancy on dh-python which is not in Precise
[11:24] <caribou> Laney: hmm, this dh-python dep is going to be an issue going forward as after saucy we will no longer have a release to pull the source from other than trusty
[11:27] <mvo> doko: yeah, done and fixed in git
[11:27] <mvo> doko: its pep8 going wild
[11:29] <doko> mvo, thanks!
[11:30] <doko> jtaylor, no, I don't know
[11:30] <mvo> doko: yw, I upload in a some minutes
[11:30] <Laney> caribou: yeah, how long are you going to want to backport for?
[11:30] <caribou> Laney: 12.04 lifetime :-/
[11:31] <caribou> Laney: is there a "best practice" way to install python3 bits on Precise
[11:31] <Laney> you could un-dh-python2 it, or look at backporting that to precise
[11:31] <caribou> Laney: sosreport 3.1 is python3, hence it uses a --with python3 rule
[11:32] <caribou> Laney: from what I can see, there is no dh_python3 on Precise. If there is an alternate way of installing python3 software on Precise I can adapt the rules file for it
[11:33] <geser> doko: what's the current fix for code linking with -lgfortran where gcc is 4.8 while libgfortran is 4.9 and gcc not finding -lgfortran? wait for gcc-4.9 becoming the default again? (I was looking at some r-cran-* FTBFS over the weekend)
[11:34] <doko> geser, waiting until tomorrow
[11:35] <Laney> caribou: ah sorry I read dh-python2 there... I'm not totally sure about py3 on precise myself
[11:36] <caribou> Laney: maybe the simplest approach for this specific bug is to fix saucy, then use it as a source for the backport
[11:36] <Laney> if a backport would produce functional packages then we could look at that (Debian did this)
[11:37] <caribou> Laney: a backport from a newer saucy would
[11:37] <Laney> I mean of dh-python
[11:37] <caribou> Laney: ah, I thought you meant sosreport
[11:37] <Laney> saucy backport would be easy enough, but then we get this problem next time I guess
[11:38] <caribou> Laney: gives me more time to figure out how to get sosreport 3.1 into precise, hence the backport would be from Trusty
[11:38] <Laney> might give someone room to look at taking on the dh-python task
[11:40] <Laney> so if you want, gather up all the fixes you want and propose a new saucy debdiff then I'll sponsor that for youe
[11:42] <doko> tvoss, what's the status of the phone/4.9 transition?
[11:46] <caribou> Laney: I will update the bug : let's get the current debdiff in saucy as it is now. I don't want it to wait any longer
[11:46] <Laney> alright
[11:53] <caribou> Laney: another -backports question : since you don't use debdiffs for backports, it means that the source package needed for the backport is directly pulled from the archive
[11:53] <Laney> caribou: we download the source from the new release and then upload it to backports with a new changelog entry on top
[11:54] <caribou> Laney: I mean, I have no other way than *not* using dh-python in Trusty as well
[11:54] <Laney> caribou: We can do source change backports if it's necessary to make the package build or work
[11:55] <Laney> in that case you attach a debdiff which is applied on top of the package to be backported
[11:55] <Laney> https://wiki.ubuntu.com/UbuntuBackports#Building_a_Backport
[11:55] <caribou> Laney: that is what I had in mind : keep the trusty pkg intact & add a minor modif to have it work in the backports archive
[11:56] <caribou> Laney: thanks, I'll use that as a reference
[12:16] <Mantas-Baltix> Hi all :)
[12:20] <Mantas-Baltix> Could someone tell me why memtest86+ source code isn't imported from Debian into launchpad bzr (https://code.launchpad.net/debian/+source/memtest86+)? At http://package-import.ubuntu.com/status/ memtest86+ package is on section  "currently running" for at least 4 hours :(
[12:32] <rbasak> Mantas-Baltix: a UDD import failure is not uncommon. Try the UDD list - address at the top of that status page.
[12:35] <Mantas-Baltix> rbasak: Is there a failure when memtest86+ is under "currently running" for few hours ?
[12:38] <michagogo> cjwatson: are you around? Mind a PM?
[12:39] <cjwatson> michagogo: I don't mind, but if it's about bitcoin I think I've already helped as much as I'm able and I'm not going to have time to help more
[12:40] <Laney> @pilot out
[12:41] <michagogo> cjwatson: well, the thing is that it seems like what I was told was wrong. I was under the impression that the next step was for someone to sponsor it and upload to -proposed, and then you guys (SRU team) would review and discuss it
[12:41] <Laney> caribou: uploaded
[12:41] <caribou> Laney: thank you very much
[12:41] <Laney> sure
[12:41] <Laney> when it hits -updates we can do the backport
[12:42] <michagogo> But then stgraber seemed to disagree: 19:15:48 <stgraber> no, it's not. If someone was to upload that today, I'd reject it when it hits the queue because it doesn't meet our current SRU criteria 19:16:00 <stgraber> so if you don't want that to happen, this needs to be discussed prior to upload
[12:42] <cjwatson> michagogo: Bring it up on the ubuntu-devel list, with context?
[12:42] <michagogo> cjwatson: so I wanted to know, how does one start a discussion with the SRU team, since you don't appear to have an IRC channel nor a mailing lost
[12:43] <cjwatson> We're all on ubuntu-devel
[12:43] <michagogo> cjwatson: ah, that's the place for it?
[12:43] <michagogo> Okay, thanks.
[12:54] <Mantas-Baltix> could someone upload nautilus 1:3.10.1-0ubuntu9.2 from trusty-proposed to trusty-updates (see bug  #1184720 )
[12:55] <Mantas-Baltix> VERIFICATION DONE one week ago, I also can confirm, that nautilus 1:3.10.1-0ubuntu9.2 from trusty-proposed works fine with symlinks
[13:01] <rbasak> Mantas-Baltix: usually packages have to wait for at least a week to give all testers an opportunity to find regressions. Looks like that one's only 6 days old, so it won't be on the SRU team's radar yet.
[13:03] <infinity> jtaylor_: I didn't revert anything, the sid upload that I synced had literally no diff against the utopic version except changelog.
[13:04] <jtaylor_> infinity: then my diff was lost already by an earlier sync/merge :/
[13:05] <infinity> jtaylor_: -15.1 was synced by Dmitry Shachnev
[13:06] <infinity> jtaylor_: And it appears to have tk8.6 bits...
[13:06] <infinity> Err, no.
[13:06] <infinity> I can't read.
[13:07] <jtaylor_> I think the underlinking patch was applied in debian
[13:07] <jtaylor_> but debian uses 8.5 not 8.6
[13:07] <infinity> jtaylor_: Yeah.  I'll fix this up.
[13:07] <jtaylor_> this needs to be keept in ubuntu + the patch probably needs adapting
[13:08] <jtaylor_> thx, I can maybe also have a look later today
[13:09] <jtaylor_> vtk build unfortunately takes very long on my machine
[13:22] <infinity> jtaylor_: Testbuilding this now: http://paste.ubuntu.com/7726421/
[13:28] <jtaylor_> infinity: looks good thank you
[13:28] <infinity> jtaylor_: NP, I had to do something with this whole "accidentally waking up way too early on a day off" situation.
[13:29] <jtaylor_> :)
[13:29] <jtaylor_> fwiw the patch should be forwarded to debian as it now too has a 8.5/8.6 mix which should be avoided. I'll do that this evening
[13:32] <infinity> jtaylor_: Ta.  I suppose the other option would be moving forward with getting the experimental version in sid (though it also needs the 8.5->8.6 transition, it looks like, but doesn't need the patch).
[13:34] <jtaylor_> right might be the better path
[13:35] <jtaylor_> then there is also vtk6 where the tcl bindings don't seem to work at all due to multiarch :/
[14:29] <doko> jamespage, could you have a look at debian-java ML, Merging maven-repo-helper and maven-debian-helper ?
[14:46] <jamespage> doko, I can but not today
[14:46] <jamespage> doko, but will do this week
[14:56] <mapreri> pitti: thanks in advance :) (wrt the outgoing email to you)
[15:32] <doko> jamespage, thanks, I assume that proposed merge would force maven into main
[15:39] <jamespage> doko, it would
[16:42] <Mantas-Baltix> It seems there are some problems with package's sources imports from Debian - at http://package-import.ubuntu.com/status/ same packages  (memtest86+, openscap, liferea, etc.) are on section  "currently running" for at least 7 hours :(
[16:43] <Mantas-Baltix> I wrote an email to https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2014-June/001215.html  , but got no answer :(
[16:44] <cjwatson> xnox,wgrant: ^-
[16:48] <Mantas-Baltix> And count of  "outstanding jobs" at http://package-import.ubuntu.com/status/  increases every 10 minutes...
[16:49] <xnox> cjwatson: wgrant: something is wrong, despite not publishing any failure logs, there are for e.g. memtest86+ tracebacks from wadllib/application.py failing to parse xml
[16:49] <xnox> hm.
[16:50] <xnox> 166.414  safe_decode() called on an already-unicode string: u'Yann Dirson <dirson@debian.org>'
[16:50] <vak> hi all
[16:50] <vak> During initramfs phase $(ls /dev/sd* ) shows nothing... how come?.. what modules might have became missing?? could it be that udev rules are broken after HDDs were attached to the new SATA port positions??
[16:52] <vak> everything was OK before i changed the SATA-ports (and i don't remember at which ports the HDDs were attached...)
[16:53] <infinity> vak: Seems more likely that the ports you switched to are either nonfunctional or need another driver.
[16:53] <ogra_> or probably a BIOS setting that you missed
[16:53] <infinity> Or the drives aren't plugged in right, or, or...
[16:54] <infinity> vak: Anyhow, that's more of a support question for #ubuntu, not a development question.
[16:54] <xnox> Mantas-Baltix: it is running at the moment, monitoring the log, it probably is blowning up on the sid upload.
[16:56] <xnox> vak: you can increase udev logging as a boot arg and/or config file options / command, to see which events udev is saying about hard-drives, et.al.
[16:57] <xnox> Mantas-Baltix: http://paste.ubuntu.com/7727282/ and since debian import fails, it's out of date.
[17:11] <vak> infinity: ogra_: everything is OK if i ran LiveCD.
[17:12] <vak> xnox: changed to debug 2 hours ago, nothing interesting so far
[17:12] <Mantas-Baltix> xnox: could you fix the import, at least memtest86+ 5.01-1 , please ;)
[17:13] <vak> infinity: and the questions seems to be too deep for supporters on #ubuntu
[17:14] <vak> s/questions/question
[17:15] <vak> infinity: at least, asked there before coming here.
[17:16] <xnox> Mantas-Baltix: the import errors out, why do you need an import, and how can I help you to unblock you without an import?
[17:16] <xnox> Mantas-Baltix: possibly permanent, and/or requiring fixes in the import stack.
[17:17] <Mantas-Baltix> xnox: I wanna create memtest86+ 5.0.1 packaging  recipe for my PPA - I need to have latest memtest release for Ubuntu Baltix derivative, see http://launchpad.net/baltix
[17:18] <xnox> Mantas-Baltix: pull-lp-source, dput into ppa. Or even use a script from ubuntu-archive-tools to copy the version you want, into ppa/series you want.
[17:18] <xnox> Mantas-Baltix: normal dput uploads are accepted into ppa. And since the branch import is out of date, you are out of luck.
[17:18] <xnox> Mantas-Baltix: are you planning to modify memtest? or do you just want latest one in your ppa?
[17:19] <xnox> E.g. $ ./copy-package -d ubuntu -s utopic --to-ppa xnox --to-ppa-name scratch --to-suite trusty memtest86+
[17:19] <xnox> from lp:ubuntu-archive-tools.
[17:20] <xnox> there is also backport-package script in ubuntu-dev-tools that can automate backporting package, lower the version & upload into ppa to have the right version number (e.g. higher than stable, but lower than next release)
[17:21] <Mantas-Baltix> xnox: no, I just wanna to backport original memtest86+ 5.0.1-1 package from Debian to Ubuntu Trusty and Precise - I already created packaging recipe for memtest86 4.3.6, see https://code.launchpad.net/~baltix/+recipe/memtest86-debian
[17:26] <Mantas-Baltix> xnox: I currently can't use dput, because today I don't have access to my private GPG key :(
[17:28] <Mantas-Baltix> xnox: maybe you can upload unmodified memtest86+ 5.0.1-1 package to some PPA (or sources to some launchpad.net branch) and then I could copy package to baltix PPA or create packaging recipe :)
[17:47] <xnox> Mantas-Baltix: pull-lp-source memtest86+; cd memtest86+-*; bzr init .; bzr commit -m "initial"; bzr push lp:~baltix/+junk/memtest86+ and create a packaging recipe as you wish.
[17:47] <xnox> Mantas-Baltix: i'm guessing you do realise that not having access to your private gpg key is important =)
[17:52] <Mantas-Baltix> xnox: I don't have access to private key only today ;)
[18:00] <mapreri> Mantas-Baltix: and the upload can't wait a single day?
[18:03] <Mantas-Baltix> mapreri: I'm building new Baltix GNU/Linux distribution release today ;)
[18:48] <xnox> Mantas-Baltix: i gave you steps to make a branch, which can be "recipified" into a ppa build.
[18:49] <hallyn> doko: hi, in netcf in trusty you pushed the change to "Build using dh-autoreconf." - i didn't notice that while pushing new versino to debian so it's not there.  Is that needed?  Should I change it in debian before syncing then?
[18:50] <cjwatson> hallyn: Generally that class of fix is there to make it actually build on some subset of arm64/ppc64el
[18:51] <cjwatson> hallyn: Even if it isn't needed right now (because the generated files in the orig.tar are new enough), it's good practice to add it anyway to help the next port
[18:51] <hallyn> cjwatson: ah, ok, so then definately should be there.  ok, thx.  it's just the new dh-autoreconf dep and call in debian/rules right?
[18:51] <hallyn> cjwatson: do you mind if i ask you to sponsor to experimental ? :)
[18:52] <cjwatson> I guess ppc64el from the timing
[18:53] <cjwatson> hallyn: Can do, but have evening things to do at the moment.  Mail?
[18:53] <hallyn> cjwatson: great, thanks
[18:54] <cjwatson> And yes, usually it's just build-dep + --with autoreconf, or dh_autoreconf / dh_autoreconf_clean in backward packages :)
[18:54] <cjwatson> (or there's a cdbs version involving including something)
[18:54] <juliank> Yep.
[18:55] <juliank> Its creator agrees.
[18:55] <hallyn> this one just did include /usr/share/cdbs/1/rules/autoreconf.mk;  not sur eif that makes it backward
[18:55] <juliank> that's fine
[18:55] <juliank> it's a CDBS package.
[18:55] <juliank> also I'd count CDBS as backwards
[18:55] <juliank> s/also/although/
[18:59] <hallyn> yeah i think that was his point too :)  I'm a but unsure why I went with cdbs as that package isn't all that old
[19:00] <Mantas-Baltix> xnox: thanks
[19:39] <cjwatson> juliank: heh, me too ;)
[21:05] <tvoss> xnox, so which libelf version am I meant to use? libelf1 or libelfg0?
[21:17] <infinity> tvoss: libelf1 is the "new" hotness from elfutils, it's probably the one you want.
[21:17] <infinity> tvoss: Very few things use libelf0g anymore.
[21:18]  * infinity wonders why glib-bin does...
[21:40] <tvoss> infinity, thanks
[22:06] <dobey> infinity, slangasek: either of you want to fix bug #1323334 and eradicate ubuntu-purchase-service from the archive?
[22:09] <slangasek> let's have a look
[22:09] <infinity> Done.
[22:11] <slangasek> infinity: stop working
[22:11] <infinity> slangasek: Removing packages is pleasure, not work.
[22:11] <slangasek> also, stop sniping things I've said I was looking at
[22:11] <infinity> slangasek: I did it before you responded. :P
[22:12] <slangasek> infinity: then let me know you're looking at it maybe ;)
[22:12] <infinity> 16:06 < infinity> Looking.
[22:12] <slangasek> oh?
[22:12] <infinity> (I just made that up)
[22:12] <slangasek> :)
[22:15] <dobey> heh
[22:15] <dobey> infinity, slangasek: thanks :)
[22:21] <vak> why could it happen that udev didn't create /dev/sd[abc] entries?
[22:29] <wgrant> xnox: Were you able to make any progress on the package-import issue?
[22:41] <wgrant> xnox: package-import fixed. The real error was the traceback after the safe_unicode line you quoted; the WADL cache was corrupt.
[23:17] <sarnold> Trevinho: another 14.04 screenlock bug, not much in the way of details though: 1335835
[23:17]  * Trevinho checks
[23:18] <Trevinho> sarnold: I can't access to that bug... is it maybe private=
[23:18] <Trevinho> ?
[23:18] <sarnold> Trevinho: argh, sorry, I guess there's still a problem in my scripts :) thanks!
[23:18] <sarnold> Trevinho: should be open now :)
[23:19] <Trevinho> sarnold: it is, thanks