=== Trevinho_ is now known as Trevinho
=== freeflying_away is now known as freeflying
=== Guest72010 is now known as balloons
=== mwhudson is now known as zz_mwhudson
[04:26] <Logan_> cjwatson: Is there any way I could help out with the backlog in ~ubuntu-archive?
=== TheMuso` is now known as TheMuso
[07:16] <pitti> Good morning
[07:17] <pitti> stgraber: thanks for the heads-up
[07:58] <dholbach> good morning
[08:03] <dpm> hi jamesh, around for a quick chat on mediascanner 2.0?
[08:04] <dpm> morning dholbach!
[08:04] <jamesh> dpm: sure.
[08:04] <dpm> cool, thanks :)
[08:05] <dholbach> hey dpm
[08:05] <jamesh> dpm: is there anything in particular you want to know about it?
[08:05] <dpm> jamesh, on your e-mail you said the QML bindings are blocking on feedback. Are you waiting for someone's feedback in particular? Can we provide that feedback from the Music app side of things to unblock them?
[08:06] <jamesh> dpm: I was waiting on Victor, but if anyone else on the project has ideas of what's needed, that would be great.
[08:06] <dpm> jamesh, ok, cool, I'll ping him with a reminder. Do you have a bug to track this feedback, or would just e-mail work?
[08:07] <jamesh> dpm: we were just using email, but I can set up a bug report if that'd be easier
[08:08] <jamesh> we're at https://launchpad.net/mediascanner2 now, due to some issues with handling packaging of multiple lines of development from a single LP project
[08:09] <dpm> jamesh, yeah, if you don't mind, a bug would be useful, so that we can have a single place to track it. I'll then ask Victor to comment on it.
[08:10] <jamesh> looks like I don't have permission to turn on bug reporting for the mediascanner2 project.  Hopefully sil2100 can help with that when he's online later
[08:10] <dpm> ack. Are you setting the project for bugs and filing the bug report, or do you want me to file it?
[08:10] <dpm> ah, ok
[08:12] <dpm> let me see if I can find someone who's online with the right permissions
[08:24] <Unit193> mvo: Here?
=== zz_mwhudson is now known as mwhudson
[08:48] <infinity> Logan__: Not yet, I'll try to get to it todat.
[08:48] <infinity> Logan__: Or today.
=== schmidtm_ is now known as schmidtm
[09:14] <dpm> jamesh, lp:mediascanner2 is now set up for bug reporting. Would you mind reporting the bug about QML bindings feedback and then we'll take it from there?
[09:26] <Laney> life would be better if offlineimap didn't hang at least once every two days
[09:27] <pitti> Laney: wow, I've been using it for years, I never had that (or any problem really)
[09:27] <Laney> how do you run it?
[09:27] <pitti> $ offlineimap
[09:27] <pitti> nothing fancy
[09:27] <pitti> with .offlineimaprc http://paste.ubuntu.com/6831043/
[09:29] <Laney> oh, something else does the SSHing for you
[09:31] <pitti> Laney: yes, preauthtunnel; best thing ever
[09:31] <pitti> no password for imap
[09:31] <Laney> I don't know about that!
[09:31] <pitti> passwords are so "eek"
[09:32] <Laney> I could certainly use that for my personal acct, wonder about the work one
[09:32]  * Laney notes it down
[09:32] <pitti> Laney: I'm still one of these old farts who reject to use gmail and have @ubuntu.com etc. forwarded to my own server
[09:33] <Laney> yeah I host my own too
=== mwhudson is now known as zz_mwhudson
=== timrc is now known as timrc-afk
[10:12] <jamesh> dpm: bug filed here: https://bugs.launchpad.net/mediascanner2/+bug/1273625
[10:12] <ubottu> Error: Could not gather data from Ubuntu for bug #1273625 (https://launchpad.net/bugs/1273625). The error has been logged
[10:26] <doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
[10:27] <doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
[10:27] <doko> http://qa.ubuntuwire.com/ftbfs/
[10:27] <doko> http://qa.ubuntuwire.org/ftbfs/ppc64el.html
[10:27] <doko> http://qa.ubuntuwire.org/ftbfs/arm64.html
[10:30] <doko> http://people.canonical.com/~ubuntu-archive/
[10:30] <slangasek> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[10:30] <slangasek> yay, url time on IRC ;)
[10:30] <dpm> jamesh, thanks!
[10:30] <seb128> slangasek, I was about to say :p
[10:31] <slangasek> seb128: sorry, we're in a room with the CTS team at the moment and teaching them all +1 maintenance :-)
[10:31] <seb128> slangasek, I see ;-)
[10:32] <Unit193> seb128: Sorry if I come off sounding short.
[10:33] <doko> slangasek, desktop doesn't know the concept of +1 maintenance anymore ;p
[10:34] <seb128> doko, no, looking a build issues, transitions, etc is just something included in our daily workflow ;-)
[10:35] <cjwatson> tseliot: fglrx-xpress/precise-proposed - looks like amd-xconfig should be in a clean target somewhere, since there are mostly-duplicate files amd-xconfig and amd-xconfig.in
[10:36] <tseliot> cjwatson: true but I like to regenerate it for testing using the test_amd_xconfig script
[10:40] <cjwatson> tseliot: right, but it shouldn't be in the source package
[10:40] <cjwatson> (I accepted it anyway)
[10:42] <seb128> Unit193, no worry, it's weird that apt-get upgrade wants to install old Recommends for you that you didn't want to install/removed in the past, are you sure it's not a new recommends/a one time thing?
[10:42] <seb128> Unit193, and it seems pavucontrol should just be listed an alternative recommends there if it's one of the options in the code
[10:44] <Unit193> seb128: I'd presume you won't add pavucontrol first in the list, which I get.  That option sounds fine to me, it'll end up doing the same thing since I already have that.
[10:44] <seb128> Unit193, right, the most common usecase is listed first, but as you said, it shouldn't be an issue if you have one of the options
[10:46] <ogra_> package libc6-amd64 is not ready for configuration  cannot configure (current status `half-installed')
[10:46] <ogra_> GRMBL
[10:46] <ogra_> infinity, !
[10:46] <Unit193> In that case I'll remove my proposal as it isn't as good as adding pavucontrol.
[10:48] <seb128> Unit193, your call, or update it to add pavucontrol as an alternative if you can
[10:50] <Unit193> seb128: Just thought of that, since it'll update.  Might want to review since it's quite late and brain no work well now.
[10:50] <tseliot> cjwatson: thanks
[10:50] <seb128> Unit193, ok
[10:51] <Unit193> Thanks for taking a look.
[10:53] <bluesabre> Unit193: at this point, the term is "early"
[10:53] <bluesabre> :D
[10:53] <Unit193> bluesabre: Shhh, you stinker.
=== bluesabre is now known as bluestinker
=== bluestinker is now known as bluesabre
=== _salem is now known as salem_
[11:34] <knome> hey seb128, do you have by any chance time to look at bug 1207493 again? we should have a correct debdiff and all there now
[11:34] <ubottu> bug 1207493 in xubuntu-docs (Ubuntu Precise) "[SRU] Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,Fix committed] https://launchpad.net/bugs/1207493
[11:41] <mitya57> barry: by django changes, you mean https://github.com/django/django/commit/e1d18b9d2e8ac2 ?
[11:44] <mitya57> I am asking because there is also https://bitbucket.org/birkenfeld/sphinx/commits/ce0b17bcd7c9, let me know if you need that as well.
=== MacSlow is now known as MacSlow|lunch
[12:01] <seb128> knome, sure, adding that to my todo for this afternoon
[12:09] <slangasek> hallyn: bug #1273654
[12:09] <ubottu> bug 1273654 in qemu (Ubuntu) "qemu-arm64-static binfmt registration for non-existent binary" [Undecided,New] https://launchpad.net/bugs/1273654
[12:10] <hallyn> slangasek: thanks
[12:11] <barry> mitya57: right.  i looked at both the django and sphinx ones.  the sphinx one is just a workaround for the django bug, which is the real problem.  the sphinx patch isn't enough (i added another fix which does make it work, but i'd rather fix django properly instead)
[12:18] <xnox> seb128: please review & approve https://code.launchpad.net/~ted/upstart-app-launch/application-task/+merge/202768
[12:19] <xnox> seb128: it's a fix proposed by slangasek
[12:19] <seb128> xnox, why me? ;-)
[12:19] <xnox> seb128: you happen to have the right permissions on lp.
[12:19] <seb128> xnox, you don't have access to the status?
[12:19] <seb128> k
[12:19] <xnox> seb128: i'm not PS enough.
[12:20] <Laney> fauxww
[12:20] <seb128> xnox, that's ok young padawan, did it for you
[12:20] <slangasek> hallyn: XS-Debian-Vcs-Git
[12:21] <xnox> seb128: i want to join ~indicator-applet-developers
[12:21] <slangasek> seb128: ubuntu-core-dev wants to join ~indicator-applet-developers ;)
[12:22] <Laney> that's a nice idea
[12:22] <seb128> slangasek, you would have to ask an admin of that team I guess
[12:22] <Laney> talk to an admin :P
[12:22] <seb128> seems like you want ted
[12:30] <mitya57> barry: OK, so I assume nothing is needed from me
[12:30] <barry> mitya57: not unless you know where the dmpt branch actually lives :)
[12:31] <mitya57> I think someone just forgot to update the SVN
[12:31] <barry> i suspect the package has been uploaded without updating the branch
[12:31] <barry> mitya57: exactly... :(
[12:31] <mitya57> Do it yourself then :)
[12:31]  * barry grumbles
[12:32] <barry> mitya57: yeah, i'll probably do that when i've verified the patch actually fixes the problem
[12:33] <mdeslaur> wgrant: congrats!
[12:51] <hallyn> slangasek: actually, is a version check actually needed?  The only way a user would have a qemu-aarch64 binfmt file is from the 1.6 version(s) which had qemu-user-aarch64;  so postinst could just unconditionally remove it?
=== tkamppeter__ is now known as tkamppeter
=== MacSlow|lunch is now known as MacSlow
[13:40] <slangasek> hallyn: debatable in this case, but in general you don't want maintainer scripts to re-apply changes more than once on upgrade that may clobber local changes the admin has made
[13:44] <slangasek> hallyn: patch sent to the bug, anyway :)
[13:44] <hallyn> thanks
=== timrc-afk is now known as timrc
[14:38] <doko> seb128, could you do another merge of poppler from experimental?
[14:39] <doko> or maybe package 0.25.1 if it's not a development series
[14:39] <seb128> doko, it's a dev serie (and they often change sonames there)
[14:40] <seb128> doko, what change do you need from experimental? we just merged on them
[14:41] <doko> seb128, there are several ftbfs currently (cvs, gdb-doc, etc, ) which go away when I switch poppler and texlive-bin to the debian versions
[14:41] <didrocks> xnox: https://code.launchpad.net/~autopilot/autopilot/1.4
[14:41] <didrocks> slangasek: FYI (done) ^
[14:41] <seb128> doko, we have the same version than debian experimental (upstream version) and our packaging diff is small, do you have specifics on those ftbfses?
[14:41] <slangasek> didrocks: ta
[14:41] <didrocks> yw
[14:42] <seb128> doko, note that the new poppler got uploaded this week and is trusty-proposed atm (libreoffice needs to migrate with it and some other things like calligra didn't got rebuilt yet)
[14:42] <doko> seb128, we have 0.24.3 , experimental 0.24.5
[14:42] <seb128> doko, https://launchpad.net/ubuntu/+source/poppler/0.24.5-0ubuntu1 ?
[14:43] <doko> ahh
[14:43] <seb128> doko, there was a soname change in 0.24.5 and transition is ongoing ( Sweetsha1k needs to fix libreoffice)
=== freeflying is now known as freeflying_away
[15:20] <doko> seb128, so it looks like all the ftbfs like cvs, gdb-doc are caused by the new poppler
[15:21] <seb128> doko, do you have a build log showing the error?
[15:21] <doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
[15:22] <doko> seb128, only show on i386, goes away when building poppler with -O0
[15:22] <seb128> "fun"
[15:22] <seb128> toolchain issue?
[15:27] <pitti> stgraber: hey, how are you?
[15:27] <doko> seb128, are there any poppler tests?
[15:27] <pitti> stgraber: do you have any idea how to achieve the "lxc-wait for a time when it's safe to interact with the container" without using runlevels or extra init scripts in the template?
[15:28] <seb128> doko, the srcdir has some but not a lot
[15:28] <pitti> stgraber: i. e. is it possible to poll from the outside, like repeatedly trying to run a command like "runlevel" from e. g. adt-virt-lxc?
[15:28] <seb128> doko, you want a smaller testcase/reproducer? maybe tsdgeos can help you, he's upstream for poppler
[15:28] <pitti> stgraber: that would be much easier than the ridiculous "sudo readlink /var/lib/lxc/.." hacks that adt-virt-lxc does ATM
[15:30] <pitti> stgraber: AFAIUI, lxc-execute starts a new container; is there a counterpart for "run command in a running container"?
[15:31] <doko> seb128, sure, that would be nice. so problem seems to occur when the @ sign is encoded itself in an texinfo file
=== oSoMoN_ is now known as oSoMoN
[15:33] <wgrant> pitti: lxc-attach?
[15:34] <pitti> wgrant: oh, thanks!
[15:34] <wgrant> I think it's relatively new
[15:34] <wgrant> But very handy
[15:34] <slangasek> yep, it's newish
[15:35] <pitti> rbasak: so instead of this mad /var/lib/lxc/ poking, why don't we just run lxc-attach until the runlevel switches to 2?
[15:35] <slangasek> I think it requires newish kernel support, in particular
[15:35] <pitti> ah, so not something you could use in saucy or precise?
[15:35] <slangasek> it's in saucy, I don't know if it works on precise
[15:35] <slangasek> hallyn: ^^?
[15:35] <pitti> ah
[15:35] <pitti> well, good enough
[15:35] <pitti> the lxc runner is fairly new anyway
[15:38] <pitti> rbasak: FYI, I filed bug 1273725 to remind me
[15:38] <ubottu> bug 1273725 in autopkgtest (Ubuntu) "simplify adt-virt-lxc startup checks" [Undecided,New] https://launchpad.net/bugs/1273725
[15:47] <hallyn> slangasek: does not work with the precise kernel.  works fine with the saucy backported kernel on precise
[15:47] <hallyn> pitti: ^
[15:47] <pitti> hallyn: thanks
[15:48] <mitya57> doko: I see webkit in your rebuild logs, I think it can be deleted as it has been renamed to webkitgtk.
[15:48] <doko> mitya57, maybe file a bug report and subscribe ubuntu-archive?
[15:49] <Laney> it's done
[15:49] <Laney> I asked about it last week or so
[15:49] <mitya57> bug 1261721
[15:49] <ubottu> bug 1261721 in webkit (Ubuntu) "RM: webkit -- ROM; renamed to webkitgtk" [Undecided,Confirmed] https://launchpad.net/bugs/1261721
[15:51] <Laney> they declined to process it, just ignore
[15:53] <doko> mitya57, https://launchpadlibrarian.net/163863694/buildlog_ubuntu-trusty-i386.python-django_1.6.1-1_FAILEDTOBUILD.txt.gz
[15:53] <doko> with the current sphinx
[15:54] <mitya57> doko: barry if fixing that
[15:54] <doko> ahh, good to know
[15:54] <barry> mitya57, doko will be uploading that fix to debian
[15:55] <mitya57> doko?
[15:55] <mitya57> I think he is not going to do that if he asked me...
[15:56] <doko> didrocks, https://launchpadlibrarian.net/163915490/buildlog_ubuntu-trusty-i386.oneconf_0.3.5_FAILEDTOBUILD.txt.gz  b-d's should be on -all-dev
[15:57] <doko> kenvandine, https://launchpad.net/ubuntu/+archive/test-rebuild-20140127/+build/5524030
[16:00] <kenvandine> doko, interesting failure... i'll fix it
[16:01] <seb128> doko, I think you should ping barry for oneconf, he's buggy since the python3 port and didrocks said he has no free slot to look at it (barry did the port by then)
=== Sweetsha1k is now known as Sweetshark
[16:05] <infinity> YokoZar: Ugh, I didn't notice the epoch on the wine packages before I accepted them.  Haven't accepted the binaries yet, though.  Do we really need to introduce that just to smooth over a PPA version?
[16:07] <doko> seb128, kenvandine: you may want to look at other failures in http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html  not yet announced, main stillre building
[16:08] <Laney> what's special about this test build?
[16:08] <seb128> infinity, did you ever get at the bottom of that ubuntu-wallpapers/dh_install/find/\' in filenames issue?
[16:09] <doko> Laney, python3.4 is the default, nothing else is special
[16:09] <infinity> seb128: I got distracted by some other things, but I've not completely forgotten about it.
[16:09] <seb128> infinity, ok, so I consider that you still "own" it ;-)
[16:10] <Laney> pwn
[16:10] <infinity> seb128: Yeah, I'm fine with that for now.  Unless you have some bright ideas.
[16:10] <seb128> infinity, it's easy enough to workaround by escaping the ' in the .install
[16:11] <seb128> but then people are going to forget about the issue and it's not going to be fixed
[16:11] <seb128> otherwise no, no clever idea about what changed that creates the issue
=== greyback is now known as greyback|food
[16:32] <barry> seb128: i keep trying to find cycles to look at oneconf but they always seem to get eaten up before i can do it.  at least i still have a tab open on the bug ;/
[16:33] <seb128> barry, ok
=== greyback|food is now known as greyback
[16:59] <doko> seb128, I'm tempted to blame poppler ... I can reproduce this with the 4.7 toolchain, both linaro and fsf, and fsf 4.8. on both armhf and i386. need to find a machine to check on powerpc too. but this looks like a 32bit issue in poppler
[17:00] <seb128> doko, ok, and it just started with .5? e.g if you rebuild .3 on current trusty it works fine?
[17:00] <doko> no, maybe earlier
[17:02] <jhenke> hi, is there anybody I can ping to take a closer look at bug #1272664 ? the bug is either in the grub installer or efibootmgr and breaks usage of ubuntu on hyper-v gen2
[17:02] <ubottu> bug 1272664 in efibootmgr (Ubuntu) "Installing UEFI boot entry on Hyper-V gen 2 corrupts VM configuration, making the VM unuseable" [Undecided,New] https://launchpad.net/bugs/1272664
[17:03] <doko> seb128, hmm, not seen in http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140108-trusty.html
[17:04] <seb128> doko, http://cgit.freedesktop.org/poppler/poppler/log/?h=poppler-0.24 ... there is like 10 commits between those poppler versions
[17:05] <seb128> doko, do you have a small testcase?
[17:08] <doko> seb128, no, not directly. try to build gdb-doc
[17:08] <doko> or iproute2
[17:08] <seb128> that's not a small testcase
[17:08] <seb128> k
[17:09] <seb128> well, I guess first trying with the trusty version of poppler (e.g not the proposed one) rebuild would be useful
[17:09] <seb128> then if that works there is like a 10 commits diff, shouldn't be too difficult to find which one created the issue
[17:09] <seb128> I can have a look, but that's not going to be for today
[17:17] <doko> seb128, now filed #1273779
[17:17] <seb128> doko, thanks
[17:18] <seb128> doko, do you know if it happens in Debian as well?
[17:18] <doko> seb128, only checked the poppler version in nustable, and I can't reproduce it
[17:19] <seb128> doko, ok
[17:19] <stgraber> pitti: you could poll using "lxc-attach -n <container> -- runlevel" or something like that
[17:21] <pitti> stgraber: right, that's what I came up with; thanks!
[17:34] <dobey> mardy, kenvandine: hey, is there any work on supporting google hosted apps accounts in online-accounts? (in a way that is easy to differentiate them from standard google accounts, if it already "works")
=== bfiller is now known as bfiller_afk
[17:58] <pitti> $ sudo lxc-start -n nosuchcontainer
[17:58] <pitti> lxc-start: Executing '/sbin/init' with no configuration file may crash the host
[17:58] <pitti> stgraber: ^ want a bug, or known issue?
[17:58] <pitti> stgraber: (it's at least confusing)
[18:02] <stgraber> pitti: the error message seems right to me
[18:02] <stgraber> pitti: a container doesn't need to exist in /var/lib/lxc to work
[18:03] <stgraber> pitti: you could pass parameters using -f or multiple -s without having it in the lxcpath
[18:03] <pitti> oh, I didn't know that
[18:04] <pitti> but I didn't give -f or any other option
=== zz_mwhudson is now known as mwhudson
=== mwhudson is now known as zz_mwhudson
=== zz_mwhudson is now known as mwhudson
=== bfiller_afk is now known as bfiller
[20:18] <jtaylor> nice py3.4b2 -> py3.4b3 regresses doc strings
[20:21]  * Logan_ waves to Noskcaj.
[20:21] <Noskcaj> hey Logan
[20:21] <Logan_> Noskcaj: I saw the logs from the DMB meeting. You seemed confused. :P
[20:22] <Noskcaj> I'm currently stuck with no internet and overslept the meeting. So things could be better
[20:22] <Noskcaj> i'd only had 4 hours sleep before the meeting, so that would be why
[20:22] <Logan_> :/
[20:27] <Noskcaj> Logan_, The darktable merge should be done now
[20:27] <Logan_> yes master
[20:27] <Noskcaj> ;)
[20:28] <Noskcaj> Now if applying for MOTU by email would unbreak
[21:02] <qengho> kees: I saw your post about "-fstack-protector-strong". Looks really promising. I'm also interested in "-fPIE -pie" as default, at least for 64-bit archs. I wonder if there are any valid objections any more.
[21:02] <jtaylor> does -pie finally not mess up shared libraries now?
[21:03]  * qengho doesn't know.
[21:04] <jtaylor> in that if you add it to dpkg-buildflags for lib + binary package like asterisk it ftbfs
[21:04] <qengho> I'll test.
[21:04] <jtaylor> you'll have to remove the hardening wrapper first, its still useful for this case
[21:05] <mardy> dobey: hi!
[21:05] <dobey> hi mardy
[21:06] <mardy> dobey: Google Apps accounts do work, just write the e-mail address and keep the password field empty
[21:06] <mardy> dobey: at least, they were working last time I tried :-)
[21:06] <dobey> mardy: is there any way to differentiate them from normal google accounts?
[21:07] <dobey> parse the e-mail address?
[21:07] <mardy> dobey: mmm... what differentation would you like to see?
[21:07] <mardy> dobey: yes, we do that, and use the email address as display name for the account
[21:07] <dobey> mardy: how to know that an account is for an ubuntu.com google apps thing, for example
[21:07] <mardy> dobey: are you in Ubuntu Touch or on the desktop?
[21:08] <dobey> mardy: my workstation. but it's more of a general question.
[21:08] <mardy> dobey: so, you are saying that after creating an account, you don't see the email address under it, in the account list?
[21:10] <mardy> dobey: I've to quit now, but if that's so, please file a bug; something might hav broken recently
[21:11] <dobey> mardy: no, i'm asking if technically there is a way to programatically determine if an account is related to a specific apps for domains, domain
=== salem_ is now known as _salem
=== seb128_ is now known as seb128
[23:23] <YokoZar> infinity: ~20% of users were on PPA last I looked, so I'd say yes.
=== freeflying_away is now known as freeflying