[07:38] <Keybuk> ion: I must get around to writing crazy zsh expansion for Upstart
[07:38] <Keybuk> e.g. start <tab> not completing anything already running ;)
[07:39] <ion> Yeah :-)
[07:41] <Keybuk> but first I should probably write more of Upstart
[13:46] <shan3> hi all!
[13:47] <shan3> I have read the getting started page http://upstart.ubuntu.com/getting-started.html but I have a question for which I can't seem to find an answer on the site.
[13:47] <shan3> Are there any special characteristics required for a script that is run by Upstart
[13:47] <shan3> ?
[13:49] <shan3> I have a 'traditional' service script that forks to the background and I tried many different methods inclusing using states... But I can't get it to start
[13:49] <shan3> *including
[13:50] <shan3> running the script from command line works fine
[20:00] <shan3> Hi all. Any idea why a simple job like this: http://pastebin.com/Q6mkJzzw doesn't work?
[20:05] <sadmac> shan3: looks like it would need the task keyword, since the script exits.
[20:06]  * shan3 google task keyword
[20:07] <sadmac> man 5 init is the docs
[20:08] <shan3> sadmac: what about using the 'service' option and having a pre-start script instead... ?
[20:09] <shan3> http://wiki.frugalware.org/index.php/Upstart_Job_HOWTO < says we can do that instead of script or exec
[20:11] <sadmac> shan3: oh, for what it looks like you want to do that's right
[20:12] <sadmac> shan3: except no service option if you're using the latest version
[20:13] <shan3> sadmac: hm... if I use pre-start script, upstart doesn't even recognize my job as a job...
[20:13] <sadmac> shan3: what version of upstart is this?
[20:14] <shan3> the one in Ubuntu 10.04 RC
[20:14] <shan3> 0.6.5
[20:14] <ion> A typo or invalid syntax somewhere?
[20:15] <shan3> let me try again using pre-start script without the service option...
[20:15] <shan3> that's about all I've been changing
[20:17] <sadmac> shan3: the service option is no longer supported
[20:17] <sadmac> shan3: its bad syntax
[20:20] <shan3> Hm... so then what is the right way to run a script that exits in a job?...
[20:21] <ion> Make it a pre-start/post-start script or make the job a task by using the ‘task’ stanza.
[20:22] <shan3> ion: Thanks... I'll have to read the latest docs... seems like I've been reading outdated ones and pulling my hair out.
[20:24] <ion> init(5) as sadmac said.
[20:25] <shan3> yup... got it.
[20:31] <LzrdKing> woah, it exists!
[20:31] <sadmac> LzrdKing: yes. welcome to the pocket dimension of xindu
[20:32] <LzrdKing> oh, i musty be on the worng place
[20:32] <LzrdKing> woah, typos galore!
[20:32] <LzrdKing> i must be in the wrong place*
[20:33] <LzrdKing> how can i use upstart to bring up my wireless as soon as wlan0 is visible to the kernel?
[20:33] <sadmac> LzrdKing: you need to have udev run initctl emit something so you get an event when that happens
[20:34] <LzrdKing> how do i get udev to do that?
[20:34] <sadmac> LzrdKing: ask in #udev :)
[20:34] <sadmac> LzrdKing: depending on your distro maybe something of the kind is already set up
[20:35] <Keybuk> SUBSYSTEM=="net", RUN+="/sbin/initctl emit ..."
[20:35] <LzrdKing> i don't think so, as much as i've tried, i can't get wlan0 up before a mountall happens, whch tries to mount nfs shares
[20:36] <sadmac> nfs + wireless + boot-essential = cry
[20:36] <LzrdKing> so i can have udev emit anything that the upstart sctips then looks for?
[20:36] <LzrdKing> scripts*
[20:36] <sadmac> LzrdKing: indeed.
[20:37] <Keybuk> if you have mountall, it sounds like you're running Ubuntu
[20:38] <LzrdKing> so if it emits "wirelessnetworkvisible" then the upstart script should have "start on wirelessnetworkvisible"?
[20:38] <LzrdKing> Keybuk: yes, karmic
[20:38] <Keybuk> then you will already have events from udev
[20:38] <Keybuk> e.g. net-device-added wlan0
[20:38] <Keybuk> which will already run "ifup wlan0" if you have wlan0 configured in /etc/network/interfaces
[20:39] <LzrdKing> i do, but that mountall comes along to early
[20:40] <LzrdKing> shouldn't udev emit that event before anything in rcS.d/ is run?
[20:40] <sadmac> LzrdKing: you may be able to add "and net-device-up wlan0" to mountall's start conditions. Maybe.
[20:41] <LzrdKing> i need the "and" for mutliple requirements?
[20:42] <sadmac> LzrdKing: yes, but the "and" has some quirks and surprises
[20:42] <LzrdKing> like what?
[20:44] <sadmac> LzrdKing: if you have a job that says start on starting foo and bar, foo will get stuck in the starting state until bar comes along, because its starting event won't get retired until that condition is met, even though its in another job.
[20:45] <LzrdKing> maybe i'll just take my nfs shares out of fstab and mount them manually in rc.local...
[20:45] <sadmac> LzrdKing: or make them noauto in fstab and mount them in rc.local
[20:47]  * sadmac counts the minutes until someone who barely speaks english and whom he's never seen before or will see again files a Fedora bug suggesting we update the Upstart package without articulating any particular need for it.
[20:48] <LzrdKing> new version?
[20:49] <Keybuk> yeah, nothing really important in it - just wanted to flush it out
[20:49] <Keybuk> main reason is that whatever gettext I used for 0.6.3+0.6.5 had files generated against the GPLv3 version of Bison
[20:49] <LzrdKing> sadmac: if i use noauto then mount -a won't mount it?
[20:50] <sadmac> LzrdKing: yes
[20:50] <LzrdKing> Keybuk: terrible
[20:51] <LzrdKing> sadmac: have you tired to get wireless+nfs up at boot time before?
[20:52] <sadmac> LzrdKing: no. I also don't use Ubuntu :) but I don't think the maintainers of any of those components are expecting to work with oneanother
[20:52] <LzrdKing> sadmac: you said it was "cry"
[20:52] <LzrdKing> so i thought you tried and failed miserably, as i am
[20:53] <sadmac> LzrdKing: I'm crying at the idea.
[20:54] <LzrdKing> it really shouldn;t be that hard, i mean, all i need to do to bring up wlan0 is "iwconfig wlan0 essid myESSID; dhclient wlano"
[20:54] <LzrdKing> oops, wlan0
[20:55] <Keybuk> LzrdKing: did you add it to /etc/network/interfaces ?
[20:55] <LzrdKing> Keybuk: yeah i did
[20:56] <Keybuk> that's all you should need to do
[20:56] <LzrdKing> it didn't seem to make any change
[20:56] <LzrdKing> plus i have the iwconfig/dhclient command isn a script, plus i installed wicd
[20:56] <LzrdKing> s/isn/in
[20:57] <LzrdKing> startup scripts need to be organized better
[20:57] <LzrdKing> so people can figure out whats going on
[20:57] <sadmac> Keybuk: what's the new codename from?
[21:00] <LzrdKing> rc#.d/ was easy to understand, upstart is hard
[21:10] <ion> rc#.d was full of race conditions and ugly workarounds that may or may not have worked.
[21:10] <LzrdKing> but i understood what was happening
[21:11] <LzrdKing> i will understand upstart, eventually
[21:11] <LzrdKing> messaging is wierd, things become so loosely connected now
[21:41] <JanC> in the past things weren't connected at all  ;)
[21:43] <LzrdKing> sure they were, program a called program b
[21:43] <LzrdKing> but that was it
[21:43] <Keybuk> yes, you knew that for a program to be started after networking was up, it had to be replaced with a number "higher than 40" in "runlevel 2"
[21:43] <Keybuk> in Ubuntu
[21:43] <Keybuk> but in Debian that had to be "higher than 35" in "runlevel S"
[21:43] <Keybuk> and in Fedora that had to be "any value" in "runlevel 3 or 5"
[21:43] <Keybuk> etc.
[21:44] <LzrdKing> but it was easy to look at the directory listings and link your script into an existing runlevel startup
[21:46] <JanC> I think there are some plans to make it possible to map what was started by what
[21:47] <LzrdKing> i just need to learn the new system, then i'll say, boy that sysv crap sure was backwards
[22:57] <shan3> Is it possible to use bash instead of sh for upstart jobs?
[23:19] <ion> exec /path/to/bash-script


[11:14] <ikonia> note we need to update the nvidia factoid,
 chris80: do you have any opinion whether i should be looking at nvidia or amd?
[11:41] <ikonia> lets see what happens
[11:41] <bazhang> I dont see how thats on topic, and he was warned repeatedly
[11:41] <ikonia> well, he wants to know which he should use
[11:42] <ikonia> he's been told nvidia twice and he keeps leading it to his cracked xbox, so lets see what happens this time
[11:42] <bazhang> ok
[15:51] <DJones> Troll detected:  Wang_Dickman> CAN I SELL UBUNTU LOCALLY? I SOLD 6 COPIES AND MADE 360$
[16:26] <IdleOne> selling ubuntu dvd's is fine. His nick is not.
[16:28] <DJones> It looked like the same person who was kicked/banned a couple of times yesterday with a similarly inappropriate nick
[16:30] <DJones> Yep, 55795 & others yesterday
[17:54] <genii> Hm. <mrtAkdeniz> My wireless mouse is not working on Ubuntu Gnome 13.04  and then: It was not working on Mint too, but If I start Xserver as root by writing su then startx, It was working ... I want to stay far away from that one.
[19:34] <Pici> genii: he did the same thing in offtopic which got him removed from there.
[19:34] <Pici> re: coffee stuffs
[19:34] <Pici> offtopic for ops
[19:35] <genii> Pici: I let him go on a while to vent :)
[19:52] <genii> Hm. "NSA_MONITOR<EMAIL_ADDRESS>has joined #kubuntu"
[19:56] <LjL> this screen is so white, i wonder how it's look if i looked at it through a prism
[20:02] <genii> Probably pretty trippy
[20:17] <LjL> genii: sorta kinda something like this i imagine http://www.flickr.com/photos/ljlbox/2944771543
[20:18] <genii> My eyes! They're burning!


[01:16] <dobey> infinity: oh. hope you're feeling better. are you still around?
[01:25] <infinity> dobey: Ish.
[01:28] <dobey> infinity: just uploaded a new ubuntuone-client for saucy-proposed, and about to do the same for precise-proposed, if you could accept them?
[01:36] <infinity> dobey: I will have a look, yeahp.
[01:37] <dobey> infinity: and precise-proposed uploaded too. thanks much. i'll test as soon as they're built in -proposed
[01:41] <infinity> dobey: Done and done.
[01:43] <dobey> thanks!
[01:58]  * dobey wonders how long it will take for them to show up in the archive
[02:18] <dobey> sigh, i wonder if it's virtualbox that makes setting the time so difficult, or what
[02:22] <infinity> dobey: "date -s ..."?
[02:23] <infinity> dobey: Preferably in the VM, not in the host, if you value your sanity.
[02:23] <dobey> sanity? what's that?
[02:24] <dobey> in saucy i can set the date ok from the system settings
[02:24] <dobey> but in the precise vm it keeps automatically changing back to the current date
[02:24] <dobey> no idea why
[02:25] <infinity> dobey: Some "use network time" tickbox being overexhuberant, perhaps?
[02:25] <infinity> dobey: But setting it from a terminal should do fine, I'd think.
[02:25] <dobey> maybe, but i unchecked it (you can't actually change the date with the radio button set to "automatic")
[02:26] <dobey> nope, date -s doesn't help
[02:27] <infinity> Your VM hates you...
[02:27] <dobey> it set it for a few seconds, but by the time i typed the command to start u1 and connect, it had already changed back :(
[02:27] <infinity> I'd suggest ntpd is running, but ntpd usually gives up if you're too far out of sync with reality.
[02:28] <dobey> ps doesn't show any ntpd
[02:28] <dobey> whee
[02:30] <dobey> and i unplugged the network and it still gets reset
[02:30] <dobey> so yeah, precise vm is hating me
[02:30] <infinity> I can't imagine what would be resetting it.
[02:31] <dobey> yeah, me either :(
[02:31] <infinity> If in doubt, blame g-s-d?
[02:31] <dobey> wfm
[02:31] <infinity> Though killing g-s-d wouldn't be so helpful if what you're testing needs it. :P
[02:32] <dobey> ok, so the notifications are still weird on precise (but i think tthat's a bigger bug in the code that we don't really have time to fix at this point)
[02:32] <infinity> I wouldn't be aboe blaming indicator-datetime, or similar, either.  But I'm just grasping at straws, without staring at the VM in question.
[02:32] <dobey> but the connecting post-june-1 fix is working right on precise
[02:32] <infinity> s/aboe/above/
[02:33] <infinity> dobey: If you're happy enough with the state of those packages, then, we'll just let 'em in.
[02:33] <infinity> dobey: I don't want to delay any longer unless you think you can fix the weird notification thing in short order.
[02:35] <dobey> infinity: i don't think we can fix it. i just now changed the bug to verification-done and added a comment to that effect. i think we should push the update out now
[02:36] <infinity> dobey: Alrighty.  Doing.
[02:37] <infinity> mdeslaur: Around?
[02:37] <dobey> infinity: thanks a lot for your help with this.
[02:37] <infinity> jdstrand: Or you?
[02:37] <infinity> Oh, wait, I think the security team might be on European time...
[02:39] <mdeslaur> infinity: what's up?
[02:39] <infinity> mdeslaur: Any qualms about me pushing the above ubuntuone-client update to precise-security as well, overwriting what you have in the pocket?
[02:40] <infinity> mdeslaur: I think it'd be monumentally confusing to the 2 people who run security-only without updates when the package explodes and stops working correctly on Jun 1. :)
[02:40] <mdeslaur> infinity: no qualms at all, go right ahead
[02:40] <infinity> mdeslaur: Ta.
[02:40] <mdeslaur> does it need to be rebuilt with only -security though?
[02:41] <infinity> Seems pretty unlikely, but maybe I should have double-checked before hitting enter.
[02:41]  * infinity quickly goes to look at deps.
[02:42] <infinity> mdeslaur: binary deps all looks safe.
[02:44] <mdeslaur> infinity: cool
[02:45] <dobey> hooray
[02:51] <infinity> mdeslaur: Speaking of things that aren't technically security updates but screw with people who run security-only, I wonder if we should chat about tzdata sometime.
[02:52] <mdeslaur> hrm, interesting
[02:52] <mdeslaur> yeah, I guess that could go into -security too
[02:52] <infinity> mdeslaur: I mean, the part where we've never had complaints either means no one actually runs security-only, or the people who do are all in regions with stable timezones. :)
[02:53] <infinity> mdeslaur: Cause you tend to notice pretty quickly when tzdata is wrong for you.
[02:53] <mdeslaur> I've always been really curious as to how many people actually do run -security only
[02:53] <infinity> Me too.  I'm not even sure how we'd go about mocking pseudo-metrics for that, let alone good ones.
[02:54] <infinity> Could start with maybe looking for desktop apps that are out of sync between security and updates and reporting crashes to errors.
[02:54] <mdeslaur> when someone enables unattended updates during the server image install, that's security only, right?
[02:54] <infinity> Not sure.
[02:54] <Logan_> is the implicit conversion to pointer failure really necessary on amd64? it only inevitably causes a problem on ia64, and Debian only checked on ia64 buildds (but we fail builds on amd64 as well)
[02:55] <infinity> Unattended-Upgrade::Allowed-Origins {
[02:55] <infinity>         "${distro_id}:${distro_codename}-security";
[02:55] <infinity> };
[02:55] <mdeslaur> hrm, interesting
[02:55] <infinity> mdeslaur: The default conffile comments out other pockets, so yeah, I guess.
[02:55] <infinity> /etc/apt/apt.conf.d/50unattended-upgrades
[02:55] <dobey> weird
[02:56] <mdeslaur> I always thought it would be used more by server users than desktop users
[02:56] <infinity> Logan_: Yes.
[02:56] <dobey> my server has backports and updates in the list when i do "apt-get update"
[02:56] <infinity> Logan_: It's actually worse on amd64 than ia64, in that it's a guaranteed runtime explosion on ia64, and it's nondeterministic "wheeee!" on amd64.
[02:56] <mdeslaur> dobey: when done manually, yes
[02:56] <Logan_> infinity: I see - but then why doesn't Debian do it?
[02:56] <mdeslaur> dobey: when done automatically by unattended-updates, no
[02:57] <infinity> Logan_: Plus, it's always a bug.  And a bad one.  Even on 32-bit arches, it usually points to a bad bug elsewhere (like an implicit declaration).
[02:57] <dobey> mdeslaur: oh, that's kind of weird
[02:57] <infinity> Logan_: Debian failed for it on ia64 because LaMont ran those buildds.  Guess who wrote the code that fails it on our buildds? :)
[02:57] <Logan_> I see :P
[02:58] <infinity> Logan_: Anyhow, I'm the one at "fault" for extending the check to all 64-bit arches, but with good reason.
[02:58] <infinity> Logan_: I'm tempted to extend the check to all implicit declarations as well, as they cause more interestingly subtle bugs.
[02:58] <Logan_> what's weird is that I just synced over your delta for jmagick because I didn't get any references to "implicitly" in my pbuilder log, but it happened on the build
[02:58] <Logan_> any idea why that's the case?
[02:58] <Logan_> *buildd
[03:00] <Logan_> I'll obviously reinstate your changes, but I don't get why I didn't get those warnings in my local build
[03:00] <infinity> Logan_: What arch was your local build on?
[03:00] <Logan_> amd64
[03:00] <infinity> Also, wow, this code is a mess.  I must have been very tempted to rewrite half of it last time I was in there.
[03:02] <Logan_> should I use sbuild instead or something? or would that not make a difference?
[03:03] <infinity> Logan_: I don't see why it would make a difference.  I'm doing a test build here.
[03:05] <Logan_> infinity: oh wait - is the line "Function `getByteArrayFieldValue' implicitly converted to pointer at magick_MagickImage.c:3454" injected into the log?
[03:05] <Logan_> because it occurs right beneath a warning in the buildd log
[03:05] <Logan_> and that's what I grepped for in my local build log
[03:05] <infinity> Ahh, yes, that's inserted. :)
[03:05] <Logan_> grrr :P
[03:05] <Logan_> rewriting history
[03:06]  * Logan_ begrudgingly reintroduces the delta
[03:07] <infinity> Logan_: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/view/head:/lpbuildd/check_implicit_pointer_functions.py
[03:07] <infinity> Logan_: That's responsible for the insertion.
[03:07] <Logan_> ah, I see
[03:08] <Logan_> I think I'll also forward your patch to Debian once I upload this, unless you want to
[03:08] <infinity> It's already there.
[03:08] <Logan_> tbh, it should be upstream
[03:08] <Logan_> oh
[03:08] <infinity> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727776
[03:09] <Logan_> alright, reupped with the patch
[03:10] <Logan_> thanks as always :P
[03:10] <infinity> Reading that build log just makes me cry.
[03:10] <infinity> How do people never actually check the output of their compilers?
[03:12] <Logan_> I like all of the deprecated functions
[03:12] <infinity> That's to be expected, as the thing they're building against moves on...
[03:12] <infinity> But all the type mismatches have probably been there since day 1.
[03:12] <infinity> I don't think that's an underlying API moving.
[03:12] <infinity> That's just lazy programming.
[03:13] <Logan_> erm
[03:13] <Logan_> one of the functions they use, DestroyImages, has been deprecated in ImageMagick since 2002
[03:13] <infinity> Hahahaha.
[03:13] <infinity> Okay, some lazy there too then. :)
[03:17] <infinity> If we turned on -Wall -Wextra -Werror, we could probably reduce the archive size by 90%.
[03:17] <infinity> So tempting.
[03:18] <Logan_> we're not supposed to babysit upstream :P
[03:20] <Logan_> as nice as it would be to remove warnings from all packages in the archive, it ain't gonna happen with our limited devs
[03:20] <infinity> I know.  It's a pipe dream I'll never realize.
[03:21] <infinity> So, I'll go back to nursing my flu instead.
[05:22] <pitti> Good morning
[05:49] <michagogo> dobey, infinity: Yeah, Virtualbox does mess with the clock
[05:49] <michagogo> I think it keeps the VM's hardware clock synced with the host or something
[05:50] <michagogo> Which is annoying if you need to mess with the clock inside the VM
[05:50] <michagogo> But I think there's a way to turn it off -- if not in the GUI, then with vboxmanage
[05:50] <infinity> michagogo: That's completely broken behaviour...
[05:50] <infinity> Of course, the best way to avoid it is to use kvm or Xen. :P
[05:50] <michagogo> Heh, starting to google for "virtualbox disable..." first suggestion is "time sync"
[05:55] <RAOF> infinity: You'll be in Malta next week, right?
[05:59] <infinity> RAOF: Aye.
[05:59] <infinity> siretart: I'm rejecting the libav binaries from the queue, so we don't half-start the transition on 4/6 arches.
[05:59] <infinity> siretart: If you need help figure out the arm64/ppc64el build failures (in both cases, it looks like perhaps bad assumptions about the compatibility of vector assembly), ask.
[06:01] <RAOF> infinity: Rad. It might be time to get to that AA training.
[06:03] <infinity> RAOF: Yeah.  I'm trying to get arges to be a limited-scope AA just to be able to back me up for kernel SRU stuff (which requires AA because reasons), so maybe the three of us should spend some quality time together.
[06:05] <slangasek> cjwatson, xnox: I got a ucf prompt on upgrade from trusty->utopic for /etc/kernel-img.conf.  Does d-i or ubiquity set this up for us on install, or was this my own doing?
[06:06] <infinity> slangasek: d-i creates it, I believe, but what on earth thinks it owns it all of a sudden?
[06:06] <slangasek> infinity: "kernel-common", because Manoj woke up
[06:06] <RAOF> And by “requires AA because reasons” what you mean is “needs to be a member of ~ubuntu-archive because LP permissions”, as *I'm* a member of ~ubuntu-archive for the same reasons.
[06:06] <infinity> slangasek: Ah-ha.  So, yeah, it was completely unowned in Ubuntu until then.
[06:07] <infinity> RAOF: Yeah, that. ;)
[06:07] <infinity> RAOF: But if we have people we "shouldn't" have in ~ubuntu-archive, I also want to make sure they're prepared to flex those permissions sanely when needed.
[06:07] <infinity> (Or to remove them)
[06:08] <infinity> (Or to get notes from their mothers promising they won't touch anything)
[06:08] <RAOF> That's what I've done :)
[06:08] <RAOF> People ask for things not-SRU-related, and I say “sorry, no can do” ☺
[06:08] <infinity> slangasek: Did kernel-common always "own" it, and we only just recently pulled it in as a dep of something else?
[06:08] <infinity> slangasek: I don't have it installed here...
[06:09] <slangasek> infinity: no, from the changelog kernel-common is a new package; I had kernel-package installed for $reasons, and on upgrade it pulled in the new kernel-common
[06:09] <infinity> slangasek: Indeed, new in sid and utopic.
[06:10] <infinity> slangasek: So, that's entirely Manoj's fail.  He can't just take over a config file like that.  Go forth and smack him.
[06:10] <slangasek> infinity: so I think we want to fix kernel-common to /actually/ install a file that matches what the installer does, or else launch the new package out of an airlock if we don't want it in utopic
[06:10] <slangasek> infinity: is this a bug also in Debian?
[06:10] <infinity> slangasek: Yeahp.
[06:10] <slangasek> infinity: you want to do the smacking? :)
[06:10] <infinity> slangasek: kernel-img.conf has the same semantics there, both its use in kernel postsints, and its unowned (until now) status.
[06:10] <infinity> slangasek: You discovered it, smack on.
[06:11] <slangasek> infinity: you seem to have a better handle on the details, surely the smack would be more effective from you :)
[06:11] <infinity> slangasek: I tried.  Can't tab complete his name in #debian-devel.  I give up.
[06:18] <slangasek> infinity: relatedly, why do we still create /vmlinuz and /initrd.img links by default?  That's silly
[06:19] <infinity> slangasek: You mean why do we not default to link_in_boot=yes, or why have the links at all?
[06:20] <slangasek> infinity: if we're going to have them at all, they should be in /boot, not somewhere that may be a separate filesystem; and the bootloader no longer uses them on x86 so we should probably not have them at all
[06:20] <infinity> slangasek: Except for the 7 people who still use lilo, yeah, no one else uses them, I imagine.
[06:21] <infinity> slangasek: But absolutely agreed that if we have them, they should be in boot (and I always alter my config to do so).
[06:21] <slangasek> me too
[06:22] <infinity> Anyhow, looks like the kernel-common thing was an overzealous reply to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626216
[06:22] <infinity> I'm thinking just putting the manpage in linux-base and keeping the rest alone would have been saner. :P
[06:22] <StevenK> I have do_symlinks = no, and yet /vmlinuz is a symlink to latest kernel
[06:23] <infinity> StevenK: That's because it's do_symlink
[06:23] <StevenK> Hah
[06:23] <StevenK> I also don't have a kernel-img.conf manual page, which is helpful
[06:24] <infinity> Oh, hrm.  No.  It's do_symlink in the code, but do_symlinks in the config file.  Whee.
[06:24] <StevenK> Hahaha
[06:24] <StevenK> infinity: Is this where I say "You're welcome." and back away slowly? :-P
[06:56] <LocutusOfBorg1> Hi, can I ask somebody of the buildd team to retry a build failed?
[06:56] <LocutusOfBorg1> https://launchpad.net/ubuntu/+source/wxwidgets3.0
[06:56] <LocutusOfBorg1> https://launchpad.net/ubuntu/+source/wxwidgets3.0/3.0.0-3/+build/6030586
[06:57] <LocutusOfBorg1> don't know, "compiler segmentation fault" doko_ do you have any idea?
[06:57] <LocutusOfBorg1> maybe just a retry is enough
[07:09] <infinity> LocutusOfBorg1: Retried, but I bet it fails again.
[07:10] <LocutusOfBorg1> thanks infinity I hope not :p
[07:11] <LocutusOfBorg1> I would like to upload some packages that use wx3.0 on debian
[07:12] <LocutusOfBorg1> I don't want to see them in proposed until somebody retries/processes them, and I need at least the wx -3 release
[07:12] <LocutusOfBorg1> because of the new package
[07:19] <infinity> pitti: Your patches to do rebuilds with dpkg-buildpackage for linux/glibc fail because there's no fakeroot.  That needs to be in the deps.
[07:19]  * infinity wonders if this is worth killing his sid build to fix...
[07:23] <apw> infinity, pitti, yeah the rebuild fixes for linux fail for lack of fakeroot as well
[07:23] <infinity> apw: Yeah, that's where I noticed the bug, and am now fixing it in glibc. ;)
[07:24] <apw> infinity, so ... why isn't that build-essential
[07:24] <apw> ie ... already installed
[07:24] <infinity> apw: Because it's not.  gain-root is buildd-specific.
[07:24] <infinity> apw: http://paste.ubuntu.com/7504510/
[07:24] <infinity> apw: That's what I'm applying to glibc, something similar should do for the kernel.
[07:25] <LocutusOfBorg1> :( g++: internal compiler error: Segmentation fault (program cc1plus)
[07:25] <LocutusOfBorg1> Please submit a full bug report,
[07:25] <apw> infinity, oh, i see ... unexpected but ok ... will get that applied to the kernel, not sure i want to upload for it though, uggg
[07:25] <infinity> LocutusOfBorg1: File a bug on gcc-4.8 and poke doko about it.
[07:25] <infinity> apw: Don't bother uploading for it, just queue it up.
[07:26] <apw> infinity, also is there anything i can _test_ these changes on do you know
[07:26] <infinity> apw: I'll just be naughty and ignore the -2.6 tests, if the other tests pass.
[07:26] <apw> infinity, thanks :)
[07:26] <infinity> apw: There's a magic wiki page somewhere about how to do adt at home.  I always lose it...
[07:27] <infinity> apw: http://packaging.ubuntu.com/html/auto-pkg-test.html
[07:27] <apw> infinity, also does the error line in p-m make sense to you, the version it reports for linux
[07:27] <infinity> apw: The version there is completely bogus, yes.
[07:27] <infinity> jibel: What's up with that?
[07:28] <apw> jibel, http://paste.ubuntu.com/7504521/ is what it was saying
[07:29] <apw> jibel, everything is right there in the sense there is a regression, but it is not in that version of linux
[07:30] <LocutusOfBorg1> ok wilco
[07:31] <LocutusOfBorg1> does anybody knows why cppcheck is still in proposed queue? https://launchpad.net/ubuntu/+source/cppcheck
[07:32] <infinity> LocutusOfBorg1: Causes two packages to become uninstallable.
[07:33] <infinity> Or, rather, the tinyxml2 transition does.
[07:33] <infinity> Why is there a library in those metapackages? :/
[07:34]  * infinity fixes...
[07:37] <LocutusOfBorg1> thanks :)
[07:37] <LocutusOfBorg1> doko_, ----> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1322485
[07:42] <jibel> apw, infinity looking
[07:45] <infinity> jibel: It's not actually causing a problem currently, but the reporting having the wrong version is definitely confusing. :P
[07:48] <jibel> infinity, right, and in the logs of britney it's the correct version "Collected autopkgtest status for linux_3.15.0-2.6/linux_3.15.0-2.6: FAIL" I'll investigate further after the sprint today
[08:21] <zyga> hey
[08:22] <zyga> mvo: running update-manager on utopic today I've noticed that checkboxes next to package names are cropped (about 30% on the left)
[08:26] <mvo> zyga: I can reproduce this, thanks! this smells like iz gtk bug because I don't think we changed update-manager in utopc much. just a internal change fo the meta-index stuff, nothing in the UI
[08:27] <zyga> mvo: yeah, I suspect that as well
[08:27] <zyga> mvo: want a bug report for that?
[08:27]  * zyga wonders how to file that bug ;)
[08:27] <zyga> if I use ubuntu-bug it will say packages are outdated
[08:28] <mvo> zyga: lets discuss in malta, then I can nudge seb128 diretly to fix it :P
[08:28] <zyga> if I update I cannot show the bug ;0
[08:28] <mvo> zyga: hihi
[08:28] <zyga> heh, sure :)
[08:28] <zyga> mvo: I'm not in malta btw
[08:28] <zyga> mvo: are you guys still there?
[08:28] <mvo> zyga: aha, ok. I will fly there sunday
[08:28] <zyga> oh, I heard some folks are there for a week or so
[08:28] <zyga> nice place to sprint!
[08:29] <mvo> zyga: I never went there, I'm curious about it
[08:29] <infinity> mvo: 'iz gtk bug'... Haven't seen that in a while. :)
[08:29] <Laney> I don't see that problem btw and gtk hasn't really changed in utopic yet
[08:30] <mvo> infinity: soon it will be "iz qt bug" :P
[08:30] <mvo> Laney: oh? hm, hm
[08:31] <Laney> well, unless I don't know what I'm looking for :)
[08:32] <Laney> it looks like http://ubuntuone.com/0ZlmWracPK89WzWSAUMAdf
[08:33] <mvo> Laney: the gtk treeview  paints the "triangles" wrong and cuts parts of the text. once a expander is clicked (or theme is changed) it is ok again. simple resize is not sufficient
[08:38] <mvo> Laney: http://ctrlv.in/335583
[08:40] <infinity> Laney: Getting the most out of that service before June 1? :P
[08:41] <jtaylor> if a package does not work at all as it does not support the software version in trusty, but a new upstream version does, can one SRU the new upstream?
[08:42] <jtaylor> (subversion 1.8 and eclipse subversion plugin are the packages in question)
[08:42] <infinity> jtaylor: If that's literally the only way to fix it, perhaps.
[08:42] <Laney> infinity: Old habits die hard :P
[08:42] <infinity> jtaylor: I assume it's the plugin you're talking about, not updating SVN itself?
[08:43] <xnox> infinity: tinyxml library is used by gallery-app click.
[08:43] <jtaylor> yes
[08:43] <jtaylor> technically its a java library the plugin uses
[08:43] <infinity> jtaylor: How scary is the delta, and can the necessary bits be backported?
[08:43] <jtaylor> didn't look
[08:43] <jtaylor> I'm wondering if can safe looking as there is zero regression potential
[08:43] <jtaylor> it can't get worse than does not work at all
[08:44] <infinity> xnox: Yeah, I saw the note in the seeds when I fixed it.  Gross that we're seeding libraries due to underrepresented (or unrepresentable) deps.
[08:44] <xnox> infinity: hence it's in the touch seed, i've filed bug to either get tinyxml into the click itself, during click build. or move from tinyxml to qt.
[08:44] <xnox> infinity: cause camera-app click to longer depends on tinyxml.
[08:44] <infinity> jtaylor: Yeah, that's a pretty valid argument, I'd still like to see the proposed diff. :)
[08:45] <jtaylor> svnclientadapter is the source
[08:46] <infinity> You'd think 1.8 would work with 1.8...
[08:46] <infinity> Silly people.
[08:47] <jtaylor> I don't think the versions are coupled
[08:47] <jtaylor> utopic has 1.10
[08:47] <jtaylor> I'll check if a rebuild works first
[08:47] <infinity> jtaylor: Is it svnclientadapter or libsvn-java that's the problem?
[08:48] <jtaylor> (installing utopic in trusty works fine)
[08:48] <jtaylor> the adapter
[08:48] <jtaylor> its got a version == 1.7 check in it
[08:51] <infinity> Are you getting this string? "Incompatible JavaHL library loaded.  Subversion 1.7.x required."
[08:51] <jtaylor> yes
[08:51] <jtaylor> the diff to utopic is not large
[08:51] <jtaylor> but I don't see time well spent in backporting
[08:51] <infinity> Theoretically, the package had a patch for that...
[08:52] <infinity> Oh, no it didn't, I can't read.
[08:53] <jtaylor> I'll file a bug that the package should have a stricter svn dependency
[08:53] <infinity> But that one delta to src/javahl/org/tigris/subversion/svnclientadapter/javahl/JhlClientAdapterFactory.java might fix it.
[08:53] <jtaylor> yes, but is it really worthwhile testing if that is enough?
[08:53] <pitti> infinity, apw: argh, sorry about that; thanks
[08:54] <jtaylor> upstream tested utopic with 1.8
[08:54] <jtaylor> so we should use that for trusty
[08:54] <pitti> apw: right, I don't think you need to upload just for that -- new kernels come often enough anyway? :-)
[08:54] <jtaylor> instead of trying to do a partial backport
[08:54] <infinity> pitti: Should this be the right fix? http://anonscm.debian.org/viewvc/pkg-glibc?view=revision&revision=6105
[08:55] <infinity> pitti: Identical commit was made to the kernel.
[08:55] <infinity> jtaylor: Sure, bumping the version might be the saner thing to do, just want to explore options.
[08:55] <infinity> jtaylor: It's certainly not an enormously scary diff.
[08:56] <pitti> apw: BTW, http://people.canonical.com/~pitti/tmp/linux-autopkgtest/ are the updated tests for linux-exynos5 (now including fakeroot)
[08:56] <pitti> apw: that also restricts the test to armhf, to avoid a failure on x86
[08:56] <pitti> infinity: looks good; -rfakeroot should be the default these days though?
[08:57] <infinity> pitti: It is, but if we're explicitly depending on a specific gainroot, I feel we should also explicitly call it.
[08:57] <pitti> *nod*
[08:58] <infinity> pitti: Why the need to restrict tests to armhf when the source only produces armhf binaries?   That seems like a test infra issue, not something that should be literring tests.
[08:58] <infinity> pitti: It makes exactly zero sense to run tests on an arch the package doesn't build for.
[08:59] <pitti> ah, I guess we could apply some debian/control parsing magic to find that out, yes
[08:59] <infinity> pitti: Or just read the .dsc
[08:59] <infinity> pitti: Oh, but you only work with unpacked trees?
[09:00] <infinity> Anyhow, that package is also buggy and claims to build arch:all packages that it can't possibly.
[09:00] <pitti> infinity: tree, .dsc, or (as in production) apt-get source
[09:00] <infinity> I fixed that in linux-ppc long ago, I guess the stupid carried over. :P
[09:00] <pitti> so debian/control it is
[09:00] <infinity> pitti: Kay, apt-get source gets you a .dsc, which is much easier to parse than control in this case.
[09:00] <infinity> But meh.
[09:01] <infinity> First, control needs to be fixed to stop pretending it builds things it doesn't.
[09:01] <infinity> apw: Where is the exynos5 git?
[09:01] <cjwatson> xnox: does the click package in question actually link against tinyxml directly, or is it perhaps via libmediainfo?
[09:01] <pitti> well, needs to work for anything, so debian/control it is; but the parsing isn't the problem really, it's figuring out from the Architecture: fields whether or not this applies
[09:01] <cjwatson> xnox: (compare gallery-app.deb)
[09:01] <apw> infinity, now why did i need to know that already this week
[09:02] <infinity> pitti: Sure.  In this case, you'd (rightly) guess wrong, I think, since there are arch:all debs, but there shouldn't be.
[09:02] <infinity> Oh, wait, the git is right there in the control.  I wonder if it's right.
[09:03] <xnox> cjwatson: actually, i think you are right. I'll test that out.
[09:03] <apw> infinity, i'd assume it is git://kernel.ubuntu.com/hwe/ubuntu-trusty-meta-exynos5.git
[09:03] <apw> infinity, i'd assume it is git://kernel.ubuntu.com/hwe/ubuntu-trusty-exynos5.git
[09:03] <infinity> apw: Yeah, that's what I'm cloning right now.
[09:03] <infinity> apw: Do you have write access to that, or do I need to bug ike with a patch?
[09:04] <apw> i should have, but will check
[09:04] <apw> infinity, that repo is _ahead_ of the archive
[09:04] <infinity> apw: That seems reasonable...
[09:05] <infinity> zinc needs a go-faster button.
[09:06] <apw> i do have write access to it indeed, though this out of sync fun makes life trixy
[09:08] <cjwatson> xnox: objdump -p <ELF object> | grep NEEDED  should show it
[09:09] <xnox> cjwatson: right. it has NEEDED libmediainfo.so.0, and no mentions of tinyxml.
[09:10] <xnox> cjwatson: so infinity's seed change can go it & unblock that transition.
[09:10] <infinity> xnox: It's already in...
[09:11] <infinity> final: cppcheck,libmediainfo,tinyxml2,ubuntu-touch-meta
[09:11] <infinity> SUCCESS (26/0)
[09:11] <xnox> i wonder if i should be subscribed to -changes mailing list =)
[09:11] <infinity> I had to do that update by hand, though.  Turns out ./update doesn't work so well when the thing you're seeding only exists in proposed...
[09:11] <infinity> Quite annoying.
[09:22] <cjwatson> it sounds like the correct seed change (given the intent) would actually have been to seed libmediainfo0 directly.
[09:25] <infinity> Perhaps, yes.  I was just following the ABI change, this was before anyone did analysis into the why.
[09:25] <infinity> libmediainfo0 appears to already be there anyway.
[09:26] <infinity> So libtinyxml and libzen could both go away from the seed, I'd think.
[09:27] <infinity> But I'll leave that to someone who knows more about this stack.
[09:28] <infinity> pitti: So, the bug where exynos5 claims to build packages it doesn't will be fixed in the next upload, at which point a parsing of debian/control or .dsc will return nothing but armhf.
[09:28] <infinity> pitti: Which, to me, seems much saner than arch-restricting the test in the source, but YMMV.
[09:33] <infinity> pitti: OTOH, I'm not sure there's value in that test in that source anyway.  The point of the glibc/linux/binutils/gcc rebuilt test circle is just to make sure no part of the toolchain breaks another part.  I'm not sure there's much extra value in making sure every out-of-tree kernel builds.
[09:35] <cjwatson> hallyn: So I belatedly looked through your log from last night.  Your problem is that your preseed file isn't being read at all.  You either need to add file-preseed to your image (build/pkg-lists/netboot/common, probably), or (perhaps easier) given that you're embedding the preseed file in the initrd anyway, just embed it specifically as "/preseed.cfg", at which point it will be read automatically and you can drop the file= boot ...
[09:35] <cjwatson> ... parameter.
[09:36] <cjwatson> (We should perhaps add file-preseed to netboot images at some point, since it's in Debian's)
[11:15] <siretart> infinity: yes, I could really use some help on those two ftbfs. for arm64, I guess it would be a matter of identifying the upstream commits in master that need to be backported. Please tell me and I see to include them for 10.2
[11:15] <siretart> infinity: for ppc64, I have no idea what this is supposed to mean, nor what could be causing it: /usr/bin/ld: libavcodec/libavcodec.a(fft_altivec_s.o): ABI version 1 is not compatible with ABI version 2 output
[11:16] <infinity> siretart: It means it's trying to link a big-endian and little-endian object together.
[11:16] <infinity> siretart: Which probably means the Altivec bits are endian-specific.
[11:16] <siretart> I guess we could disable altivec on ppc64 and neon on arm64
[11:16] <infinity> siretart: Which should be fixed, but the easiest solution would be to disable altivec on ppc64el.
[11:17] <siretart> do we have PPA where I could do the testbuilds, or can you take care of that?
[11:17] <infinity> siretart: And I haven't looked at the neon code in question, but it's probably similarly buggy in assuming neon == armv7t2 or some such.
[11:17] <infinity> siretart: I can do some test builds for you, though possibly not right this instant.
[11:18] <siretart> no problem, take your time
[11:18] <siretart> if we can push this transition before the beta, that'd be great
[11:18] <infinity> siretart: That seems like a pretty doable goal.
[11:19] <siretart> while the transition is not fully over, libav reached testing yesterday, and going with libav9 is imo a no-go for utopic
[11:19] <infinity> siretart: So, with libav9, was it using altivec on ppc64el and neon on armv8?
[11:19] <infinity> siretart: If so, we should perhaps figure out what broke in each case.
[11:19] <infinity> siretart: But I'd suspect it never was before, and now it's detecting "correctly", which happens to be incorrectly for the code in question.
[11:20] <siretart> that's entirely possible
[11:21] <siretart> if you need help, you might want to talk to jannau on #libav-devel@freenode, he was doing most of the aarch64 work lately
[11:21] <infinity> siretart: Well, I'd happily just turn off both SIMD options and sort it out later, my only concern is that fixing it later might change the ABI.
[11:22] <siretart> --disable-neon in debian/confflags should do the trick then
[11:23] <siretart> in that case they will use the plain C version
[11:23] <siretart> I don't have ABI concerns here
[11:23] <infinity> siretart: You don't have ABI concerns because you don't care if it breaks, or because you're positive the alternate SIMD implementations are opaquely hidden behind a stable ABI? :)
[11:25] <xnox> infinity: cjwatson: should cross-pkg-config, allow cross-compiling against non-multiarched libraries?
[11:26] <cjwatson> Err.  I'd be inclined to say probably, since the worst it can do is make errors more confusing
[11:27] <xnox> cjwatson: ack, and it would unblock a lot of cross-compilation queries i'm getting in #ubuntu-unity, for leaf -dev packages that are not multiarched yet.
[11:27] <cjwatson> I don't think it's vital, since there are other fixes possible, but it probably smooths the path
[11:27] <infinity> How is it currently preventing it?
[11:28] <xnox> infinity: commented out /usr/lib/pkgconfig from PKG_CONFIG_LIBDIR in /usr/share/pkg-config-crosswrapper
[11:28] <Laney> It says "  # If you want to allow use of un-multiarched -dev packages for crossing
[11:28] <Laney>   # (at the risk of finding build-arch stuff you didn't want, if not in a clean chroot)
[11:29] <Laney>   # Uncomment the next line:
[11:29] <Laney> "
[11:29] <cjwatson> My opinion on the spur of the moment on IRC doesn't necessarily override reasoned argument that you might find in the history, of course
[11:30] <infinity> xnox: Hrm.  Perhaps changing that to be keyed off an environment variable instead of encouraging people to edit the script? :P
[11:31] <xnox> infinity: by default, it is keyed off environment.
[11:31] <xnox> cjwatson: Laney: infinity: i'm thinking this might be a simple regression, cause package was forced synced.
[11:31] <infinity> xnox: I can absolutely understand the reasoning.  The errors would be confusing to the "average" person if they had wrong-arch libs found because of that.
[11:32] <infinity> xnox: Err, no, I mean that particular bit keyed off environment, not asking people to set the entire PKG_CONFIG_LIBDIR themselves.
[11:32] <xnox> Well, previous edition of pkg-config-wrapper was a two-liner:
[11:32] <xnox> triplet=`basename $0 | sed -e 's:-pkg-config::'`
[11:32] <xnox> PKG_CONFIG_PATH=/usr/lib/${triplet}/pkgconfig:/usr/${triplet}/lib/pkgconfig pkg-config $@
[11:33] <infinity> xnox: So, that was buggy in that it missed /usr/share, and it also missed the directory you're talking about.
[11:33]  * xnox ponders what are the differences between PKG_CONFIG_LIBDIR & PKG_CONFIG_PATH
[11:34] <xnox> infinity: we used to prepend multiarch paths, now we replace all paths with multiarch-only without original.
[11:34] <xnox> which is regressing cross-buildability of a lot of touch stuff in ubuntu.
[11:35] <infinity> xnox: That's not what your paste implied.
[11:35] <Laney> I've already eaten this change for a few libraries, but letting people opt back in might be a good idea
[11:35] <infinity> xnox: Anyhow, if we were including /usr/lib/pkgconfig before, and no one was complaining about it being confusing, go ahead and uncomment that line.  If you're positive that's how it used to work.  Your paste certainly doesn't imply what you said, though.
[11:36] <infinity> Oh, I see.
[11:37] <infinity> PKG_CONFIG_PATH behaves differently.
[11:37] <infinity> Kay.
[11:38] <infinity> xnox: Yeah, possibly just the path of least reistance to uncomment that line in Ubuntu, since that was the previous status quo, if no one was complaining about the occasional breakage.
[11:38] <infinity> Curiously, the old way we did it would have never worked when crossing to i386.  Obviously not something many people do.
[11:44] <siretart> infinity: we use linker scripts to hide internal symbols. applications have (or at least should not) no way to access those internals directly
[11:46] <infinity> siretart: Some quick symbol dumps certainly look to agree with you.  So, yeah, if you want to just disable neon on arm64 and altivec on ppc64el, that would get you over the hump for now, though it would be really good to make sure we revisit both.
[11:51] <siretart> absolutely, we should do that. In terms of priority, transitioning the archive seems more important and time-critical to me at this point, though
[11:55] <siretart> infinity: if you have a look at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=debian/confflags, disabling neon for arm64 and altivec on powerpc should be straight forward, if you know what to look for (I would need a porter machine to look up what environment variables to test for)
[12:00] <infinity> siretart: Kay.  I'll try to have a look at that after I've slept a bit.
[12:00] <siretart> infinity: Thanks!
[12:01] <ahasenack> hi, anyone know why the systemd-logind crash isn't fixed yet in trusty? It happens on every login since the release, seems very high priority
[12:12] <mdeslaur> ahasenack: what crash is that? do you have a bug number?
[12:12] <ahasenack> mdeslaur: just a crash report, that I upload everytime, but apport doesn't tell me what it did with it
[12:12] <ahasenack> -rw-r-----  1 root whoopsie 145K Mai 23 09:00 _lib_systemd_systemd-logind.0.crash
[12:12] <ahasenack> -rw-r--r--  1 root whoopsie    0 Mai 23 09:00 _lib_systemd_systemd-logind.0.upload
[12:13] <ahasenack> well, I don't upload it everytime anymore, got tired of that :)
[12:13] <ahasenack> but did upload it today
[12:16] <mdeslaur> ahasenack: I don't see it being reported on errors.ubuntu.com by anyone, sorry
[12:17] <mdeslaur> ahasenack: perhaps file an actual bug about it? does it happen in your guest account too6
[12:17] <ahasenack> it was a fresh install
[12:17] <ahasenack> but haven't tried the guest account
[12:18] <ahasenack> I suspect most people suspend/resume
[12:18] <ahasenack> it happens after a cold start, first login
[12:19] <mdeslaur> ahasenack: I definitely haven't seen that, and there aren't any errors being reported about that
[12:19] <mdeslaur> ahasenack: so please file a bug
[12:19] <ahasenack> ok
[12:19] <ahasenack> mdeslaur: do you know where my crash report went?
[12:20] <ahasenack> I've got colleages who also tell me they clicked the report button in the crash dialog box dozens of times
[12:22] <mdeslaur> ahasenack: is this it? bug 1309025
[12:23] <ahasenack> mdeslaur: could be, let me look at my stacktrace from the crash file
[12:23] <xnox> ahasenack: do you have cgroups-lite installed?
[12:24] <ahasenack> xnox: yes
[12:24] <xnox> ahasenack: uninstall it & reboot. check if that fixes it for you.
[12:25] <xnox> ahasenack: you want cgmanager installed at the same time (if not otherwise installed)
[12:25] <ahasenack> xnox: isn't that needed by lxc? cgroups-lite?
[12:25] <ahasenack> Title: systemd-logind assert failure: cgmanager-client.c:4546: Assertion failed in cgmanager_get_value_sync: proxy != NULL
[12:25] <xnox> ahasenack: no.
[12:25] <ahasenack> that's the title from my crash report
[12:26] <ahasenack> so yeah, looks like it's the same bug
[12:26] <xnox> ahasenack: although i have cgroup-lite installed and everything works fine....
[12:26] <xnox> hm...
[12:26] <ahasenack> xnox: cgmanager is installed too already
[12:27] <mdeslaur> xnox: I also have cgroup-lite installed
[12:27] <ahasenack> xnox: can't remove cgroup-lite:
[12:27] <ahasenack> The following packages will be REMOVED:
[12:27] <ahasenack>   cgroup-lite* libvirt-bin*
[12:27] <xnox> mdeslaur: hm, why does libvirt-bin & utah still use cgroup-lite?
[12:27] <xnox> hallyn: jibel: can libvirt-bin & utah switch to use cgmanager instead of cgroup-lite
[12:27] <xnox> ?
[12:37] <lamont`> infinity: actually, dannf wrote the code to fail implicit-conversions... I just brought it over to ubuntu, and yes, it's a far worse (though less frequent ant therefore a total surprise in debugging) on amd64
[12:39] <marga> infinity, ping? We've added more info to the weird libx32 bug (https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605)
[12:40] <marga> infinity, we believe it's an issue related to auditd being enabled, and that it's the kernel who's at fault.
[13:09] <marga> Uhm, seems infinity is sick and away... Is there anybody around here knowledgeable on both kernel issues and auditd that could give a hand?
[13:15] <yoh> Hi guys, I wondered if there any recipe somewhere to replicate existing PPA environment locally? in particular to the given version of kernel.  PPA build (on 12.04) fails in a unique fashion and we need to troubleshoot it.
[13:20] <geser> marga: even infinity sleeps now and then
[13:21] <marga> geser, sure, I thought he was in more or less my timezone, but I might be wrong.
[13:22] <ScottK> He did say he was sick yesterday.
[13:24] <marga> His away message says so.
[13:25] <geser> hmm, ok, he was active up till around 90 min ago and his last words were "after I've slept a bit."
[13:25] <marga> Oh, ok.
[13:25] <marga> geser, thanks for the info.
[13:34] <leex> hi, my do-release-upgrade segfaults with this error message: http://paste.ubuntu.com/7505633/ while trying to upgrade 13.04 to 13.10 does anyone have an idea on how to fix it?
[13:40] <ara> stgraber, salut! qt-base has been in the trusty unapproved queue for quite a bit of time now (https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=)
[13:40] <ara> stgraber, and it will help solve an important bug (https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1307701)
[13:40] <ara> stgraber, as SRU team member, could you please have a look, please?
[13:42] <TJ-> leex: It suggests there is an illegal UTF8 character in one of the existing /etc/apt/sources.list.d/* files
[13:44] <leex> TJ-: damn I had an .un~ file in there :/ maybe they should be ignored by the script, thanks!
[13:45] <leex> TJ-: nevertheless, thanks a lot, upgrading works now :)
[13:49] <ScottK> ara: The tools the SRU team use for SRU processing don't really work for CI train syncs so they tend to not get looked at as often.
[13:51] <ara> ScottK, so, do I have to do anything differently to make sure it is looked at?
[13:52] <ScottK> No. I'm sure it will get looked at.
[14:11] <hallyn> cjwatson: d'oh, but som eof the questions i thought weren't being asked.  i think i've been copying it lately as the wrong filename now that you mention it, but in the past it has never taken the username preseeds while it didn't ask me for partitioning...  hm.  well i'll fix the filename and test next week.  hoefully i'll just feel silly and it'll work :)
[14:12] <hallyn> xnox: do you mind opening a bug against libvirt?  i'm out until next tue.  i had originally wanted to do it during 14.04 cycle
[14:12] <hallyn> i need to do that as well as test out the upstart patch.  but, dropping irc now - ttyl
[14:22] <infinity> marga: I'm not quite asleep yet, but also in no shape to wrap my head around that bug either.
[14:22] <marga> infinity, well, pkern just found a fix
[14:22] <marga> infinity, it's 3 lines in one .S file :-/
[14:22] <infinity> marga: Oh, handy.
[14:23] <marga> infinity, he's updating the bug now, with the diff.
[14:23] <infinity> marga: Lovely.  Who's to blame?
[14:24] <marga> infinity, uhm... the interaction between x32 syscall masking and auditd
[14:25] <marga> when running on x32, syscalls have an extra high bit, that needs to be removed before calling auditd, and this wasn't happening.
[14:26] <infinity> apw: Can you have a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1302605
[14:26] <infinity> marga: Thanks to you (and pkern) for the debugging and patch.
[14:26] <marga> infinity, :)
[14:26] <infinity> marga: Does he intend to push that upstream himself?
[14:27] <marga> infinity, upstream being kernel.org?
[14:27] <infinity> marga: Yeah.
[14:27] <apw> infinity, x32 ?
[14:27] <infinity> apw: Yeah, check the last couple of comments.
[14:28] <infinity> pkern: Oh, I guess you're here, I could ask you directly. :P
[14:28] <marga> infinity, ok, he says he will try to do it
[14:31] <apw> infinity, yeah that looks about right, do i need to do something, or are they interacting upstream about it
[14:32] <infinity> apw: The last two lines of IRC backcroll seem to imply that pkern will attempt to upstream it, but if it passes muster for you guys, SAUCEing it and then replacing with an upstream commit might not be terrible.  Seems like the sort of thing that shouldn't blow up.
[14:32] <apw> infinity, ok, will ahve a poke
[14:32] <marga> apw, personally, given my experience with previous kernel.org patches coming from non kernel hackers, it would be nice if this could get applied early.
[14:32] <infinity> apw: Which is why I also gave it a trusty task for you (probably broken in saucy too, but carefactor of zero there)
[14:34] <pkern> infinity: I'll try. As you might now... Is there a primary x32 maintainer?
[14:35] <infinity> pkern: Not sure on the kernel side.  x32 in general is HJ Lu's baby, but I have no idea if he's also doing kernel or just toolchain.
[14:35] <pkern> I saw his name on the ABI documents at least.
[14:35] <pkern> Ok.
[14:36] <infinity> pkern: It might fall in hpa's lap.  Dunno.
[14:37] <infinity> pkern: The patch looks pretty mind-numbingly obvious, so I don't imagine much push-back if you can actually get noticed and get it in the right person's patch queue.
[14:39] <infinity> pkern: Anyhow, I think apw will be a gentleman and get it into the Ubuntu kernel for you guys soonish, but you should be the one submitting upstream for attribution and bragging rights.  We can swap the local patch for the upstream commit when it happens.
[14:39] <apw> infinity, pkern, that indeed
[14:41] <pkern> infinity: ACK, thanks!
[15:22] <cjwatson> xnox: is lp:~xnox/ubuntu-test-cases/touch-emulator still maintained?
[15:23] <cjwatson> xnox: just want to check if I'm working on the right basis for building autopkgtest stuff around it - if so, I have a patch to fix it up for python3 on the target
[15:30] <xnox> cjwatson: i don't believe that's latest. There was work done by #ci folks around touch-emulator.
[15:30] <xnox> cjwatson: i'd take patches / fixes for it.
[15:33] <xnox> cjwatson: plars tells me latest is in https://code.launchpad.net/~doanac/ubuntu-test-cases/emulator-scripts
[15:33] <cjwatson> Aha, right
[15:33] <xnox> cjwatson: about to land (it's emulator/x86 focused)
[15:33] <cjwatson> you have mail anyway
[15:33] <xnox> cjwatson: ack. will review.
[15:34] <cjwatson> looks like it's obsolete with that new branch
[15:34] <xnox> IMAGE_OPT="--channel ubuntu-touch/utopic-proposed --arch=i386" USE_EMULATOR=1 xvfb-run -a -s "-screen 0 640x480x24" ./scripts/run-smoke -a friends-app
[15:34] <xnox> is the new way of doing things.
[15:34] <xnox> plars telling in #ci =)
[15:34] <plars> hi
[15:35] <plars> Having some issues on the emulator side though
[15:35]  * cjwatson notes
[15:35] <plars> I ran it yesterday a few times and saw the emulator crash
[15:35] <cjwatson> I did manage to get xnox's scripts working today, but only one in three or so emulator runs actually starts up properly
[15:35] <plars> trying it with larger tests (webbrowser for example), the device just disappeared at one point on me
[15:37] <cjwatson> I had adb push hang at one point too
[15:39] <zyga> hey, is there any reason why python3-dbg doesn't load any native modules? I cannot import lxml and other things like that
[15:41] <zyga> barry: ^ any idea?
[15:41] <zyga> I need to poke around a problematic python app with gdb
[15:41] <zyga> and I want to have access to all the fancy py- macros in gdb
[15:43] <stgraber> c
[15:43] <stgraber> oops :)
[15:43] <zyga> too much gdb
[15:43] <zyga> ;)
[15:43] <zyga> s/python/python3/
[15:43] <xnox> stgraber: is your login name "c" and pasword "oops :)" ?! =)
[15:43] <stgraber> xnox: sure is :)
[15:45]  * ogra_ throws envious looks at stgraber ...
[15:45] <ogra_> i just read that you can get symmetrical 1GBit fiber in switzerland now
[15:45] <ogra_> evil !
[15:45] <zyga> ogra_: you make me sick,
[15:45] <zyga> ogra_: that should be illegal ;)
[15:45] <ogra_> ++
[15:46] <ogra_> and they say thats the low end offer ! they plan even bigger setups
[15:46] <zyga> ogra_: they must make up for the fact they have no sea ;)
[15:46] <ogra_> lol
[15:49] <xnox> zyga: they have lakes to make up for that ;-)
[15:49] <barry> zyga: you need to install the -dbg packages for any extension modules
[15:50] <zyga> barry: thanks
[15:50] <zyga> barry: I reverted to using plain python3 and py-bt finally works :)
[15:50] <zyga> it's godsend when a multi-threaded dbus service deadlocks
[15:51] <barry> nice
[15:52] <xnox> everything is nice about dbus, apart from writing bindings to dbus services or debugging it server side.....
[15:52] <stgraber> ogra_: sort of, it's been possible to get gigabit or even 10gbit fiber for a few years now but not through mainstream ISPs and obviously retricted to tiny areas, now swisscom launched their fiber service which is covering quite a few more cities but it's still a long way from being the usual kind of speed
[15:53] <ogra_> ah
[15:53] <stgraber> ogra_: nowadays your standard internet over there is around 150/15 over cable, with the fast one being 250/25, both pretty reasonably priced
[15:54] <stgraber> however, as I don't live there anymore (I just happen to be there this week before Malta) I don't get to enjoy it too often, my home connection in Montreal is just 30/10 vdsl (but very very stable, native ipv6, static IPs, ... so perfect for work)
[15:55] <stgraber> well, I can get 250/25 over cable in Montreal, it's just that it'd come with a stupid 500GB quota and won't allow using it for home servers, so not really an option...
[15:57] <ogra_> i could get 50/25 VDSL here ... if i only could get rid of my 2M SDSL line
[15:57] <xnox> i have 120/10 in London. And I am disappoint. Fairly static IPs (~ it renews only about 2 times a year, or well never if you keep your router on), no IPv6 =(
[15:58] <Laney> at least no CGNAT on virgin... yet...
[15:59] <cjwatson> xnox: Is that ADSL?  You could probably get native IPv6 from A&A then
[16:00] <xnox> cjwatson: that's cable. I have not had ADSL since 2010. (since there is no options but ADSL in Hull)
[16:01] <xnox> cjwatson: A&A is pricey =)
[16:02] <cjwatson> They actually improved their pricing a fair bit recently from my point of view, so I was going to look at them again after I got back from Malta
[16:04] <stgraber> my current DSL provider also comes at a premium vs the usual ones, but that's what you have to pay to get good service and competent support when things go wrong. Otherwise you'll end up with the usual "did you update Windows?" kind of tech support and will be stuck without internet for a week...
[16:05] <stgraber> (though with DSL, it's usually the phone provider that screws up and unfortunately you can't quite change that, unless you go cable and then it's even worse, at least in Canada)
[16:06] <cjwatson> A&A take special pride in browbeating the phone provider into fixing things faster than anyone else, which is one reason I'm interested :)
[16:06] <cjwatson> Anyway, EOW
[16:07] <stgraber> :)
[16:07] <stgraber> ok, have fun, see you on Sunday/Monday!
[16:21] <rbasak> xnox: I'm with A&A. For the quality I get, I don't think 100GB/mo for £25 (+£10 line rental) is pricy.
[16:23] <rbasak> It's sometimes a bit annoying to have to watch the bandwidth when doing some repeated test that uses cloud images though.
[16:23] <rbasak> I tend to try and do that sort of thing somewhere online instead, rather than local.
[16:38] <elmo> I agree, I don't think A&A is pricey either; I'll happily pay their prices for a competent ISP and the native v6 is a nice added bonus
[17:00] <xnox> rbasak: i should find out how much bandwidth i waste, cause we stream television over the internet (via russian channels subscription)
[17:31] <ryanneufeld> Can someone point me to a guide for building my own deb packages for trusty that doesn't include all the bazzar and launchpad stuff?
[17:38] <apw> pkern, ok test kernels are posted in the bug, if you could let me know how they pan out.
[18:41] <Henne91> Hey guys! I'm trying to create a patch to fix/workaround the following bug: https://bugs.launchpad.net/ubuntu/+source/indicator-keyboard/+bug/1240198
[18:41] <Henne91> I've never done this before so I thought maybe somebody here can help me with this.
[18:43] <Henne91> Basically it seems like it is necessary to create an additional config file for ibus to change its default behaviour.
[18:44] <Henne91> I used Quilt to create the file as a patch.
[18:46] <Henne91> Ok, just found the required infos in the docs. Nevermind! ;-) Thanks anyway.
[18:59] <smoser> hey, is there any way of getting ddebs through a ppa ?
[19:01] <dobey> smoser: you can request it be enabled for your ppa i think
[19:02] <smoser> dobey, just as in a request to launchpad ?
[19:02] <smoser> specifically i'm after this for cloud archive, which is built via a ppa and then copied elsewhere.
[19:04] <dobey> smoser: as in asking an lp admin, yeah.
[19:05] <dobey> smoser: ask, as in the asme way one would ask for arm support in a ppa
[19:05] <smoser> dobey, thanks.
[19:47]  * xnox stops doing random uploads and goes to pack
[21:15] <Shock> hi
[21:16] <Shock> I've made a patch for #1247584 and tested locally on my system. would anyone be willing to help me prepare the patch for inclusion in ubuntu?
[21:43] <sarnold> Shock: oof, looks complicated. If you attach your patch to the bug, it'll kick off another bot that'll add some messages and perhaps prod other people into looking at the bug to sponser the patch.
[21:44] <Shock> sarnold: thanks. would've liked to learn how to do it myself, though.
[21:54] <sarnold> Shock: makes sense :) do you have sbuild set up on your machine yet? That'd be a handy next step, if not; that'll make it easier to test patches in the packaging
[21:54] <Shock> sarnold: nope, I've been building the packages with dpkg-buildpackage
[21:55] <sarnold> Shock: ah, fair enough. for occasional use that's just fine :)
[21:55] <sarnold> Shock: what does 'what-patch' return for that package?
[21:56] <Shock> quilt
[21:57] <sarnold> Shock: nice. if you quilt push -a all the patches onto the queue, then you could use quilt import /path/to/patch to add your patch to the end of the file
[21:57] <Shock> sarnold: I've been reading http://packaging.ubuntu.com/html/fixing-a-bug.html but I don't understand the relationship between all the parts
[21:58] <Shock> sarnold: I've already built a package with the patch locally
[21:58] <sarnold> Shock: nice! now you need a debdiff. this is the part that gets hard for me, because I use a different toolchain that automates this away from me :) hehe
[21:59] <Shock> sarnold: I've installed devscripts
[21:59] <sarnold> Shock: did you update the debian/changelog?
[21:59] <sarnold> (add new version etc)
[21:59] <Shock> sarnold: no
[21:59] <sarnold> Shock: okay, dch -r will help you there :)
[22:00] <Shock> sarnold: I dont know all the rules pertaining to the changelog/versioning so I've left it alone. the package I've built has the same version as the one in the archive
[22:00] <sarnold> Shock: there's some version update examples here: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[22:01] <Shock> sarnold: ok, I'm in the editor
[22:01] <Shock> this is insane :) is it not possible to automate it somehow?
[22:02] <sarnold> Shock: that's the handy tool I mentioned earlier :) I'm not sure if it would repay the setup costs for just dealing with a package once in a while, but it's really handy for dealing with five versions of four packages each week :)
[22:03] <Shock> sarnold: I'm talking about stuff like "Please be careful. Security updates must have a version number higher than any version that was in the archive for that release. This means you must check the release pocket, the proposed pocket and the updates pocket (see SecurityTeam/FAQ#Repositories for details)."
[22:03] <Shock> sarnold: it seems very error prone
[22:04] <Shock> sarnold: in time, I plan to understand the relationships between pbuilder, dpkg-buildpackage, sbuild, schroot, debootstrap, etc
[22:04] <Shock> sarnold: seems a lot to take in
[22:04] <sarnold> Shock: the launchpad 'source package' page will have version numbers all handily collected in one place; check https://launchpad.net/ubuntu/+source/systemd for the numbers
[22:05] <sarnold> Shock: (again, this is another step that is abstracted away a bit by the 'umt' tool I use, it'd be 'umt search system' -> http://paste.ubuntu.com/7507428/
[22:06] <Shock> sarnold: if I understand correctly, my version should be 204-5ubuntu20.3
[22:07] <sarnold> Shock: looks right to me
[22:08] <Shock> sarnold: ok, I'm in the editor spawned by dch -r
[22:08] <Shock> sarnold: at the top is the last official changelog entry
[22:08] <sarnold> Shock: oh man. I'm sorry. I mis-remembered. :( quit out of that without saving..
[22:09] <sarnold> Shock: dch -a  should do what you want
[22:09] <Shock> sarnold: with my name under it :-/
[22:10] <Shock> sarnold: I must've done something wrong because dch -a is somehow replacing the last changelog entry
[22:10] <sarnold> Shock: it didn't make a new one for you?
[22:11] <cjwatson> dch -i would be more usual for that.
[22:11] <Shock> sarnold: no, I think this is because I've issued a debcommit at one point in order to comply with what dpkg-buildsource was asking
[22:11] <cjwatson> dch -a explicitly asks to append to the current entry.
[22:12] <sarnold> cjwatson: sigh. thanks. :)
[22:12] <sarnold> neat though, that'll be handy to have.
[22:12] <sarnold> Shock: twice wrong in one go. sorry. sigh.
[22:12] <Shock> ok, dch -i left the last entry intact and created a new one for me. it doesn't have the version at the top like the last official entry
[22:13] <Shock> sarnold: don't worry, this way I've learned the difference between dch -r, -a, and -i :)
[22:13] <sarnold> Shock: haha :) me too, when before all I ever used was -r ..
[22:14] <sarnold> (which worked in my workflow, 'umt changelog' does the dch -i with a calculated version number...)
[22:16] <Shock> sarnold: I prefer to stay with the low level stuff until I understand how the plumbing works, then move to higher level stuff
[22:17] <sarnold> Shock: *nod*
[22:19] <Shock> sarnold: this is the top of the changelog in the editor: http://paste.ubuntu.com/7507454/
[22:21] <sarnold> Shock: nice; could you also add (LP: #1247584) to the comment, so the bug will be closed when the package is uploaded?
[22:22] <Shock> sarnold: added! do I need to add a version line?
[22:22] <sarnold> Shock: yes, I believe 'trusty-updates' for the release name
[22:25] <Shock> sarnold: added "systemd (204-5ubuntu20.3) trusty-updates; urgency=medium", what now?
[22:26] <Shock> parsechangelog/debian: warning:     debian/changelog(l3): found start of entry where expected start of change data
[22:26] <Shock> LINE: systemd (204-5ubuntu20.3) trusty-updates; urgency=medium
[22:26] <Shock> parsechangelog/debian: warning:     debian/changelog(l3): found eof where expected start of change data
[22:26] <Shock> got that after saving
[22:26] <sarnold> Shock: rebuild the package; find a pristine copy of 204-5ubuntu20.2 source package -- and use debdiff between the two .dsc files to generate a debdiff that you can attach to the bug and ask for a sponser
[22:27] <Shock> sarnold: should I ignore the warning from dch?
[22:28] <sarnold> Shock: I -think- your asterisk was one column too soon
[22:29] <sarnold> the one on line 8 is under the second 's' in 'systemd', make sure yours lines up on the same column
[22:30] <Shock> sarnold: it seems alligned with the other asterisks. dch added a line above my version line "systemd (204-5ubuntu20.3) UNRELEASED; urgency=medium"
[22:31] <sarnold> Shock: ah, yeah, you only need one of those lines
[22:31] <Shock> sarnold: I'll delete the one added by dch
[22:36] <Shock> sarnold: I've run debdiff: http://paste.ubuntu.com/7507521/
[22:38] <sarnold> Shock: you ought to be using the 20.3.dsc from your 'work' directory instead
[22:38] <sarnold> (it'll be built once you rebuild the package with your new changelog entry in place)
[22:38] <Shock> sarnold: I dont have a 20.3.dsc :-/
[22:38] <Shock> oh
[22:39] <Shock> is a source build sufficient?
[22:39] <sarnold> it should be for a changelog-only change
[22:43] <Shock> sarnold: it's telling me it detected local changes (to files I've not modified) and aborting. do you need pastebin with the errors?
[22:43] <sarnold> Shock: try quilt pop -a and then rebuild?
[22:48] <Shock> sarnold: debdiff worked but maybe using what it output would be giving the maintainer more work than attaching a simple diff :(
[22:49] <sarnold> Shock: maybe, can you pastebin it?
[22:49] <Shock> sure
[22:50] <Shock> sarnold: http://paste.ubuntu.com/7507563/
[22:50] <ScottK> sarnold: Actually trusty or trusty-proposed.
[22:50] <sarnold> ScottK: oh! thanks
[22:51] <sarnold> Shock: man that looks very nearly awesome. the patch headers for the 99-keyboard-test.patch are funny :) -- those should be replaced with something more useful
[22:51] <infinity> Just trusty, please.
[22:52] <Shock> sarnold: it told me "The information above should follow the Patch Tagging Guidelines" and I was like "eject! eject!" :) information overflow
[22:53] <sarnold> Shock: hehe yeah I've had this tab open for nearly two years now :)  http://dep.debian.net/deps/dep3/
[22:54] <infinity> The boilerplate it gives you should be enough to go by, usually.  Just fill in the blanks.
[22:55] <Shock> sarnold: I'm gonna modify the debdiff directly. how do I check if it applies cleanly to the pristine package source?
[22:55] <sarnold> Shock: unpack the sources in a clean tree, then run patch --dry-run -p1 < /path/to/debdiff -- ifit applies, then take off the --dry-run, re-apply, then re-run the build
[23:00] <Shock> sarnold: there's a patch in the patches directory that creates a whole file (on which my patch depends on). how do I ensure my patch is run after the other one? does quilt take care of the ordering?
[23:00] <infinity> Shock: ordering is based on the order in the series file.
[23:00] <Shock> infinity: thanks, then I'll drop the numeric prefix from the patch file name
[23:30] <Shock> sarnold: ok, I edited the debdiff, applied it and built the package


[02:36] <jbicha> doko: does it make sense to have openjdk-12 in the disco release archive? since its lifecycle is so short
[05:15] -queuebot:#ubuntu-release- New binary: alglib [s390x] (disco-proposed/universe) [3.14.0-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: alglib [ppc64el] (disco-proposed/universe) [3.14.0-1] (no packageset)
[05:21] -queuebot:#ubuntu-release- New binary: alglib [amd64] (disco-proposed/universe) [3.14.0-1] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: alglib [arm64] (disco-proposed/universe) [3.14.0-1] (no packageset)
[05:22] -queuebot:#ubuntu-release- New binary: alglib [i386] (disco-proposed/universe) [3.14.0-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: alglib [armhf] (disco-proposed/universe) [3.14.0-1] (no packageset)
[09:23] <LocutusOfBorg> hello can anybody please bump symfony hint on armhf to  3.4.19+dfsg-1ubuntu1 ? upstream should receive a patch soon
[09:23] <LocutusOfBorg> there is an ongoing PR
[09:32] -queuebot:#ubuntu-release- New: accepted alglib [amd64] (disco-proposed) [3.14.0-1]
[09:32] -queuebot:#ubuntu-release- New: accepted alglib [armhf] (disco-proposed) [3.14.0-1]
[09:32] -queuebot:#ubuntu-release- New: accepted alglib [ppc64el] (disco-proposed) [3.14.0-1]
[09:32] -queuebot:#ubuntu-release- New: accepted alglib [arm64] (disco-proposed) [3.14.0-1]
[09:32] -queuebot:#ubuntu-release- New: accepted alglib [s390x] (disco-proposed) [3.14.0-1]
[09:32] -queuebot:#ubuntu-release- New: accepted alglib [i386] (disco-proposed) [3.14.0-1]
[14:33] <jbicha> https://code.launchpad.net/~jbicha/britney/libuv1_starjava-ttools_symfony/+merge/359971
[21:51] -queuebot:#ubuntu-release- New binary: pushover [amd64] (disco-proposed/universe) [0.0.5+git20180909-3] (no packageset)


[00:33] <lifeless> wgrant: Care to do me a favour ?
[00:33] <lifeless> wgrant: see #isd scrollback and guess what it is.
[01:56] <wallyworld_> wgrant: i expect we will eventually make bug/branch sharing policy required=True, so for now i should default to PUBLIC if null
[01:57] <wgrant> wallyworld_: All projects will start with them unconfigured when we turn this on.
[01:58] <wallyworld_> so unconfigured = PUBLIC, right? i need to determine what to show in the ui if not set
[01:58] <wgrant> unconfigured = public or private, with a different meaning to any of the existing enum values
[01:59] <wgrant> unconfigured means that private_bugs and BranchVisibilityPolicy are respected
[01:59] <wgrant> Which have more complicated meanings than *_sharing_policy
[01:59] <wallyworld_> oh joy. ok, so that makes things a little more complicated on the ui.
[02:00] <wgrant> Yeah, indeed, sorry. Forgot about that
[02:00] <wallyworld_> np, it's all fun
[02:01] <wgrant> Perhaps makes it similar to the milestone widget
[02:01] <wgrant> I don't think it needs to be settable back to null
[02:01] <wgrant> That can always be done through the API if someone makes a mistake and needs to revert.
[02:02] <StevenK> Perhaps we should add it to the "Configuration options" on the project page
[02:02] <StevenK> "Configure sharing options"
[02:02] <wgrant> That's not "Configuration options"
[02:02] <wgrant> That's "UI trainwreck"
[02:03] <StevenK> Same same
[02:03] <wallyworld_> so i was working on adding it to the +sharing page as discussed this morning
[02:03] <wgrant> (but yes, it's possible that the "(!) Sharing" link should become "(!) Configure sharing" down there, but that's not relevant here)
[02:03] <wgrant> The sharing config clearly belongs on +sharing
[03:17] <StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/drop-enhanced_choice_popup/+merge/119461
[03:19] <wallyworld_> StevenK: the test case needs to be renamed now there are more tests added
[03:51] <StevenK> wallyworld_: Sorry, was noming. http://pastebin.ubuntu.com/1146190/
[03:51] <wallyworld_> np
[03:52] <wallyworld_> that'll do, i already +1
[04:08] <lifeless> ggrrrr iso-testing.
[04:08] <lifeless> GRRRRGRGRGR
[04:09] <StevenK> lifeless: Hm?
[04:09] <lifeless> bug 6.
[04:09] <lifeless> Again.
[04:10] <lifeless> I will bet a large (say 1000) amount of money that there is a doc or some other thing in the iso-testing system that folk are following.
[04:21] <StevenK> wgrant: Do you want to help me bash my head against this testbrowser upgrade branch, or do you have something more productive for me to do?
[04:21] <StevenK> With hopefully less pain and suffering.
[04:21] <wgrant> StevenK: What's still broken?
[04:22] <StevenK> wgrant: Still the four from yesterday.
[04:22] <StevenK> xx-person-subscriptions has been nailed shut
[05:05] <StevenK> Errr
[05:06] <StevenK> cp -a lib/canonical/launchpad/icing/yui_2.7.0b/build build/js/yui2
[05:06] <StevenK> cp -a lib/canonical/launchpad/icing/yui_2.7.0b/build build/js/yui2
[05:06] <StevenK> cp -a lib/canonical/launchpad/icing/yui_2.7.0b/build build/js/yui2
[05:06] <StevenK> Repeat a lot
[05:06] <wgrant> StevenK: That's been around for a while.
[05:07] <lifeless> bigjools: want to do that call from last week ?
[05:07] <StevenK> wgrant: Bah
[05:07] <bigjools> lifeless: can do - and I'll explain why I missed it :)
[05:08] <bigjools> lifeless: call me when ready
[05:08] <lifeless> bigjools: ok, be a couple of minutes
[05:12] <StevenK> wgrant: Why are recipes so terrible? Do you think that its plausible that OOPS-71b883b1dbbd619339e84b662eca301a is related to bug 893576?
[05:16] <lifeless> https://code.launchpad.net/~lifeless/python-oops-timeline/lgpl/+merge/119468
[05:16] <lifeless> wgrant: did you do that favour for me btw?
[05:17] <wgrant> StevenK: That OOPS doesn't appear to exist anywhere
[05:17] <StevenK> Oh, you have to kidding me.
[05:17] <wgrant> Unless we have an OOPS storm somewhere
[05:17] <wgrant> lifeless: No
[05:17] <StevenK> OOPS: OOPS-dabad1c5d11797cefc608105ae54d218
[05:17] <StevenK> Filename: /srv/oops.canonical.com/oops-amqp/launchpad/production/2012-08-13/OOPS-71b883b1dbbd619339e84b662eca301a
[05:17] <StevenK> *FACEPALM*
[05:17] <wgrant> Ah
[05:18] <wgrant> Yes
[05:18] <wgrant> And no, they're unrelated
[05:18] <wgrant> There's a separate bug for that one
[05:19] <StevenK> Easiest fix is to error out say "Remove the obsolete distro from your recipe." Slightly harder is to filter out the obsolete distro
[05:20] <StevenK> wgrant: What's your opinion?
[05:21] <wgrant> Not sure :)
[05:21] <StevenK> lifeless: ^ You're pretty opinated. :-)
[05:22] <StevenK> Anything at all is better than an OOPS
[05:31] <lifeless> StevenK: oops filenames != oops ids
[05:31] <StevenK> lifeless: Why display them at all?
[05:32] <lifeless> so that if you want to look at custom fields you can
[05:35] <wgrant> wallyworld_: Did you try putting the fields in the main body? They would probably fit well, particularly as it doesn't really make sense for them to be in the sidebar.
[05:36] <wgrant> (and that huge warning won't usually be there)
[05:36] <wallyworld_> wgrant: it didn't look so good - too much text and vertical space used
[05:37] <wallyworld_> i hate reading lots of text without it being somehow grouped
[05:39] <wallyworld_> plus we have wasted white space on the right of the page i thought it may be nice to use, similar to the bug privacy portlet
[05:39] <wallyworld_> but, all just my opinion
[05:40] <wgrant> wallyworld_: Yeah, indeed. But I think it could work well to just simply split the page into two sections: the first declares which artifacts are which type, the second declares who can see which type.
[05:40] <wgrant> It's difficult to say
[05:41] <wallyworld_> yeah, need user feedback i guess. maybe we can through it out there and see what feedback we get; it's beta after all
[05:41] <wallyworld_> and the layout can be changed quickly to suit
[05:41] <wgrant> Indeed
[05:42]  * wallyworld_ has run out of coffee, situation critical, need to go buy some more
[05:42] <wgrant> Uhoh
[05:50] <StevenK> Hm, I thought the feature flags around SPRecipes were long dead
[05:50] <wgrant> They should be. Why?
[05:50] <StevenK>     def setUp(self):
[05:50] <StevenK>         super(TestSourcePackageRecipe, self).setUp()
[05:50] <StevenK>         self.useContext(feature_flags())
[06:28] <lifeless> StevenK: can I have a review of https://code.launchpad.net/~lifeless/python-oops-timeline/lgpl/+merge/119468 ?
[06:29] <lifeless> wgrant: any chance you can review that ppr thing ?
[06:29] <StevenK> lifeless: I glanced at it. TBH, I thought were going to self-review.
[06:30] <lifeless> hmm, perhaps I should. But I've interrupted you already, so meg.
[06:30] <lifeless> StevenK: wgrant: I can't find the bug (but I know it exists) for recipes w/obsolete series.
[06:30] <StevenK> 890	-# GNU Affero General Public License version 3 (see the file LICENSE).
[06:30] <StevenK> 891	+# GNU General Public License version 3 (see the file LICENSE).
[06:31] <StevenK> Tis bug 1006493
[06:31] <wgrant> lifeless, StevenK: Bug #1006493
[06:31] <wgrant> Yeah
[06:31] <wgrant> That
[06:31] <lifeless> grah. thanks, apparently I fail at simple search and replace.
[06:31] <StevenK> lifeless: That's buildout.cfg. GPLv3? Really?
[06:32] <StevenK> lifeless: That's the only thing that belts me in the face. I'd prefer the copyright years updated to include this year, but I'll leave it up to you.
[06:33] <lifeless> StevenK: no other changes to the file - copyright doesn't accrure.
[06:34] <StevenK> lifeless: "but I'll leave it up to you." :-)
[06:34] <lifeless> sure, thanks.
[06:35] <StevenK> lifeless: And approved.
[06:35] <lifeless> StevenK: I replied because it would be wrong to update the copyright, as opposed to merely a preference :)
[06:35] <lifeless> StevenK: thank you!
[06:36] <wallyworld_> wgrant: do you know if one can call via a web service named_operation a method that has been declared as a property mutator?
[06:36] <wgrant> wallyworld_: No. You have to use PATCH for that
[06:36] <wallyworld_> bollocks :-(
[06:37] <wgrant> Why?
[06:37] <wallyworld_> patch sucks because it returns an entry resource and not what one might really want
[06:38] <wallyworld_> whereas a named op you can return arbitrary json data or html or whatever suits your needs
[07:12] <bigjools> it'd sure be nice if the "workitems_text: Unknown status XXX" was accompanied by a list of valid statuses
[07:48] <adeuring> good moorning
[08:42] <lifeless> are there any undeployed DB patches ?
[08:44] <wgrant> No
[08:44] <wgrant> cjwatson will hopefully have one soon
[08:44] <wgrant> It's in review now, I believe.
[08:44] <wgrant> Which means we can apply the new downtime schedule now :)
[08:45] <czajkowski> wgrant: has that been blogged/annouced yet ?
[08:46] <wgrant> stakeholders have been told, and I imagine it will be blogged soonish
[08:58] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/db-process-accepted-bugs-job/+merge/119320 awaiting review, yes
[09:11] <mgz> can feature flags be set in advance of them actually existing?
[09:12] <mgz> or should I put a note in the NDT for the land that includes this change for the l-osa to set the flag after?
[09:12] <wgrant> mgz: 'If true, load posts from the launchpad for display on the root page.' ← do you mean "Launchpad blog"?
[09:12] <wgrant> mgz: And yeah, you can set beforehand if you need
[09:13] <mgz> dammit
[09:13] <wgrant> Having unknown ones isn't a problem
[09:13] <mgz> literally just sent that to be merged
[09:14] <mgz> can I sneak in another rev with ec2 land?
[09:15] <wgrant> mgz: ec2 land doesn't ask PQM to merge a specific revno. It'll submit whatever's in the branch when the run finishes.
[09:15] <wgrant> So you can push up a rev now while it's running, as long as you promise it won't break the test suite :)
[09:15] <mgz> woho! :)
[09:24] <lifeless> czajkowski: it has now
[09:25] <czajkowski> lifeless: sweet :)
[09:25] <czajkowski> lifeless: would you like me to to A) copy that onto the blog and circulate everywhere, or B) just post that link to other places?
[09:26] <wgrant> If you do copy it elsewhere, might want to s/5 seconds/5 minutes/
[09:26] <lifeless> czajkowski: Thanks for offering. I'll do an announcement to the main LP blog myself.
[09:26] <lifeless> wgrant: did I typo ?
[09:26] <wgrant> "This schedule will give us a max of 30 seconds downtime per day, a
[09:26] <wgrant> significant reduction from the current maximum of 5 seconds,"
[09:26] <wgrant> :)
[09:26] <lifeless> DOHFUCK
[09:26] <lifeless> wgrant: please follow up to my mail and correct it ;)
[09:27] <wgrant> Sure
[09:27] <czajkowski> lifeless: np, I know it's late you side of the world :)
[09:28] <lifeless> You are as late as you feel.
[09:43] <mgz> czajkowski: also there's a s/slow/slot/ to fix when reposting
[09:44] <lifeless> czajkowski: blog post done; feel free to edit if you wish :).
[09:49] <czajkowski> lifeless: cheers
[10:03] <G> lifeless: czajkowski: s/at once of these times/at one of these times/ ?
[10:18] <czajkowski> G: fixed
[11:03] <wgrant> cjwatson: " * even the API for accepting unapproved uploads to a PPA is cumbersome; while it is (I think) possible, it requires explicitly granting oneself a queue admin permission on one's own PPA"
[11:03] <wgrant> cjwatson: I don't believe it's possible to create queue admin permissions on a PPA
[11:03] <wgrant> It's not meant to be, at least.
[11:08] <cjwatson> wgrant: What's there to prevent it?
[11:08] <cjwatson> The archive owner has launchpad.Edit on IArchive, and I don't see any other restrictions on newQueueAdmin.
[11:08] <cjwatson> Not saying it's sane.
[11:09] <wgrant> :(
[11:09] <wgrant> Indeed
[11:10] <cjwatson> Obviously the answer is to not get into that situation in the first place.
[11:11] <wgrant> Yeah
[11:42] <czajkowski> cjwatson: you've been busy this morning, :)
[11:43] <czajkowski> bug queue is busy :)
[12:20] <cjwatson> czajkowski: only four :)
[13:42] <mgz> 17477 tests run in 4:12:35.906462, 1 failures, 0 errors
[13:43] <mgz> dammit... there was a doctest
[13:43] <mgz> why are you testing html output in doctests launchpad ;_;
[13:44] <cjwatson> Think of it as a reserve of LoC.
[13:48] <mgz> ha, a good tip, just found a couple of hundred to lose
[13:51] <deryck> rick_h_, I'm qa-ok on that edit emails thing.
[13:53] <rick_h_> deryck: ok cool thanks
[13:56] <mgz> ...is this google web service stuff actually used any more?
[13:57] <mgz> ah, it's on the main page only?
[14:31] <mgz> actually, I'll be conservative for now...
[14:31] <mgz> deleting too much junk would make this more annoying to land.
[14:45] <rick_h_> cjwatson: ping
[14:45] <cjwatson> rick_h_: yes?  (you have 15 minutes until my screen session goes unattended)
[14:46] <rick_h_> cjwatson: just wanting to say that I'm looking at your branches for review, but man their a bit out of my wheel house and lots of corner cases it seems
[14:46] <rick_h_> cjwatson: so I think I'll punt to the more build-side heavy folks, but don't want you to think I'm ignoring you
[14:46] <cjwatson> that's fine, I'm offline from 15 minutes from now until Thursday anyway
[14:47] <rick_h_> cjwatson: ok, sorry for the delay
[14:47] <cjwatson> (I've done my pending QA on dogfood and should be able to qa-ok those changes from my phone once they hit qastaging)
[14:48] <rick_h_> thanks cjwatson
[14:54] <czajkowski> cjwatson: off anywhere nice
[14:54] <czajkowski> or just taking a break from lp :)
[14:55] <cjwatson> family funeral
[15:14] <deryck> rick_h_, fantastic work, sir, on the wireframes!
[15:15] <deryck> rick_h_, can you spare 5 minutes for a video chat about it?  Just next steps, no corrections or comments from me.
[15:16] <rick_h_> deryck: sure thing
[15:17] <deryck> rick_h_, standup hangout.... joinging now....
[15:20] <czajkowski> cjwatson: oh I'm sorry to hear that.
[15:32] <rick_h_> deryck: should I attach a pdf you think or just refer to the U1 link?
[15:33] <deryck> rick_h_, refer to the U1 link
[15:33] <rick_h_> k
[15:45] <rick_h_> deryck: ok, email sent, I'll be hiding under this desk for the rest of the day :P
[15:46] <deryck> rick_h_, heh, no fear!
[15:46] <rick_h_> deryck: woot, and ndt is complete so once I fix these 3.5 bugs I we can flip the feature flag for orange!
[15:46] <deryck> nice!
[15:46] <czajkowski> deryck: is https://bugs.launchpad.net/launchpad/+bug/1036267 rolling out soon ?
[15:47] <deryck> czajkowski, just deployed.
[15:47] <deryck> rick_h_, don't forget to mark the bugs fix released.
[15:47] <czajkowski> oh good, before I hop my phone of a wall!
[15:47] <czajkowski> stupid 2 fctor auth!
[15:47] <czajkowski> *factor
[15:47] <rick_h_> deryck: ah, it won't auto do that?
[15:47] <deryck> rick_h_, no, sorry
[15:47] <czajkowski> rick_h_: no bugs are lazy that way!
[15:47]  * rick_h_ has messed that up several times then doh
[15:48] <rick_h_> thanks for the heads up/reminder then
[16:48] <cgoldberg> is anyone here familiar with PPR (Launchpad Page Performance Reports)?  It's a zserver tracelog parser that creates html reports (pageperformancereport.py).  lifeless recently moved the code from launchpad codebase into lp-dev-utils... and I'm doing some work on it now.  We want to re-use it for parsing Apache Access logs (for SSO and other projects).
[16:48] <cgoldberg> anyone up for a code review of a lp-dev-utils branch? :)
[16:52] <czajkowski> cgoldberg: the on call reviewer is in the topic, currently it is rick_h_ so he'd have to see how busy his queue is
[16:58]  * deryck goes offline for lunch, back soon
[17:02] <cgoldberg> czajkowski, thanks
[17:25] <rick_h_> cgoldberg: linky to the MP?
[17:25] <rick_h_> sorry, just back from lunch
[17:28] <cgoldberg> rick_h_,  https://code.launchpad.net/~coreygoldberg/lp-dev-utils/ppr-access-parser/+merge/119409
[17:29] <rick_h_> cgoldberg: k, loading up
[17:30] <cgoldberg> rick_h_, k thanks!   lifeless was sorta guiding me.. but got too busy to review an MP.  If he has time today, i'd like him to look also before merging
[17:31] <rick_h_> cgoldberg: ok, if he's online before I EOD I'll prod him
[18:16] <lifeless_> science, it works.
[18:17] <rick_h_> says you :P
[18:23] <sinzui> rick_h_: are you aware of a yui function/library that we could trivially reuse to set the deactivated attribute of subordinate fields. eg checkbox/radiobutton must be checked for input field to accept input?
[18:29] <rick_h_> sinzui: not off the top of my head no. I'd htink it's be just an event on a form handling object with a list of disable/enable based on some attrChange event
[18:32] <sinzui> maybe we want to add an attr to all subordinate fields that cannot have input without the another field's state being checked. eg, data-leader="membership-can-expire" on the field that asks for the expiration days. A common script could look for that attr, from the leader field from add a handler to toggle deactivated based on the state of leader.checked
[18:33] <rick_h_> sinzui: wallyworld_ jcsackett just a heads up, updating the JS tests to pass in 3.5.1. Some broke since last fix up. https://code.launchpad.net/~rharding/launchpad/yui35_test_fix2/+merge/119603
[18:33] <rick_h_> so just reminder on the quotes on attrs and such, orange is going to start running with the 3.5.1 feature flag soon and I'll see if I can find a chance to figure out a way to run our JS tests on multiple versions somehow
[18:35] <rick_h_> sinzui: ah, gotcha. Yea, nothing I know of off the top of my head. Is this on some widget out there?
[18:35] <sinzui> sorry rick. I reviewed some of those tests you fixed
[18:35] <rick_h_> sinzui: np, it's going to happen until the tests actual fail for everyone
[18:36] <sinzui> is the leap to 3.6 harder? should we target that now instead on 3.5?
[18:36] <rick_h_> sinzui: so two parts
[18:36] <rick_h_> 1) 3.6. is new and I don't tend to trust new and I don't think we *need* anything in there atm
[18:37] <rick_h_> 2) I'm working on making it easier to test/upgrade versions and going from 3.5.1 to 3.6 will make a good test run of that process
[18:37] <sinzui> fab
[18:37] <rick_h_> sinzui: plus we can't do anything still until we get everyone on the combo loader so it'll be some time yet I'm sure :/
[18:38] <sinzui> I thought the loader was on for everyone. I thought I was the last person to switch, and I hacked my env to work with combo-loader and ie8 a few weeks ago
[18:39] <rick_h_> sinzui: if your form needs are a current widget maybe we can do some sort of extension that adds a .submit event binder and runs through a list of 'fields xxx require yyy enabled else set xxx.value(undefined)
[18:39] <rick_h_> sinzui: well, it's on for up through beta-testers
[18:39] <rick_h_> but not on full production
[18:39] <sinzui> okay. understood and agreed we need it on default first
[18:39] <rick_h_> we're waiting on an RT to setup squid caching of JS combo load files for that
[18:41] <sinzui> rick_h_: I think I want two data attrs to define two different behaviours. One ensure the subordinate field cannot be used without first checking the master...to prevent users from entering unneeded information. I want the opposite where entering a value in the input checks the master checkbox/radiobutton so that my entry is not ignored by some forms.
[18:42] <rick_h_> sinzui: yea, I think we'd have to have a base starting widget that was a 'form container'
[18:42] <sinzui> We have about 5 bugs where form input fails because the form does not do that the user implies, or the form implies the user should do something.
[18:43] <rick_h_> sounds perfect for something like a yui 3.5 View base class
[18:43] <rick_h_> *sigh*
[18:44] <rick_h_> deryck: ok, so since these are just test fixes, going to ask for the feature flag to 3.5.1 to be set on orange.   Like the ending of the Lath of Heaven, we are dying, dreaming of life
[18:51] <lifeless_> rick_h_: you should read 'thinking, fast and slow'.
[18:51] <lifeless_> rick_h_: not the social science you think you know.
[18:52] <rick_h_> lifeless_: sorry, now approaching hour 7 in a car dealership and getting YUI 3.5.1 going into testing 7 months after the sprint to enable the change so I'm frisky today :P
[18:52] <lifeless> rick_h_: oh la la :P
[18:58] <rick_h_> deryck: ok, you've got 3.5.1 enjoy
[18:58] <deryck> I will!
[18:58] <rick_h_> I'll write up an email to the -dev list saying it's alive and kicking
[19:04] <sinzui> jcsackett: do you have time to discuss my next actions to make quick team registration sane
[19:05] <jcsackett> sinzui: sure, just one sec.
[19:08] <jcsackett> sinzui: i just missed your invite, calling back.
[20:33] <sinzui> jcsackett: haha. teams have two descriptions and the page hides the screw up. I may need to do some work on Bug #5283 just to keep the LoC count down
[20:33] <_mup_> Bug #5283: "Home page" vs. "Description" is misleading <bad-commit-11051> <easy> <lp-registry> <qa-ok> <teams> <tech-debt> <ui> <users> <Launchpad itself:In Progress by nigelbabu> < https://launchpad.net/bugs/5283 >
[20:34] <jcsackett> sinzui: fantastic. :-P
[21:53] <cgoldberg> lifeless, i'm gonna EOD in a bit.. not sure if rick_h_ got anywhere on my code review :)  could you have a look today?
[21:53] <cgoldberg> https://code.launchpad.net/~coreygoldberg/lp-dev-utils/ppr-access-parser/+merge/119409
[22:06] <rick_h_> cgoldberg: sorry, lifeless popped in and he was assigned on the review so passed since it involves amking some config stuff mandatory/etc and I'm not sure where this is used
[22:06] <rick_h_> so lifeless  ^^
[22:07] <cgoldberg> rick_h_, np
[23:33] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/format-imports-and-again/+merge/119645 when you have a spare moment. sinzui caused most of the fallout, but oh well
[23:34] <sinzui> StevenK: you don't need a review of mechanical changes made by a script....particularly when the changes were made by mechanical scripts to begin with
[23:35] <StevenK> sinzui: Oh yes I do. format-imports has made some bad calls over the six or seven times I've run it over the full tree.
[23:35] <wgrant> Yeah
[23:35] <wgrant> I catch an issue about half the time
[23:36] <sinzui> fix the script
[23:36] <wgrant> Adding "# FIRST" fixes most files, but not all of them
[23:36] <wgrant> Anyway, this case is all good.
[23:37] <StevenK> Yeah, some of the files require manual fixing if they have imports that are between the copyright header and __metaclass__
[23:37] <wgrant> lint should probably be taught to complain about that
[23:37] <StevenK> Indeed
[23:38] <StevenK> wgrant: Thanks, lp-landing