[04:18] <Unit193> pitti: Good morning.
[04:20] <darkxst> Unit193, hey, can you make a branch against lp:ppa-versions with your changes, I couldnt download the paste
[04:20] <darkxst> (will merge everything except the change of debian tracker, kind of like the new better)
[04:21] <Unit193> darkxst: Uhh, sure.  I wouldn't recommend it though, I don't know python so it's all hacks. :P
[04:23] <darkxst> Unit193, it looked ok to me
[04:30] <pitti> Good morning
[04:30] <pitti> FTR, I lost overnight scrollback; thanks to unity crashing 30 seconds after I started my session (during dist-upgrade)
[04:39] <darkxst> hey pitti
[04:45] <darkxst> pitti, anyidea how to change the location of /tmp in python? I tried to set TMPDIR, but retracer is failing
[04:45] <darkxst> dpkg-deb: error: unable to create temporary directory: No such file or directory
[04:47] <pitti> darkxst: hm, did you create $TMPDIR actually?
[04:47] <darkxst> pitti, yes, its in my home folder
[04:47] <pitti> darkxst: AFAIK the tempfile module ought to respect $TMPDIR
[04:48] <darkxst> thats what I though
[04:48] <darkxst> thought
[04:49] <Unit193> darkxst: Try that?  And don't say I didn't warn you. :P
[04:49] <pitti> $ mkdir /tmp/x; TMPDIR=/tmp/x python3 -c 'import tempfile; print(tempfile.NamedTemporaryFile().name)'
[04:49] <pitti> /tmp/x/tmpfkpdqt0l
[04:49] <pitti> seems fine to me, I also tried with mkstemp()
[04:50] <pitti> darkxst: hm, no idea then; can you run strace on it and see what it tries to do?
[04:54] <darkxst> pitti, nm, was just a typo
[04:55] <darkxst> Unit193, are you using some script that messes with whitespaces?
[04:55] <Unit193> No.
[04:56] <darkxst> Unit193, why are there unrelated whitespace changes in your commits then? http://bazaar.launchpad.net/~unit193/ppa-versions/xfce-changes/revision/45 for example
[04:58] <Unit193> darkxst: 'commit file.py -m' vs 'commit -m', noticed I missed them too late in rev 41.
[04:58] <darkxst> Unit193, can you generalise this, so the list comes from the profiles (http://bazaar.launchpad.net/~unit193/ppa-versions/xfce-changes/revision/40)
[04:59] <darkxst> and make it get_upstream_extra
[04:59] <darkxst> will use it in gnome for freedesktop modules
[04:59] <Unit193> Uhh.
[05:00] <Unit193> Had to filter out the veeery old (not in Debian, don't actually have releases, etc.) packages, so it's a bit specific.
[05:02] <darkxst> err, right misread that
[05:03] <darkxst> was only glancing though looked like you were adding a list of extra packages to pull in
[05:04] <Unit193> No, but thought about that next as there's a few more I'd like to track.
[05:04] <Unit193> But, not sure that'd actually work.
[05:09] <darkxst> Unit193, add a dictionary to the profiles, something: upsteam_extra = {upstream:package, ... }
[05:14] <darkxst> may need a path in there as well though I suppose
[05:15] <Unit193> Yeah, and upstreams tend to be a bit different.
[05:15] <darkxst> Unit193, maybe upstream:path would be better
[05:15] <darkxst> or you can do a list of tuples
[05:16] <darkxst> [(upstream, package, path)]
[05:16] <darkxst> I think the ubuntu-desktop script does something like that
[05:17] <darkxst> Unit193, http://bazaar.launchpad.net/~ubuntu-desktop/ubuntu-desktop-versions/trunk/view/head:/packages.py
[05:31] <darkxst> pitti, the symlink hackery ok with you or should it perhaps live in sandboxutils?
[05:52] <pitti> darkxst: haven't looked in detail yet, but probably okay
[05:55] <darkxst> pitti, its all a little horid, but the auto-load framework way pre-dates the introduction of python scripts
[05:55] <darkxst> and solib-absolute-path gets stuff in the middle of the file names
[05:57] <darkxst> I've not seen anything in the scripts I have worked on (mainly glib and mozjs) that would require deadlock versioning, but then I also haven't seen any of the old .gdb scripts
[06:11] <AndrewMock> I would like to know why the trusty/nginx-light package includes so many extras...
[07:38] <jamespage> pitti, Daviey: morning - I have a conditional release team ack for https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1423601
[07:39] <jamespage> but I need a willing archive admin for the minor python-* package split that I'm tracking from upstream packaging - would one of you be OK with doing the binary NEW's for that?
[07:40] <pitti> jamespage: yes, can do if it happens today (will be on vac next week)
[07:42] <jamespage> pitti, will upload shortly - thanks!
[07:43] <jamespage> pitti, ok - uploading now - it will take a few hours to complete the builds
[08:10] <dholbach> good morning
[08:21] <Unit193> darkxst: Hah, whoops.  When re-importing the changes, I spelled 'utcnow' as 'uctnow', FYI.
[09:11] <ogra_> cjwatson, i got an oops fo you :) https://launchpadlibrarian.net/200087368/upload_22505_log.txt
[09:12] <ogra_> *for
[09:13] <pitti> Unit193: question for you in bug 1431200
[09:19] <cjwatson> ogra_: Apparently livecd.ubuntu-touch.system-i386+generic_x86.img was zero-sized.  Do you know why?
[09:20] <Unit193> pitti: Answer for you.
[09:21] <ogra_> cjwatson, no, i got a build log by mail where it seems to finish fine
[09:22] <ogra_> hmm
[09:22] <pitti> Unit193: thanks; I wanted to see if it was ConditionFailed=, such as in a VM; daemon-reload would retry those
[09:22] <ogra_> Unmounting chroot for build LIVEFSBUILD-22505...
[09:22] <ogra_> RUN: /usr/share/launchpad-buildd/slavebin/remove-build ['remove-build', 'LIVEFSBUILD-22505']
[09:22] <ogra_> Removing build LIVEFSBUILD-22505
[09:22] <ogra_> cjwatson, thats the last three lines
[09:22] <cjwatson> ogra_: Right, so did I, the build clearly succeeded but appears to have resulted in one of the output files being zero-length
[09:23] <cjwatson> Where the previous version was 105.4 MiB
[09:29] <cjwatson> ogra_: I'm afraid I don't have an explanation for you, other than that the zero-sized file is what caused this OOPS (perhaps we could make that more obvious, but it still ought to fail because it's broken).  There's no sign of a cause of this in the livefs build log nor in the buildd-manager logs, and livecd-rootfs is just copying that file out of the android binary package where it isn't zero-sized.  The only suggestion I have is to ...
[09:29] <cjwatson> ... dispatch a new build.
[09:31] <ogra_> cjwatson, yeah, will do that and see
[09:32] <pitti> Unit193: can you actually reproduce this with just daemon-reload?
[09:32] <pitti> Unit193: I can't, I need apt-get install --reinstall systemd
[09:32] <Unit193> pitti: Yes, I can.  I just did in fact.
[10:32] <pitti> zyga: ah, you and your C locale.. :-)
[10:32] <pitti> this really doesn't belong on a desktop..
[10:33] <zyga> pitti: hmm? what :)
[10:33] <pitti> folks, at least use C.UTF-8 for $deity's sake :)
[10:33] <zyga> pitti: where?
[10:33] <zyga> pitti: :D
[10:33] <pitti> zyga: bug 1431421
[10:33] <pitti> zyga: sorry, bug 1430773
[10:34] <pitti> zyga: (fixed now)
[10:34] <zyga> pitti: I don't set the C locale anywhere
[10:34] <zyga> pitti: (thanks)
[10:34] <zyga> pitti: I don't know why that happened
[10:34] <zyga> pitti: could it be because my pl_PL.UTF-8 locale was unavailable in my sid sbuild chroot?
[10:34] <pitti> zyga: you call this as part of some sbuild command, right? perhaps that removes the locale at the time whne you call adt-run
[10:34] <zyga> yes
[10:35] <zyga> pitti: http://paste.ubuntu.com/10590142/
[10:35] <zyga> this is my .sbuildrc
[10:35] <pitti> zyga: ah, you call adt-run *inside* the schroot? and then let this start  another chroot?
[10:35] <zyga> not sure, this is from sbuild debian wiki page
[10:35] <pitti> ah ok, I blame sbuild then :)
[10:35] <zyga> looks like it yeah
[10:35] <zyga> those run inside the chroot AFAIK
[10:35] <zyga> pitti: though I totally agree about C being evil
[10:36] <pitti> apw, jodh: \o/ on #1429756, nice work!
[10:38] <apw> pitti, jodh gets a prize for a reproducer i could fit in a VM
[10:38] <pitti> apw: ah, and then git bisect run FTW? :-)
[10:39] <apw> pitti, no i read the 600M strace log to find the symptoms, and from there i could find the commit that changed that area, and then ...
[10:39] <jodh> pitti: right, apw really deserves the prize for finding the needle in the 600M haystack! :-)
[10:39] <pitti> ok, I'm afraid you guys have to share the prize then..
[10:40]  * apw gets a cookie out of the jar
[10:40] <pitti> especially since it's already so small -- it's a silly green bullet in jenkins! :-)
[10:41] <zyga> pitti: wow, I nice catch with "you've"
[10:42] <zyga> pitti: I pasted that from twine docs
[10:42] <pitti> zyga: well, it's legit -- debian control files are UTF-8
[10:42] <pitti> (and changelogs, etc.)
[10:43] <zyga> pitti: yeah though mainly for names
[10:43] <zyga> pitti: sbuild should have better defaults IMHO
[10:52] <ogra_> cjwatson, same error on rebuild, i uploaded a livecd-rootfs with more verbosity for the copying of the android bits ...
[10:52] <cjwatson> and did it reveal anything?
[10:52] <cjwatson> oh, the rebuild wasn't with that upload
[10:53] <ogra_> hasnt migrated yet
[10:53] <ogra_> right
[10:53] <ogra_> it looks to me like it never even hits the copy code on i386
[10:53] <cjwatson> that wouldn't explain a zero-length file
[10:53] <ogra_> right
[10:53] <cjwatson> if it never hit the copy code the file in question would be missing instead
[11:29] <Riddell> mvo: what is stopping packagekit being updated to 0.9 ?
[11:31] <cjwatson> Riddell: needs https://code.launchpad.net/~mvo/click/native-dbus
[11:31] <cjwatson> well, that might be for 1.0.0
[11:32] <cjwatson> yeah, plugin support went away in 1.0.0 not 0.9
[11:56] <doko> didrocks, please could you fix the recommends for grilo-plugins? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[12:03] <darkxst> doko, grilo-plugins-extra was never meant to be main'ed, but no one knows who promoted it
[12:07] <didrocks> doko: not sure why this is directed to me, seems the guy who promoted it didn't read the MIR (nor changed the bug report status)
[12:07] <didrocks> doko: so, we need to discuss it first once the people acting on the bug are around
[12:15] <doko> didrocks, afaicr you were the person requesting that in the past. anyway, demoted the extra package
[12:16] <didrocks> doko: I never requested promoting grilo, only review the MIR. I wouldn't request btw as I can promote it myself
[12:18] <didrocks> doko: I get you are mixing with darkxst (but we all start with a d :p)
[12:22] <Odd_Bloke> Does the 7 day SRU timer start from it hitting -proposed, or from verification-done?
[12:24] <infinity> Odd_Bloke: The former.
[12:25] <Odd_Bloke> \o/
[12:25] <Odd_Bloke> infinity: Thanks. :)
[12:25] <didrocks> infinity: oh btw, you will be pleased to know that I nuked this morning the whoopsie conffiles
[12:25] <didrocks> bdmurray: mind merging my 2 uploads to whoopsie and whoopsie-preferences?
[12:28] <infinity> didrocks: \o/
[12:29] <infinity> didrocks: Swapped from conffile to config file?
[12:29] <infinity> didrocks: Or did away with the need for it entirely?
[12:30] <didrocks> infinity: unfortunately, couldn't go away completely, so config file for one remaining option, but basing the enabled checkbox based on service status (being under upstart or systemd)
[12:31] <jamespage> pitti, ceph is built on some archs - I'm working on ppc* and armhf right now
[12:33] <ogra_> cjwatson, LOL
[12:34] <ogra_> cjwatson, so i replaced all cp with "cp -v" to get more info ... and now the build just succeeds
[12:35] <cjwatson> Heh
[13:12] <mvo> Riddell: if plugins are still supported, then nothing
[13:14] <Riddell> mvo: is packagekit(-qt) a reasonable choice for e.g. dolphin file manager installing samba so it can share files?
[13:17] <mvo> Riddell: is that something that you would add? that should be fine, the session installer api supports "install_packages" which you can just feed the samba names
[13:18] <Riddell> mvo: I'm thinking of a gsoc project to add that sort of feature in various places
[13:19] <Riddell> mvo: and the samba name could be hardcoded or could use appstream? except appstream has limited support in ubuntu
[13:19] <mvo> Riddell: yeah, the limited support is a issue as is that the packagename is different in different distros :/
[13:27] <Riddell> mvo: if DEP-11 gets implemented by debian does that help ubuntu at all?
[13:28] <mvo> Riddell: a bit maybe, but because debian uses dak and ubuntu LP for the archive I doubt it will help that much, maybe, depends how deeply this is entangled into dak I guess
[13:30] <Riddell> mvo: right
[13:36] <caribou> Is there a specific method to add a patch to a dkms package that doesn't use quilt or just add the file in ./patches & edit dkms.conf ?
[13:40] <infinity> caribou: dkms.conf:PATCHES[#]= is the correct way.
[13:40] <caribou> infinity: thanks
[14:31] <seb128> pitti, bdmurray, btw bug #1427264 has details about the schroot/ecryptfs/userdir mount issue, not specific to ecryptfs but to configs where /home is a separate mount
[14:39] <tyhicks> seb128: you mean where /home/USER is a separate mount
[14:39] <tyhicks> seb128: /home being a separate mount is no problem
[14:39] <seb128> tyhicks, right
[14:39] <seb128> sorry ;-)
[14:39] <tyhicks> no prob :)
[14:49] <tyhicks> seb128: after we have a chance to better test the fstab change, do you think we should change the fstab file in the click package to do the rprivate /home?
[14:50] <seb128> tyhicks, I don't understand enough about the implications to have an opinion on whether that's the right solution I think :-/
[14:50] <seb128> but if it works +1 from me
[14:50] <tyhicks> (after I get to test it some more, I plan on updating https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648459 to suggest that the default profile be changed)
[14:52] <tyhicks> seb128: ok, I know someone that can review the change and tell me about the implications
[15:02] <seb128> tyhicks, great, let me know how it goes, I'm happy to help testing
[15:06] <stokachu> @pilot in
[15:22] <doko> jamespage, rbasak: I think even updating golang to 1.4 will break building some of the ubuntu-touch apps. thanks due to embedded outdated go packages not packaged for ubuntu :-/
[15:29] <jamespage> doko, ohno
[15:36] <doko> jamespage, plus will break golong-log4go. there exist some patches in the upstream package, but this project seems to be dead
[15:37] <doko> should be updated by somebody having go coding experience
[16:10] <doko> jamespage, subscribed you to 1431872
[16:30] <flexiondotorg_> didrocks, Please would you be able to take another look at - https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-update/+merge/251487 ?
[16:33] <didrocks> flexiondotorg_: I guess better to ask that to the patch pilot
[16:33] <didrocks> flexiondotorg_: or wait for my shift
[16:33] <flexiondotorg_> didrocks, Tanks.
[16:34] <flexiondotorg_> Or Thanks, you choose.
[16:34] <didrocks> ;)
[16:34] <flexiondotorg_> stokachu, While you're piloting, please could you take a look at https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-update/+merge/251487
[17:14] <stokachu> flexiondotorg_: sure!
[20:31] <flexiondotorg_> stokachu, Yo.
[20:31] <flexiondotorg_> stokachu, Thanks for looking at my merge proposal.
[20:31] <flexiondotorg_> I am very sick right now, so my initial comment in there is not friendly.
[20:31] <flexiondotorg_> stokachu, I apologise for that.
[20:32] <flexiondotorg_> stokachu, Regarding https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-update/+merge/251487
[20:32] <stokachu> yea i got that...
[20:32] <flexiondotorg_> I am not sure how to resolve the source-is-missing lintian errors.
[20:33] <stokachu> dunno dude im off duty now
[20:33] <stokachu> @pilot out
[20:33] <flexiondotorg_> Please can you spare some wisdom.
[20:37] <Unit193> flexiondotorg_: https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-update/+merge/251487/comments/628312 seems to say he'll take care of the other lintian warnings.
[20:39] <flexiondotorg_> Unit193, Thanks for bring y attention to that comment. Just refreshed and see it now :)
[20:39] <flexiondotorg_> I can fix the warning at least :)
[21:08] <doko> stgraber, please file MIRs for new lua-filesystem b-d's: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[21:19] <stgraber> doko: done
[21:20] <stgraber> not sure how I missed the build-depends when I did the lua-filesystem MIR...
[21:23] <doko> meh, the nth text to html converter
[21:26] <doko> stgraber, bug subscribers missing ...
[21:26] <stgraber> doko: ah yeah, I'll subscribe to both
[21:27] <stgraber> doko: done
[21:28] <doko> stgraber, not lxc-team like lua-filesystem?
[21:28] <stgraber> doko: well, if lua-filesystem is broken, that affects lxc, if the b-d of lua-filesystem are broken for something other than lua-filesystem, the lxc team won't care
[21:29] <doko> then subscribe foundations, but not a single person
[21:29] <stgraber> I'd have subscribed foundations if I could have, you need to be team admin to subscribe a team...
[21:30] <doko> bdmurray, ^^^
[21:30] <stgraber> oh, actually, looks like I can use ubuntu-foundations-team
[21:31] <stgraber> because canonical-foundations-team admins it
[21:32] <stgraber> doko: done, moved to foundations
[21:33] <bdmurray> it should be foundations-bugs subscribed
[21:33] <bdmurray> to lua-filesystems is it?
[21:33] <doko> no, markdown and dh-lua
[21:35] <bdmurray> okay, done
[21:40] <doko> stgraber, please unsubscribe ubuntu-foundations-team
[21:40] <stgraber> done