[00:30] <mwhudson> RAOF: i'm still getting those hangs with mesa 9.0.2 :(
[00:43] <RAOF> mwhudson: Boo. You've got two options here, then. One: move further back in Mesa history. Two: try an older kernel.
[00:44]  * mwhudson stares at https://launchpad.net/ubuntu/+source/mesa/+publishinghistory
[00:45] <mwhudson> RAOF: i don't see from that when 9.0.2 hit quantal(-updates)
[00:45] <mwhudson> although i do notice that 9.0.3 hit just _after_ I started seeing the problems
[00:45] <mwhudson> bah
[00:49] <mwhudson> RAOF: i don't see from that when 9.0.2 hit quantal(-updates)
[00:49] <mwhudson> although i do notice that 9.0.3 hit just _after_ I started seeing the problems
[00:49] <mwhudson> (that == https://launchpad.net/ubuntu/+source/mesa/+publishinghistory)
[01:01] <RAOF> mwhudson: Just after? ie: it's unlikely to be the culprit?
[01:02] <mwhudson> yeah
[01:02] <RAOF> That firms the kernel as being a suspect.
[01:02] <mwhudson> i don't understand the kernel's publishing history on lp at all :)
[01:02] <mwhudson> mwhudson@narsil:failover-scripts$ uname -r
[01:02] <mwhudson> 3.5.0-27-generic
[01:02] <mwhudson> mwhudson@narsil:failover-scripts$ dpkg -l | grep linux-image-generic
[01:02] <mwhudson> ii  linux-image-generic                       3.5.0.27.43                                amd64        Generic Linux kernel image
[01:03] <mwhudson> that version doesn't appear on https://launchpad.net/ubuntu/quantal/+source/linux at all
[01:08] <StevenK> linux 3.5.0-27.46 shows in updates on that page
[01:09] <StevenK> mwhudson: It probably came from proposed a while ago?
[01:12] <Sarvatt> mwhudson: do you have a sandybridge GPU? hd2000 or hd3000
[01:12] <mwhudson> Sarvatt: sandybridge, yes
[01:12] <Sarvatt> there's been a regression in the last few kernel updates, bug 1140716
[01:12] <Sarvatt> you want either 3.5.0-25 or 3.5.0-28
[01:13] <mwhudson> oh yes, that looks like it
[01:14] <mwhudson> thanks
[01:14] <mwhudson> is 3.5.0-28 in proposed?
[01:14] <Sarvatt> yeah
[01:15] <Sarvatt> the fix in -28 may not actually fix it for you, instead of reverting the broken stable update they tried to backport fixes and some people are saying they are still broken when reverting the commit worked
[01:16] <Sarvatt> but it'd be good to mention that in the bug if it doesn't, -28 should be better
[01:17] <mwhudson> ok
[01:17] <mwhudson> sudo apt-get install linux-image/quantal-proposed ?
[01:17] <mwhudson> assuming the "usual" pinning
[01:19] <mwhudson> ah, linux-image-generic i think
[01:20] <Sarvatt> not sure if pinning the metapackage works instead of the actual package, sorry
[01:20] <Sarvatt> it should :)
[01:20] <mwhudson> the latter certainly is doing more than the former
[01:21] <mwhudson> hee, i certainly have a lot of kernels installed currently
[01:22]  * mwhudson restarts
[02:29] <george_e> I'm writing Debian packaging for an application and need to apply some Debian-specific patches. The problem is that the patches should only be applied to specific series (Quantal and Raring but not Precise).
[02:29] <george_e> I've got quilt patches properly set up in the patches/ directory.
[02:30] <george_e> ...but I need only _certain_ patches to be applied on Precise.
[02:30] <george_e> Is this possible?\
[02:30] <geofft> Is this for the Ubuntu archive, for a PPA, for a local archive...?
[02:30] <geofft> If it's for the Ubuntu archive, having a different source package go into precise-backports is totally normal
[02:30] <geofft> It's convenient when a package doesn't need to be modified to be backported, but it's by no means required.
[02:37] <george_e> geofft: It's for a PPA.
[02:37] <george_e> Actually, it's for a recipe.
[02:37] <george_e> So it would be nice if I could use the same Debian packaging for each series.
[02:42] <george_e> In my specific case, the "node" executable in Precise was renamed to "nodejs" in Quantal - hence my package doesn't need to be patched on Precise (since it references the "node" executable) but needs to be patched on Quantal and Raring (which do not have the "node" executable).
[02:49] <RAOF> george_e: You can't have the same binary package version with different content, which means you'll at the very least need to change the changelog
[02:49] <george_e> Yes but this is for different series.
[02:50] <george_e> ...or does that not matter?
[02:51] <mwhudson> Sarvatt: so far so good with the kernel from -proposed...
[02:52] <Sarvatt> mwhudson: good to hear
[02:52] <Sarvatt> x-x-v-intel from -proposed made it stop reporting bugs also if you upgraded to that..
[02:52] <mwhudson> nope
[02:53] <Sarvatt> it'll just silently do gpu hangs until it freezes
[02:53] <Sarvatt> ah good so that fix worked
[02:54] <mwhudson> yeah, i think so
[02:54] <mwhudson> i wasn't getting the hangs all that frequently so i'll give it about 24h before commenting
[02:54] <Sarvatt> good to hear, thanks for the heads up
[02:57] <Sarvatt> some people upgraded x-x-v-intel from proposed and said it fixed it but it really just stopped reporting crashes by removing the apport hook
[02:57] <mwhudson> heh
[02:57] <mwhudson> would you still get stuff in /var/crash without the hook?
[02:57] <Sarvatt> still crashing all the time in the background
[02:58] <Sarvatt> nope but you'd see it in dmesg
[02:58] <mwhudson> ah right
[02:58] <mwhudson> Apr 17 13:01:47 narsil kernel: [14665.887564] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[02:58] <RAOF> george_e: Yeah, it doesn't matter.
[02:58] <mwhudson> (that's before my restart )
[02:59] <RAOF> george_e: The contents of a given binary package version have to be unique across all series.
[02:59] <Sarvatt> yeah if the proposed kernel didnt work you'd see that in dmesg
[03:00] <Sarvatt> and it'd eventually just hang completely after a bunch of those :)
[03:00] <RAOF> george_e: For a quick reason why - think what happens on a precise→quantal upgrade: it won't upgrade the package because you've already got the same version installed, but you won't have the quantal package. Which is a problem :)
[03:01] <george_e> Ah, okay. That makes sense.
[03:01] <george_e> Thanks for the explanation. Perhaps what I really need is some sort of "meta-package" that provides a "node" => "nodejs" symlink for Precise.
[03:02] <george_e> I know that Quantal and Raring include a package "nodejs-legacy" that does the opposite.
[03:02] <RAOF> Yeah, that might be the ticket.
[03:02] <george_e> Which one?
[03:02] <george_e> Using "nodejs-legacy"?
[03:03] <RAOF> The general approach - a package which does nothing but provide the expected symlink.
[03:06] <george_e> Okay.
[03:14] <george_e> RAOF: What would be an appropriate name for the package that provides the "nodejs" => "node" symlink?
[03:15] <RAOF> node-unlegacy? :)
[03:16] <george_e> :)
[03:43] <pitti> Good morning
[04:39] <siretart> morning
[04:39] <siretart> pitti: you're up early :-)
[04:39] <pitti> hey siretart
[04:40] <siretart> robru: do you happen to be still awake?
[04:40] <robru> siretart, yes! not even 10PM here ;-)
[04:40] <siretart> robru: :-)
[04:41] <siretart> robru: thanks for contacting me and your interest in ~ubuntu-elisp, I've just made you admin in that team
[04:41] <robru> siretart, ah, thank you!
[04:41] <robru> siretart, I'm actually just working on the packaging right now... enabling a certain distropatch so that the snapshot will have support for the existing emacsen-common package.
[04:41] <siretart> robru: please do take care for our daily recipe and restore that team PPA to sanity. It is currently really in a desperate state
[04:42] <siretart> robru: I've been busy lately myself, but now that I've handed in my disseration this week, I think I should be able to catch up with foss stuff really soon.
[04:42] <robru> siretart, do you know if there are a lot of users who are subscribed to this PPA? (ie, people who potentially haven't yet noticed how long it's been since the last update)
[04:43] <siretart> robru: I have to admit that I totally lost track of that team, so no idea ATM
[04:43] <robru> siretart, ok, no worries. I'm hoping to shake things up a bit, so there might be some growing pain during the transition.
[04:43] <siretart> go ahead :-)
[04:44] <robru> siretart, but so far I've had a few people testing my existing packaging and the response has been positive.
[04:44] <robru> siretart, great ;-)
[05:05] <stokachu> could i get a patch pilot to review nominations for bug 1169740?
[05:58] <dholbach> good morning
[07:28] <smb> infinity, Likely too convoluted. Hm, seems tomorrow was not the day before yesterday's tomorrow. At least lp tells me the xen packages are still in the unapproved queue for p and q.
[07:41] <diwic> TheMuso, pitti, I'm looking at bug 1167192, and I wonder, is the xdg_runtime_directory deleted at some point?
[07:43] <diwic> TheMuso, yep, it's deleted on logout, and PulseAudio only quits ~30 seconds after idle
[07:44] <diwic> TheMuso, so if you then login immediately again, PulseAudio can't find that it's already running, because the file used for that purpose has been deleted
[07:45] <seb128> diwic, not sure if that's revelant there, but the dmesg log has "[   58.622779] systemd-logind[2257]: New seat seat0."
[07:46] <seb128> diwic, logind and libpam-xdg-support are likely to behave differently
[07:46] <diwic> seb128, I'm reading the xdg spec now. It seems like we're doing the right thing by deleting the directory.
[07:46] <diwic> seb128, i e it's PulseAudio that needs fixing
[07:46] <seb128> ok
[07:47] <seb128> that makes sense to clean behind
[07:47] <pitti> diwic: it gets deleted once that user closes her last session, yes
[07:50] <diwic> pitti, I think the correct course of action would be to monitor the relevant file/directory and quit Pulseaudio if deleted. Would that make sense to you too?
[07:51] <pitti> diwic: usually such daemons listen to the D-BUS "lost connection" signal and quit themselves
[07:51] <pitti> diwic: i. e. when the user's session dbus goes away, everything hanging off it should quit itself, too
[07:52] <pitti> diwic: in raring+1 we'll also switch to logind, and we could discuss whether quitting a session should also kill all of its processes
[07:52] <pitti> (but that might not be desirable, i. e. screen sessions started in the sessions should stay)
[07:53] <diwic> pitti, is there a session dbus on VT sessions too?
[07:53] <pitti> diwic: ah no, not usually
[07:53] <pitti> diwic: but there is a CK (or logind) session, so listening to that signal should also work
[07:54] <pitti> diwic: monitoring $XDG_RUNTIME_DIR sounds okay as well, but it might not always be present
[07:54] <pitti> but then, if it isn't, just don't do it I guess
[07:54] <diwic> pitti, what would be the use case for not setting xdg_runtime_dir?
[07:55] <pitti> diwic: older distributions mostly
[07:55] <pitti> diwic: but for current ubuntu it really should be there
[07:55] <pitti> OTP, bbl
[08:09] <cjwatson> stokachu: done
[08:19] <infinity> smb: Look again.
[08:20] <smb> infinity, Amazingly, gone. :-P
[08:27] <doko> jibel, pitti: I assume https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/ doesn't show a build of the recent upload yet?
[08:28] <pitti> doko: no, last build from 16.04.2013 22:40:30
[08:29] <pitti> it's also not running in the "real" jenkins yet, hmm
[08:36] <Laney> @pilot in
[08:40] <jibel> doko, https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/3/ is the test for python3.3 3.3.1-1ubuntu3
[08:40] <jibel> I didn't push the modification for fsync yet.
[08:41] <jibel> that's the 2 tests that fail for python3.3 and for python3.3dm this is the output to stderr we talked yesterday
[08:44] <pitti> jibel: do you know why the new python3.3 upload didn't trigger a new test run? is that because of the machine which went out over night?
[08:47] <jibel> pitti, it did, the last upload of python3.3 is 3.3.1-1ubuntu3 published to -proposed 11hours ago and the version tested in run #3 of python3.3
[08:48] <pitti> jibel: oh right, I just saw the "4 hours ago", but that was raring migration; sorry
[09:02] <henrix> @pilot in
[09:15] <OdyX> tkamppeter: cups + cups-browsed and printer queues that don't disappear, does that ring a bell?
[09:18] <infinity> doko: Why did you upload python-default/precise with a bizarre dpkg-genchanges -v invocation that included the whole changelog in .changes? :)
[09:18] <infinity> doko: (I'd poke more fun, but I did exactly the same thing with something last year...)
[09:19] <infinity> doko: Anyhow, want to reupload that to avoid sending a 13k email to precise-changes?
[09:19] <tkamppeter> OdyX, what exactly happened?
[09:20] <OdyX> tkamppeter: I'm moving between offices, without shutting down. Now I see printers for offices I left 10 days ago.
[09:20] <doko> infinity, I have to look at this anyway, so for now only the python3 stuff seems to be ready
[09:22] <infinity> doko: I'm going to reject that just because of the giant .changes file.  The rest of the upload was fine, so go ahead and bounce it back whenever.
[09:22] <tkamppeter> OdyX, seems that cups-browsed needs to get a removal signal from Avahi to remove a queue while running. Workaround is restarting cups-browsed.
[09:24] <tkamppeter> OdyX, probably cups-browsed needs to detect somehow when the network environment changes, to mark all queues unconfirmed them and if Avahi does not report their presence, they go away after some secs. But how can cups-browsed detect the change of the network environment?
[09:25] <OdyX> tkamppeter: indeed, cups-browsed restart does the trick.
[09:25] <OdyX> tkamppeter: don't know; doesn't avahi have such triggers ?
[09:28] <tkamppeter> OdyX, the local machine reports itself as workstation in avahi-discover. This record contains the MAC address and the IP for the local network. Perhaps one has to track this avahi report and if the IP changes to unconfirm all queues.
[09:29] <OdyX> that could work. I'm surprised you haven't gotten such a report yet though.
[09:30] <tkamppeter> OdyX, seems that most people shut down their boxes when they move between environments, or they have only something like 2 environments with few print queues and so the extra queues are no problem for them.
[09:30] <OdyX> well, it's not a problem per se, it's just noise.
[09:34] <tkamppeter> OdyX, another thing: cups-browsed is only included in Raring, Ubuntu's development branch, and there we get a new kernel twice a week, so who reboots after every kernel update will probably not have the problem.
[09:34] <OdyX> ah yeah, good point.
[09:34] <OdyX> tkamppeter: good you have me then :)
[09:40] <Laney> Can someone reject https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/clamav/quantal-security/+merge/156911 ?
[09:49] <pitti> Laney: done
[09:50] <Laney> danke!
[10:04] <jibel> doko, I re-ran autopkgtest for python3.3 with the fsync fix, the tests that failed previously pass now but there is this failure that I haven't seen before http://paste.ubuntu.com/5715517/
[10:04] <doko> jibel, no, never did see this one
[10:06] <doko> jibel, and it doesn't fail on the buildd either: https://launchpadlibrarian.net/137578622/buildlog_ubuntu-raring-amd64.python3.3_3.3.1-1ubuntu3_UPLOADING.txt.gz
[10:31] <mlankhorst> do we have someone to look at https://bugs.launchpad.net/ubuntu/+source/xorg-lts-quantal/+bug/1134492 ?
[10:45] <jibel> doko, the refs count to stderr comes from running script.py with python3.3dm. If you use python3 instead of python3.3dm in testsuite-dbg to execute script.py the testsuite pass in autopkgtest.
[10:46] <jibel> doko, also I cannot reproduce the uuid failure, could it be due to a lack of entropy on the test system?
[10:46] <doko> jibel, but the whole point of the exercise is to use the dbg interpreter ...
[10:46] <jibel> doko, to execute the testsuite not script.py
[10:48] <doko> jibel, entropy, maybe try it on a virtulized buildd too? if that matches your autopkgtest setup better
[10:53] <jibel> doko, okay, I'll try that. re ref counts that'll give a command like : python3 /tmp/tmp.pASFAYfBf4/ubtree0-ubtree/debian/script.py "/dev/null" "python3.3dm  ...
[10:53] <jibel> which is fine since it still use the dbg interpreter to run the testsuite.
[10:54] <doko> ok, but I better use python3.3
[11:14] <Laney> pitti: Could you do https://code.launchpad.net/~fcole90/ubuntu/precise/python-reportlab/fix-for-1005187/+merge/158774 too? :-)
[11:15] <pitti> Laney: where "do" == ?
[11:15] <Laney> reject
[11:15] <Laney> or Merged, or whatever
[11:15] <Laney> I merged it, but not into the target branch there
[11:15] <pitti> Laney: ah, set to merged then
[11:16] <xnox> Laney: pitti: http://youtu.be/8vJthZst5tQ "down with whatever" =)))))
[11:16] <Laney> what is this hideous row?
[11:16] <Laney> </middle aged>
[11:17] <pitti> xnox: what's that? I can't watch that in Germany
[11:17] <ogra_> pitti, well, talk to gema :P
[11:17] <xnox> pitti: kelly rowland singing "I'm down with whatever" w.r.t. to merge request status.
[11:17] <Laney> I'm Kelly Rowland and I approve of this MP.
[11:18] <ogra_> haha
[11:32] <tkamppeter> mlankhorst, I am trying to offer my patched xorg-server to the people which suffer the touch-click bug via PPA but it seems that when building it in the PPA xorg-server falls into an infinite loop in the test suite. See https://launchpad.net/~till-kamppeter/+archive/ppa/+build/4499041
[11:32] <mlankhorst> tkamppeter: just retry
[11:33] <mlankhorst> it happens randomly
[11:33] <tkamppeter> mlankhorst, strange is also that i386 and amd64 are bult by an "arm ppa builder" and there is no armhf built at all.
[11:33] <cjwatson> That's normal
[11:33] <mlankhorst> virtual armhf builder right?
[11:33] <cjwatson> The builder is ARM-capable (via qemu), but can build any of i386/amd64/armhf
[11:35] <mlankhorst> tkamppeter: just retry, that failure is not an infinite loop, it just does nothing
[11:35] <mlankhorst> presumably some race
[11:35] <cjwatson> And PPAs only get armhf on explicit request
[11:35] <tkamppeter> mlankhorst, I have canceled and rescheduled the builds now.
[11:36] <tkamppeter> cjwatson, so it is a fast Intel processor and not a slow ARM?
[11:37] <cjwatson> Yes
[11:37] <cjwatson> A Xen guest, actually
[11:37] <mlankhorst> tkamppeter: anyway until the corruption gets fixed I'm not going to bother
[11:38] <tkamppeter> mlankhorst, I have also successfully built my patch on the Nexus 7 and my Nexus 7 works reliably with it. Right before installing it the screen got stuck on the first click.
[11:38] <tkamppeter> mlankhorst, so then let it come as SRU as soon as the corruption get fixed.
[11:38] <mlankhorst> I'm running on nexus7 with valgrind and my nexus7 xserver dies on it rather soon
[11:51] <Laney> freeflying: Gentle poke to remember to upload with -v when there's more than one version covered in an upload (it causes bugs to be closed, amongst other things)
[11:51] <freeflying> Laney: acked, thanks
[11:59] <mlankhorst> Laney: hah, I fixed my lts rename scripts to do it for me, now I can forget all about it :-D
[11:59] <Laney> don't forget too much :P
[12:00] <mlankhorst> forget what? ;-)
[12:00] <Laney> donk
[12:07] <Laney> @pilot out
[12:30] <doko> Sweetshark, should libreoffice-emailmerge be demoted?
[12:38] <apachelogger> pitti: are you still handling langpack creation?
[12:47] <pitti> apachelogger: I twiddle the cronjobs from time to time, yes
[12:48] <apachelogger> pitti: who would I talk to to get new templates into a langpack and that langpack created? (i.e. they are on launchpad but not in any langpack yet)
[12:50] <pitti> apachelogger: if they were imported recently (i. e. in the last few days), they should be in the next automatic export and upload
[12:51] <apachelogger> pitti: they have been imported for 2 weeks or more, so I am getting a bit anxious :)
[12:51] <pitti> apachelogger: what's an example domain name?
[12:52] <apachelogger> pitti: kubuntu-patched-l10n
[12:52] <pitti> from which package is taht?
[12:52] <apachelogger> same package
[12:52] <doko> pitti, jibel: both python2.7 and python3.3 uploaded. please fix everything else in autopkgtest ;-)
[12:53] <pitti> WARNING: unknown translation domain: kubuntu-patched-l10n
[12:53] <apachelogger> hum, try kubuntu-firefox-installer
[12:54] <apachelogger> albeit that's a bit strange... https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-patched-l10n
[12:54] <pitti> apachelogger: it's due to that LP bug that it doesn't add universe packages to the domain -> package map
[12:54] <pitti> bug 1048556
[12:55] <mlankhorst> mvo: hm, any thoughts on https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1134492 ? I posted what I know there, should be straightforward to reproduce with pbuilder
[12:56] <pitti> apachelogger: but we stopped having kde langpacks a long time ago; should these just appear in the main packs?
[12:57] <apachelogger> pitti: yeah, we only have like 5 packages which go through launchpad and each has 10 strings or so, so dpm and I agreed that simply putting them in the main packs should be good enough
[13:00] <apachelogger> pitti: the affected packages are: https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-patched-l10n | https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-debug-installer | https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-web-shortcuts | https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-firefox-installer | https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-notification-helper
[13:00] <pitti> apachelogger: I added manual workaround mappings for kubuntu-patched-l10n, kubuntu-firefox-installer, kubuntu-notification-helper
[13:00] <pitti> ah
[13:01] <stokachu> cjwatson: re: nominations, thanks :)
[13:03] <pitti> apachelogger: ok, workaround table updated: http://paste.ubuntu.com/5715858/
[13:05] <apachelogger> pitti: missing notificationhelper = kubuntu-notification-helper and kcm_notificationhelper = kubuntu-notification-helper
[13:06] <pitti> apachelogger: added
[13:07] <apachelogger> pitti: yay, thank you very much :)
[13:08] <highvoltage> is it just me or are these instructions actually harmful? http://helpx.adobe.com/air/kb/install-air-2-64-bit.html#main_Install_AIR_2_on_64_bit_Ubuntu_9_04
[13:10] <ogra_> highvoltage, dont worry, we wont have to support broken ubuntu 9.04 installs anymore :P
[13:11] <highvoltage> :)
[13:11] <highvoltage> ogra_: the worse thing is that adobe recommends that as the current way to install air on ubuntu :-/
[13:11] <ogra_> well, dont install air or get support at adobe for the broken thing afterwards
[13:14] <highvoltage> *nod*
[13:14] <highvoltage> I just despise them a little bit more for pasting instructions that will damage user's systems
[13:19] <shadeslayer> lol air
[13:22] <smartboyhw> xnox, er I thought Wubi was not going out for 13.04. Why did you merge my fix?:O
[13:24] <xnox> smartboyhw: what happens in the upstream wubi project does not affect what gets released or not by upstream ubuntu project.
[13:24] <smartboyhw> xnox, ah:O
[13:49] <Sweetshark> doko: yep, -emailmerge isnt needed in main anymore.
[14:11] <wgrant> pitti: From which file are the domains you reference in bug #1048556 missing?
[14:11] <pitti> wgrant: they should be in ./rosetta-*/mapping.txt
[14:12] <pitti> bbl
[14:12] <wgrant> pitti: Yes, but which language pack tarball?
[14:12] <pitti> wgrant: teh current raring ones
[14:12] <wgrant> Ah, raring
[14:12] <henrix> @pilot out
[14:17] <wgrant> pitti: I don't see that template in the langpack tarball at all. Are you sure the langpack inclusion flag was set at that point?
[14:21] <dobey> how do i tell what requires nullmailer (or mail-transport-agent) on my system? apt-get remove --purge nullmailer just wants to install exim4 instead, to replace it
[14:21] <dobey> and apt-cache rdepends isn't helpful
[14:24] <wgrant> pitti: All three templates were created just a few days before the export, and I don't see any of their pofiles in the tarball.
[14:30] <bdmurray> ev: its rather hard to see the functions here https://errors.ubuntu.com/?user=foundations-bugs&period=month
[14:34] <ev> bdmurray: *shrugs* suggestions welcome. I think trying to show enough of the functions to make them legible is a near impossible task
[14:35] <ev> bdmurray: not sure why 4.0-0ubuntu20.2+elementary5~precise1 is showing up in there, given that we're filtering out distributions
[14:36] <bdmurray> ev: well I used to be able to see it when I moused over the link in Firefox now with the hash url ...
[14:38] <ev> bdmurray: we could have alt text or a floating div that displayed the full thing on mouse over
[14:38] <ev> bdmurray: feel free to file a bug for that
[14:39] <bdmurray> ev: okay, I think that would help as its easier for me mentally to keep track of the funciton than the bug numbers (which don't always exist)
[14:39] <ev> bdmurray: I very much agree
[14:49] <pitti> wgrant: what is a "langpack inclusion flag"?
[14:52] <jibel> doko, python3.3 autopkgtest is green https://jenkins.qa.ubuntu.com/job/raring-adt-python3.3/7/   \o/
[14:54] <doko> jibel, and 2.7?
[14:57] <jibel> doko, red test_tempnam failed with a permission denied probably because adt set TMPDIR to a readonly directory
[14:58] <doko> jibel, so is this a adt issue?
[14:59] <doko> I accidentally left the pgo and lto optimizations disabled, so I'll have to do one more upload
[14:59] <wgrant> pitti: There's a flag on the +admin form for Ubuntu templates that determines whether the template will be included in langpacks.
[14:59] <jibel> pitti, ^^ you fix that by executing the testsuite with env -u TMPDIR, correct ?
[14:59] <pitti> apachelogger: ^ do you know about this? (wgrant's comment)
[15:00] <pitti> jibel: why would $TMPDIR be readonly?
[15:00] <pitti> jibel: I do that for processes which change user, i. e. run stuff as non-root
[15:06] <xnox> jibel: pitti: doko: I thought one should be using $ADT_TMP which should be writtable location.....
[15:06] <pitti> xnox: yes, if you don't use su
[15:06] <pitti> xnox: but if you start a test as root, and then su to another user, that other user won't be able to access $ADTTMP or its $TMPDIR
[15:06] <pitti> as these are still owned by root
[15:07] <xnox> hmm...
[15:08] <apachelogger> pitti: nope, also I don't think I have access to +admin ^^
[15:10] <pitti> wgrant: hm, I thought we already had that X-Ubuntu-Langpacks: header for that; I never heard about that flag
[15:12] <seb128> pitti, didn't we stop using that until bug #1048556 is fixed?
[15:13] <pitti> seb128: maybe, I don't know
[15:13] <seb128> pitti, oh, you just commented on that bug
[15:13] <pitti> who can access these +admin pages?
[15:13] <seb128> pitti, what's the url?
[15:13] <seb128> dpm can I guess
[15:13] <happyaron> pitti: guess I can. U-T-C team.
[15:13] <pitti> I don't know that either
[15:13] <seb128> if that's a translator thing
[15:13] <doko> jibel, pitti: so it looks like the control file needs another attribute to specify the user the tests are run with?
[15:14] <pitti> doko: isn't the default "user" or "root" (Restrictions: needs-root) sufficient?
[15:14] <xnox> doko: /me thought we specify that when launching adt tester already to match the adt testing environment. E.g. packages themself shouldn't fiddle with that.
[15:15] <pitti> we probably need to take a second look at this
[15:15] <xnox> doko: we can give the username currently used by our setup and/or check for it.
[15:15] <doko> pitti, I need to turn off apport, the rest can be done as a normal user
[15:15] <pitti> if we run the entire test suite as user, and just start out as root to disable apport, it's probably better to put the apport disabling into a test before the "main" one, and only run that one as root
[15:16] <pitti> doko: ah, then we could have "Tests: disable-apport\nRestrictions: needs-root\n\nTests: testsuite" perhaps?
[15:16] <dpm> pitti, seb128, wgrant, that's the regular flag we use to mark templates as exported in language packs. Anyone in the ubuntu-translations-coordinators can set it. Which packages are we talking about? I can check if the flag is set
[15:16] <wgrant> dpm, pitti: The flag is set now, at least on one of the templates. But I can't tell if it was set for the last langpack export.
[15:17] <seb128> dpm, does that work for universe packages?
[15:17] <wgrant> (except that I read the code, and it makes no sense that the template wouldn't be there if the flag was set)
[15:17] <pitti> or, if you want to keep it together, we need to unset ADTTMP/TMPFILE or chown them before the su
[15:17] <pitti> jibel: ^ WDYT?
[15:17] <dpm> wgrant, which package?
[15:17] <dpm> sorry, which template?
[15:17] <wgrant> dpm: https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-firefox-installer/+pots/desktop-kubuntu-firefox-installer/+admin
[15:17]  * pitti wishes we could just drop that ADTTMP/TMPFILE nonsense; it's creating nothing but trouble
[15:18] <dpm> wgrant, recently it's been me only setting that flag, so if it's set now, it certainly was set before the last export
[15:19] <dpm> seb128, it does, except for the issue mentioned in that bug
[15:19] <wgrant> Note that the last export was on March 22
[15:19] <wgrant> And that template was created on March 18
[15:19] <wgrant> Or later
[15:21] <jibel> pitti, I think unsetting TMPDIR before running the test is better than creating a fake test just to disable apport
[15:21] <doko> pitti, so ADTTMP/TMPFILE are always set?
[15:22] <doko> I don't like the faketest either
[15:22] <pitti> doko: yes, and they point to a directory owned by 'ubuntu', or 'root' if Restrictions: needs-root is set
[15:22] <pitti> ADTTMP certainly doesn't get in the way, but TMPFILE will
[15:23] <pitti> err, TMPDIR
[15:23] <doko> so chown -R $SUDO_USER should work?
[15:23] <pitti> yes
[15:23] <jibel> it does that's what was done for software-center IIRC
[15:24] <dpm> wgrant, I think we might be talking about different things. The latest export happened yesterday: https://translations.launchpad.net/ubuntu/raring/+language-packs
[15:24] <wgrant> Oh
[15:24] <wgrant> I thought I saw that one crash
[15:24] <wgrant> Apparently that was for another series
[15:26] <dpm> wgrant, I haven't checked if that export is ok, but in any case, there was another previous export last week, which is the one we're currently using in the language pack packages
[15:26] <wgrant> Yeah, that was quantal
[15:26] <wgrant> Oops
[15:26] <wgrant> ./mapping.txt:kubuntu-firefox-installer desktop_kubuntu-firefox-installer
[15:26] <wgrant> pitti: It's in mapping.txt
[15:31] <pitti> wgrant: hm, odd; did these appear very recently?
[15:31] <pitti> so, it should be okay in the next build
[15:32] <ev> bdmurray: I'm piecing together https://wiki.ubuntu.com/ErrorTracker/DailyTasks as a one stop shop for error tracker misbehaviour :)
[15:32] <ev> for what it's worth
[15:32] <wgrant> pitti: Nothing's changed here in a long time, so I don't think there's ever been a problem on our end.
[15:33] <bdmurray> ev: I saw, thanks
[15:33] <ev> cool
[15:36] <cjwatson> jodh: I notice that the filesystem event finishes before static-network-up starts
[15:40] <dpm> pitti, wgrant, I'm a bit confused by this issue. wgrant, you mean that the templates are present in the mapping.txt file of the latest full export (i.e. the one from yesterday), but pitti was mentioning on the bug report that the mapping.txt file of that export didn't list the templates?
[15:41] <pitti> dpm: right, I was wrong about that
[15:41] <doko> jibel, pitti : http://paste.ubuntu.com/5716277/
[15:41] <dpm> pitti, ah, gotcha, that makes it clear
[15:42] <pitti> doko: not sure whether we need to chang ADTTMP, but it can't hurt at least
[15:43] <pitti> 10 if [ -n "$SUDO_USER" ]; then
[15:43] <pitti> doko: ^ should that be $su_user ?
[15:43] <doko> no, don't want to change anything when running as nobody
[15:43] <pitti> ah, ok
[15:44] <doko> pitti, does every test case has its own TMPDIR?
[15:44] <pitti> yes
[15:52] <jibel> doko, also,  "stop apport 2>dev/null || true" otherwise the test will fail if apport is not running
[15:54] <cjwatson> jodh: I *think* I may see the general structure of what's going on here
[15:54] <cjwatson> jodh: This debugging should make it about as clear to you as it is to me so far, I think
init: conf_load_path_with_override: Loading configuration file /etc/init/rc-sysinit.conf
[15:54] <cjwatson> ...
init: conf_file_destroy: Destroyed unused job rc-sysinit
init: event_unblock: name: 'filesystem', new blockers: 3^
[15:55] <cjwatson> jodh: When we tear down the old job, we end up unreferencing and destroying the event operators it refers to, at least enough to cause them to decrement various event->blockers
[15:56] <cjwatson> jodh: So the 'filesystem' event ends up entering the finished state far too early because it's been wrongly unblocked
[16:00] <tvoss> slangasek, ping
[16:01] <slangasek> tvoss: otp pong
[16:08] <jodh> cjwatson: gotcha - that is indeed subtle. Could be an interesting one to fix too ;)
[16:10] <cjwatson> jodh: My feeling is that the nih_free in conf_file_destroy needs to be something more careful involving keeping references
[16:10] <cjwatson> jodh: But that also perhaps job_class_reconsider shouldn't replace a job that has events that are blocking some other event?  I'm not quite sure, I don't know the structures quite well enough
[16:10] <cjwatson> jodh: Is that enough to get you going for now though?
[16:11] <jodh> cjwatson: sure is - thanks!!
[17:48] <bdmurray> doko: could you have a look at bug 1084935?
[18:14] <infinity> BenC: New linux just landed, if you'd like to rebase -ppc.
[19:28] <BenC> infinity: ok, couple hours...
[19:31] <infinity> BenC: Cool.
[20:32] <doko> jtaylor,
[20:32] <doko> dpkg-source: info: local changes detected, the modified files are:
[20:32] <doko>  python-numpy-1.7.1/doc/source/conf.py
[20:32] <doko>  python-numpy-1.7.1/doc/sphinxext/tests/test_docscrape.py
[20:32] <doko> dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/python-numpy_1.7.1-1ubuntu1.diff.UwGgRh
[20:37] <jtaylor> doko: did you pop the patches before applying the debdiff?
[20:38] <jtaylor> also barry already sponsored it
[20:39] <barry> hmm. it built locally
[20:39] <barry> for me
[20:39] <jtaylor> it works if I pop the patches
[20:39] <jtaylor> if I leave it applied and then change series quilt gets confused
[20:47] <doko> ohh, if barry sponsored, fine
[21:31] <nemo> say. just a minor idea
[21:31] <nemo> if usb-creator-gtk is an ubuntu project. maybe you could have it check md5 sums for isos w/ standard names?
[21:32] <nemo> or have it return better error messages.  took me quite a while to figure out that "[Errno 5] Input/output error" was its way of saying the ISO was bad
[21:32] <nemo> (network here sucks - downloaded ISO 3 times, got 3 different checksums)
[22:18] <TheMuso> diwic: Ok thanks, that makes sense.
[23:00] <doko> tjaalton, ping
[23:05] <nemo> Oh. One more thing
[23:05] <nemo> Some people were irritated, but, 'grats to you on your new donation screen
[23:05] <nemo> frankly, I liked it and tossed some cash your way.  The voting thing was fun idea.
[23:05] <nemo> I guess it had just not been convenient enough or in my face enough to do it before ;)
[23:05] <BenC> infinity: upload away...
[23:06] <nemo> I don't care for the lil skull face after tho
[23:06] <nemo> (when I went to reattempt downloads due to failed ISO due to sucky network here)
[23:06] <nemo> was like.  seriously stupid page. don't you know I already gave you cash?
[23:13] <infinity> BenC: Cheers.