[00:01] <bazhang> the imagemagick manual rivals war and peace for length
[00:01] <bazhang> one of the former ops here actually printed it out
[04:11] <rww> Flannel: werewolf person has also been hit with a cluebat by their ops now too
[04:11] <rww> they don't like that sort of nonsense either
[04:11] <Flannel> Most channels don't.  Thankee.
[04:36] <daftykins> Flannel: you're aware you just kicked a volunteer for actually replying to relevant topics?
[04:38] <Flannel> daftykins: I'm aware of who I kicked.  A second ops call is unnecessary, as rww was obviously aware of the situation.  I will be talking to him and explaining this as soon as I get the new guy into -ot so he's not being offtopic (I only have two hands).
[04:39] <daftykins> being a regular volunteer should mean you don't get pushed around with a kick when something needs explaining
[04:39] <daftykins> perhaps you should reconsider using that as a tactic in future, given it's overly heavy handed
[04:39] <Flannel> daftykins: Actually, it's been pointed out to me that there was no second ops call.  So, I will be explaining my error to cfhowlett once I can.
[04:41] <Flannel> daftykins: However, with regard to your "regular explainer means special privledges", that's absolutely false.  No one has a longer leash than default (although some people do have shorter ones), not even ops.
[04:41] <daftykins> that's a policy mistake
[04:41] <Flannel> But, again, this particular case was an error on my part.  And as soon as we finish this conversation I'll be spending some time talking to cfhowlett about it.
[04:42] <daftykins> looks like he's quit, probably less inclined to want to be somewhere helping when some heavy-handed op likes to kick before thinking
[04:43] <Unit193> Wow, that's...Rich.  He's presuming someone hasn't already spoken to him before too.
[04:43] <Flannel> Just drop it.
[04:45] <Unit193> Heh, of course, nothing to drop.
[19:10] <ikonia> hello Chicken_Wrap
[19:10] <Chicken_Wrap> Hello, ikonia.
[19:10] <ikonia> what's up, how can we help today ?
[19:10] <Chicken_Wrap> Just want to know how I can get unbanned.
[19:10] <ikonia> oh, you're banned, from where ?
[19:10] <Chicken_Wrap> #ubuntu.
[19:10] <ikonia> you appear to be in #ubuntu
[19:11] <k1l> hi Chicken_Wrap
[19:11] <Chicken_Wrap> Yes, but I can't send any messages.
[19:11] <Chicken_Wrap> So I'm assuming that I'm muted or something along those lines.
[19:11] <Chicken_Wrap> hello, k1l.
[19:11] <Chicken_Wrap> *Hello.
[19:11] <k1l> i muted you last time since you did not stop besides beeing asked several times.
[19:11] <ikonia> lets have a look, hang on a moment please
[19:11] <ikonia> ahh k1l knows, I'll leave it to him
[19:11] <Chicken_Wrap> Not stop what?
[19:11] <genii> 70802
[19:11] <k1l> i told you in pm that you are muted and to come here when you want to use #ubuntu in a proper way again.
[19:11] <Chicken_Wrap> yes, but what did I do wrong in #ubuntu?
[19:12] <Chicken_Wrap> *Yes.
[19:12] <k1l> Chicken_Wrap: some users were making drama about warez. all were asked to stop several times. then you jumped the train and started again with that topic
[19:13] <Chicken_Wrap> I didn't get the memo. And I only asked for a definition.
[19:14] <k1l> #ubuntu is for technical ubuntu support only. we cant have regular chat in there. with 1800 users no support would be possible then
[19:14] <Chicken_Wrap> Fair enough.
[19:14] <k1l> Chicken_Wrap: and you did get the memo. it was 3-4 minutes 3 ops asking the people to stop.
[19:15] <k1l> (and muting other users as well)
[19:15] <Chicken_Wrap> k1l: I saw someone was banned, so I checked who was banned and what he/she had said.
[19:15] <Chicken_Wrap> Seeing that he/she brought up warez, I asked for what it meant from there.
[19:15] <Chicken_Wrap> I wasn't paying attention to the general chatter.
[19:16] <k1l> !guidelines
[19:16] <k1l> please make sure to read the guidelines. #ubuntu is really focused on support only. we have #ubuntu-offtopic for the other chat (like what warez is as a definition)
[19:17] <Chicken_Wrap> So it's 100% zero chatter unrelated to Ubuntu?
[19:18] <k1l> for chatter we have #ubuntu-offtopic
[19:18] <Chicken_Wrap> Alright. Thanks for your time.
[19:18] <k1l> so if you read the guidelines and think you can follow them in future i can remove the mute.
[21:07] <Pici> honk
[21:28] <Myrtti> toot


[12:14] <mpt> nooooooooo
[12:37] <mpt> Weekend, all
[12:40] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  make spec URL field a reasonable length and fix the bug causing an exception to be raised when assigning specs to milestones, which could happen when two different spec targets had a target of the same name (patch-2559<EMAIL_ADDRESS>[02:55] <dilys> Merge to<EMAIL_ADDRESS>Cherry pick patch-2558 into production 1.35 (patch-19<EMAIL_ADDRESS><EMAIL_ADDRESS>[06:34] <Keybuk> try:
[06:34] <Keybuk>     os.unlink(filename)
[06:34] <Keybuk> except OSError, e:
[06:34] <Keybuk>     if e.errno != errno.ENOENT:
[06:34] <Keybuk>         raise
[06:34] <Keybuk> THIS IS SO WRONG
[06:34] <Keybuk> ENoEnt (or even better, NotFoundError or something) should be an Exception sub-class of OSError
[07:08] <stub> Yup. Sucks.
[07:26] <Keybuk> the nice thing about xml is how easy it is to use
[07:27] <Keybuk> doc = xml.dom.minidom.getDOMImplementation().createDocument(NAMESPACE, ROOT_NODE, xml.dom.minidom.getDOCImplementation().createDocumentType(ROOT_NODE, None, DOC_TYPE))
[07:27] <Keybuk> what could be easier?! :-/
[07:52] <stub> Keybuk: elementree or one of the other XML tools that doesn't blindly follow idiotic standards like DOM or SAX
[07:53] <Keybuk> I found elementtree just as bad for constructing XML
[08:01] <stub> root = Element('root')
[08:01] <stub> child = SubElement(root, 'child')
[08:01] <stub> child.set('attribute','value')
[08:01] <stub> tree = ElementTree(root)
[08:01] <stub> tree.write('output.xml')
[08:04] <Keybuk> except that then doesn't have the right namespaces and stuff
[08:04] <Keybuk> and once you add those, it becomes exactly as hard as DOM
[08:06] <stub> root = Element('{%s}root' % NS)
[08:06] <stub> child = SubElement(root, '{%s}child' % NS)
[08:06] <stub> child.set('{%s}attribute' % NS,'value')
[08:06] <stub> tree = ElementTree(root)
[08:06] <stub> tree.write('output.xml')
[08:07] <Keybuk> and thus proving my point <g>
[08:07] <Keybuk> that's actually easier in DOM because you can just use ns.createElement
[08:07] <Keybuk> which returns an element already in the right namespace, with whatever prefix you assigned
[08:08] <Keybuk> (and you forgot there to set the xmlns:$NS attribute :p
[08:13] <stub> xmlns attribute is added automatically.
[08:13] <Keybuk> where does it get the value from?
[08:14] <stub> I do think it would be nicer if he hadn't followed James Clark's crackful idea of sticking the namespace URI in curly brackets though instead of using an extra parameter for the namespace
[08:15] <stub> It keeps track of the namespace URIs being used by elements you add. It then assigns prefixes and adds in the xmns boilerplate
[08:15] <Keybuk> see, then you end up having to try and persuade it what prefix you wanted and stuff <g>
[08:15] <stub> I don't know if it is easy to specify your own prefix in case you want human readable XML
[08:16] <Keybuk> I've yet to see someone really come up with a nice way of making xml
[08:17] <Keybuk> I tend to abstract it into three functions
[08:17] <Keybuk> set_text(node, text), set_attribute(node, attr, value), set_pair(node, key, value)
[08:17] <Keybuk> with equivalent get functions
[08:17] <stub> Ahh.... there appears to be a newer way of doing namespaces in elementtree...
[08:17] <Keybuk> the first does "la la la" inside node, removing any existing text
[08:17] <Keybuk> the second does foo="la la la" inside node
[08:18] <Keybuk> and the third does <foo>la la la</foo> inside node
[08:18] <Keybuk> and basically go frm there
[08:18] <Keybuk> and they're always about 5 lines long each, no matter which toolkit I use :-/
[08:20] <stub> hmm... false lead.
[08:23] <stub> http://www.tothink.com/python/ElementBuilder/ perhaps
[08:27] <stub> from elementtree.ElementTree import ElementTree, SubElement, Element, QName
[08:27] <stub> NS = 'whatever'
[08:27] <stub> root = Element(QName(NS, 'root'))
[08:27] <stub> child = SubElement(root, QName(NS, 'child'))
[08:27] <stub> child.set(QName(NS, 'attribute'), 'value')
[08:27] <stub> tree = ElementTree(root)
[08:27] <stub> tree.write('output.xml')
[08:27] <stub> Looks like enough people bitched to add support ;)
[10:38] <mdke> is there any way to search templates in rosetta?
[11:51] <zygis> hi
[11:52] <zygis> I've done a funny discovery when registering myself in launchpad
[11:53] <zygis> found that my wiki page url would be https://wiki.ubuntu.com/ygimantasBeruka2 instead of https://wiki.ubuntu.com/ygimantasBeruka
[11:54] <zygis> did a little research and found a bug (I guess)
[11:54] <zygis> somehow account with my name was registered in launchpad before I did it
[11:54] <zygis> see https://launchpad.net/people/uid0-tuxfamily
[11:55] <zygis> (I had an email<EMAIL_ADDRESS>uhm... two years ago)
[11:57] <zygis> how launchpad managed to register an account automatically with it?
[12:00] <zygis> wiki page under different URL, or disabled upload of hackergotchi isn't bugs of very high importance
[12:01] <zygis> but still, it's a bug :)
[12:18] <zygis> btw, wherever I go in rosetta, I get "You are not an official translator for this file."
[12:19] <zygis> what do I have to do to convince Rossetta, that I *am* the official translator?
[12:19] <mdke> zygis, you need to be a member of the relevant translator group for that language
[12:20] <mdke> if it is an Ubuntu file at least
[12:21] <zygis> well, I've just created ubuntu-l10n-lt group an hour ago
[12:22] <zygis> when it will show up in this list https://launchpad.net/rosetta/groups/ubuntu-translators/ ?
[12:24] <zygis> there's a button '
[12:24] <zygis> Appoint New Translator', who can use it? It seems that I do not have permission to use it
[12:29] <mdke> zygis, you need to ask the rosetta administrators to arrange the group
[04:44] <segfault> why the exported PO files from rosetta take so long to arrive?
[04:49] <salgado> segfault: I'm not sure, but could be because the queue is full or it's not processed very often
[04:55] <segfault> ok
[05:21] <Zoohouse> I have a question. I don't want my team to be called by my name. Is there a way I can dismantal the team I just made and remake it with another name?
[05:31] <salgado> Zoohouse: it used to be possible to rename teams, but someone removed that feature.
[05:31] <salgado> I'l file a bug on that, and if nobody complains I'll put that feature back
[05:32] <Zoohouse> ok
[05:32] <Zoohouse> Another thing
[05:33] <Zoohouse> salgado: I just made a team for artwork
[05:33] <Zoohouse> Can I upload a icon set so the team can work on?
[05:33] <Zoohouse> a package
[05:35] <salgado> Zoohouse: that's not possible yet
[05:37] <Zoohouse> Ok..
[05:39] <Zoohouse> How do I add a support ticket...
[05:41] <Zoohouse> Is launchpad still under development?
[05:41] <salgado> Zoohouse: yes, it's still under heavy development
[05:42] <Zoohouse> ah ok.. I thought It was a finished product and was woundering why some of the links were dead :D
[05:54] <Zoohouse> I just created a new product. How do I link it to the team?
[06:05] <Zoohouse> And I cant log in as admin of my product...
[07:01] <eruin> any idea why https://launchpad.net/distros/ubuntu/breezy/+sources/gdm/+pots/gdm/nb/+translate doesn't work?
[07:02] <eruin> could launchpad be configured to output more verbose errors?
[07:03] <salgado> eruin, has this error happened now?
[07:04] <eruin> it happens on a few of the nb locale sections I use
[07:04] <eruin> and yes
[07:08] <salgado> eruin, usually, when you have a URL that always raises a system error, you can just paste that URL in the bug report and say it's a system error
[07:08] <salgado> I'm filing that bug now, and I'll paste the full error message
[07:10] <eruin> okay, I'll do that in the future :)
[07:10] <eruin> thanks
[07:11] <eruin> By the way,who's responsible for the apps availablefor translation in rosetta?
[07:11] <salgado> eruin, it seems to happen for both nb and nn, have you noticed that?
[07:11] <eruin> seeing as breezy has serpentine 0.6.3 (where 0.6.2 intoroduced i18n), wouldn't it make sense to make a template available?
[07:11] <eruin> salgado, I'm not a nn translator, so no ;-)
[07:12] <salgado> eruin, I guess jordi is responsible for that
[07:20] <eruin> I guess I'll ping him after the weekend
[07:20] <eruin> we only have until the 10th to finish translations according to pitti ;o
[07:22] <salgado> eruin, you can mail the rosetta-users mailing list, if you haven't done so yet
[07:27] <eruin> hmm, there seems to already be traffic about it on the list, and jordi replied that he had added it to the queue
[07:27] <eruin> that was on sep 22
[08:59] <fabbione> hmmmm
[08:59] <fabbione> guys.. how do i add UBZ event to my calendar?
[08:59] <fabbione> shouldn't be some kind of autolink thingy?
[08:59] <fabbione>  Merged Calendar for Fabio Massimo Di Nitto <-
[08:59] <fabbione> ?`
[09:02] <fabbione> Ubuntu Below Zero: 2005-10-09 to 2006-11-18 <- this is going to be a veeeeeeeeeery loooooooong meeting...
[09:02] <Nafallo> lol
[09:03] <fabbione> no hold on!!!!
[09:03] <fabbione> it's going to start in 8 days!!!
[09:04] <spacey> i tried to plan it aswall in launchpad
[09:04] <spacey> not really obvious and not easy to set
[09:04] <spacey> to say the least
[09:07] <fabbione> i can't find a way to link UBZ into my calendar
[09:07] <fabbione> and of course the sprint page says nobody will be there
[09:07] <fabbione> dude.. launchpad is more fun than Q3A
[09:08] <fabbione> the dungeon is more complex and there are more levels of difficulties..
[09:08] <fabbione> including 20 monsters^Wdevelopers ready to hunt me down at the end of each of level
[10:09] <\sh> hmmm...


[13:49] <k1l_> nope
[14:11] <SonikkuAmerica> lolwat
[22:57] <tanja_> is there ops online?
[23:08] <tanja_> The person popopo is messaging me bad things to make a negative tone in the #ubuntu. I have taken screenshoot of his messages including whois info to forward if needed
[23:17] <SonikkuAmerica> I'm not an op in that channel, but thanks for stopping by...
[23:17] <SonikkuAmerica> Is it in channel or in PM?
[23:19] <tanja_> he pm'ed me in the middle out of nowhere
[23:19] <tanja_> and the message was that the person there were helping me in the channel said really bad things about me and that were not true
[23:20] <SonikkuAmerica> Oh. Just ignore it then.
[23:20] <tanja_> SonikkuAmerica: kk
[23:20] <SonikkuAmerica> Anything else?
[23:21] <tanja_> no and thank just wanted to report it if you guys wanted the log and whois info because of the situation
[23:21] <tanja_> *thanks
[23:22] <SonikkuAmerica> OK. Let us know if it keeps up. You can go ahead and /part the channel.


[07:00] <dholbach> good morning
[23:43] <Unit193> barry: Was it this Monday I was supposed to ping you? ;)


[00:01] <mwhudson> root@localhost:~# start plymouth
[00:01] <mwhudson> plymouth start/running, process 1127
[00:01] <mwhudson> root@localhost:~# plymouth --ping
[00:01] <mwhudson> root@localhost:~# echo $?
[00:01] <mwhudson> 0
[00:01] <mwhudson> seems better
[00:30] <straemer> Hey, I'm interested in doing some bug-fixing for the ubuntu one music android app. Would anyone be able to show me where to get started on that?
[00:31] <sarnold> straemer: (guessing) try #ubuntuone  ?
[00:33] <straemer> sarnold: I think that's a support channel
[00:33] <sarnold> straemer: ah :) darn, sorry
[01:07] <mwhudson> ok now i'm reading the mountall source
[01:07] <mwhudson> time to get out of the rabbit hole i think
[04:02] <pitti> Good morning
[06:03] <mlankhorst> morningg
[06:15] <infinity> didrocks: The new webapps-application pulls a few things into main without an MIR.  Was someone going to do something about that?
[06:16] <infinity> didrocks: Specifically gjs and mozjs.
[06:16] <didrocks> infinity: we are going to demote all those scripts to universe AFAIK
[06:17] <infinity> didrocks: "All those scripts"?
[06:17] <didrocks> so I guess webapps-application is part of it
[06:17] <infinity> didrocks: As in, unseed unity-webapps-common?
[06:17] <didrocks> infinity: indeed, I still need to do a final check with robru, but that's what I understood
[06:18] <infinity> didrocks: Alright.  Well, as soon as you know, please yank it from the seeds and I'll demote with extreme prejudice. ;)
[06:18] <didrocks> infinity: ahah, I'll maybe take that demoting pleasure for myself TBH. This has been such a pain :p
[06:19] <robru> didrocks: infinity: hi
[06:20] <didrocks> oh, a robru!
[06:20] <robru> I don't know about whether or not this stuff needs to be in main. that's a strategical question that you'd need to ask to somebody who makes plans. I just do what people tell me
[06:21] <didrocks> robru: so, IIRC, the plan of record is to have all the scripts in universe, right?
[06:21] <didrocks> robru: as we even don't install the firefox nor the chromium extension by default
[06:21] <robru> didrocks: is that so? but I thought we were prompting people to install webapps by default
[06:23] <robru> didrocks: maybe vrruiz is a better person to ask about this.
[06:23] <didrocks> robru: I'm still lost in all that maze of webapps*, where is the firefox extension?
[06:23] <robru> didrocks: I don't think the browser extensions are enabled for daily release yet, only CI
[06:23] <didrocks> robru: yeah, I just need the name of the extension :)
[06:24] <didrocks> robru: IIRC, the goal was: extension in main, all scripts in universe (including -common)
[06:24] <robru> didrocks: ok, so it's unity-firefox-extension and unity-chromium-extension
[06:25] <didrocks> ok, the extension is still in main for firefox
[06:25] <robru> didrocks: as long as we end up in a situation where the default ubuntu install will prompt users to install webapps, then I think we're ok. I don't personally have any stake in whether the apps are living in main or universe.
[06:25]  * robru just wants this nightmare to end
[06:25] <didrocks> ah, there are those desktop files we install by default though :/
[06:25] <didrocks> robru: I'm afraid that -common still need to be in main for now
[06:26] <robru> didrocks: just amazon and ubuntuone-music right?
[06:26] <didrocks> robru: right
[06:26] <robru> didrocks: so it sounds like those .desktop files need to be in a different package so that we don't bring in gjs into main with -common package
[06:27] <didrocks> robru: gjs is used for your lintian script?
[06:28] <robru> didrocks: nope, gjs is used for style_checker.js, which is a wrapper around jslint. that's different than my linter script (jslint is linting js syntax, my linter is linting the packages, ensuring that translations are present, etc.)
[06:28] <didrocks> robru: style_checker.js is run during package build?
[06:28] <robru> didrocks: yeah
[06:29] <robru> didrocks: yeah, there's no way around depending on gjs in -common, that's the closest thing we have to test coverage at the moment.
[06:30] <didrocks> robru: in fact, I think we should move them
[06:30] <didrocks> robru: scripts/third_party/jslint.js usr/share/unity-webapps/tools/
[06:30] <didrocks> common/rules.mk usr/share/unity-webapps/
[06:30] <dholbach> good morning
[06:31] <didrocks> those should be move to another package (same source)
[06:31] <didrocks> but another binary
[06:31] <robru> didrocks: ok, that can be done
[06:31] <didrocks> we can call it unity-webapps-script-build
[06:31] <didrocks> robru: or any better word ^
[06:31] <robru> didrocks: but keep in mind, either the -common package will have to depend on it, or we'll have to edit all 41 apps to depend on this new package too
[06:31] <didrocks> having all the script biuld-dep on it
[06:31] <didrocks> (yeah, I know :/)
[06:32] <didrocks> robru: but you have sed foo now :)
[06:32] <robru> didrocks: unity-webapps-dev
[06:32] <didrocks> robru: excellent :)
[06:32] <didrocks> and this one has the gjs dep
[06:32] <didrocks> will be in universe
[06:32] <didrocks> with all the scripts in universe
[06:32] <didrocks> robru: do you think you'll have time to do that? any idea once this can be done (so that we can clear the mismatch components)
[06:33] <robru> didrocks: if you make me push 41 MPs I am going to scream. I'll just commit those packaging changes directly to trunk
[06:33] <didrocks> (this has the benefit to not ship -dev content on user's machine as well)
[06:33] <didrocks> robru: direct commit is fine :)
[06:33] <didrocks> hey dholbach!
[06:33] <dholbach> hey didrocks
[06:33] <robru> didrocks: I can do that right now.
[06:33] <didrocks> robru: \o/
[06:33] <didrocks> robru: we are *almost* there!
[06:34] <robru> didrocks: ;-)
[06:34] <didrocks> robru: btw, I relaunched the daily for webapps
[06:34] <didrocks> robru: as I relaxed now the constrain to have the bootstrap commit message for distro
[06:34] <robru> didrocks: this is going to cause another bootstrapping nightmare, isn't it? we'll need unity-webapps-dev pushed everywhere
[06:35] <robru> didrocks: I saw your improvements to the changelog generation, very nice.
[06:35] <didrocks> robru: well, I'll handle it, it's juts an upload to distro and to the ppa
[06:35] <didrocks> robru: great ;)
[06:35] <didrocks> robru: just put this unity-webapps-dev to review please :)
[06:35] <robru> didrocks: right
[06:37] <infinity> didrocks, robru: Thanks for the prompt handling.  Maybe you can teach the server team how to deal with component mismatches. ;)
[06:39] <didrocks> infinity: ahah, yw! Sorry for introducing it first :-)
[06:45] <robru> didrocks: https://code.launchpad.net/~robru/webapps-applications/dev/+merge/163848
[06:48] <robru> didrocks: wait, build just failed locally. bah
[06:49] <didrocks> robru: commenting
[06:51] <robru> didrocks: ugh, I'm confused. my changes are causing dh_install --fail-missing to fail. I have no idea why... it says utils.js is not installed to anywhere, but I didn't change anything about utils.js (and trunk builds fine)
[06:51] <robru> didrocks: and I added a line to unity-webapps-common.install to explicitly install it, but it doesn't help.
[06:52] <didrocks> robru: I smell you forgot a bzr add unity-webapps-dev.install :)
[06:52] <robru> didrocks: nope, if that were the case it'd be complaining about the files that go in the -dev package. it's complaining about files that should be in the -common package
[06:54] <didrocks> robru: let me bzr branch
[06:54] <robru> didrocks: please take my branch and do a 'bzr bd' in it, total mystery to me
[06:55] <didrocks> robru: grep utils.js debian/*
[06:55] <didrocks> -> nothing
[06:56] <didrocks> robru: shouldn't you list usr/share/unity-webapps/userscripts/common/ in -common.install?
[06:56] <robru> didrocks: yeah, well, build trunk and it works!
[06:56] <robru> didrocks: but I added that line, like you would obviously expect to find, and it didn't make a difference.
[06:57] <didrocks> robru: trunk built because your .install file was not that relevant (no debian/tmp for just one binary)
[06:58] <didrocks> robru: added usr/share/unity-webapps/userscripts/common to debian/unity-webapps-common.install works here
[06:58] <didrocks> the build pass then, and all files that we need to install are installed :)
[07:00] <robru> didrocks: no idea
[07:00] <robru> didrocks: anyway, pushed. please approve
[07:01] <didrocks> robru: please set to UNRELEASED
[07:01] <didrocks> robru: not saucy
[07:01] <didrocks> in debian/changelog
[07:01] <didrocks> other than that, looking good
[07:02] <didrocks> (and wrap to 80 characters :p)
[07:02] <didrocks> robru: I wonder why emacs didn't forbid you to save the file with all your automation :-)
[07:02] <robru> didrocks: rushing
[07:02] <robru> didrocks: it does display the long line with big angry red letters though
[07:04] <didrocks> ahah ;)
[07:06] <didrocks> robru: thanks! approving now
[07:06] <didrocks> robru: once it's merged, I'll upload to saucy and the ppa for the boostrap
[07:06] <didrocks> bootstrap*
[07:06] <robru> didrocks: should I wait for you to be ready before pushing commits to the webapps trunks? or can I do that now
[07:06] <robru> ?
[07:07] <didrocks> robru: well, just show a diff and I will tell you yes/no, then, just push :)
[07:07] <didrocks> robru: it's just about appending on build-dep I guess
[07:07] <robru> didrocks: I am literally just going go s/unity-webapps-common/unity-webapps-dev in the control files
[07:08] <didrocks> robru: you don't need -common still for the usr/share/unity-webapps/userscripts/common/* content to build the scripts?
[07:08] <didrocks> (honest question, I have no idea ;))
[07:09] <robru> didrocks: I guess so. -dev should have depended on -common though, oops ;-)
[07:09] <didrocks> robru: I came to the exact same conclusion :)
[07:09] <didrocks> robru: I aborted the merge, please push an extra rev :)
[07:09] <robru> didrocks: it's fine. I'm just pulling all the webapps branches now, once that's done I'll show you one diff and then push identical changes to all branches
[07:09] <robru> didrocks: oh, ok
[07:11] <pitti> infinity: I tried to reproduce the libsoup2.4 armhf test case failure (leading to ftbfs) on my nexus; with plain dpkg-buildpackage, with and without fakeroot, our code vs. upstream git head, etc; it always works there
[07:11] <pitti> infinity: is it possible to somehow get ssh access to a buildd-like machine?
[07:12] <pitti> mbiebl: ^ FYI (affects Debian as well)
[07:13] <infinity> cache-test: 1 error(s). Run with '-d' for details
[07:13] <infinity> FAIL: cache-test
[07:13] <infinity> ^-- If only it then DID that, so we had details in the build log...
[07:14] <robru> didrocks: http://paste.ubuntu.com/5666777/ I am going to push this to all 41 webapps branches
[07:14] <didrocks> robru: excellent :)
[07:15] <didrocks> robru: I approved your additional commit bw
[07:15] <didrocks> btw*
[07:15] <robru> didrocks: great
[07:17] <robru> didrocks: ok, pushing
[07:17] <pitti> infinity: yeah, the makefile doesn't pass that on; we can temporarily call it manually in debian/rules, but that will also just list the individual tests, not why it's failing
[07:17] <pitti> infinity: do we have a PPA where I can throw lots of test builds in, so that I don't have to clutter the actual archive?
[07:17] <pitti> (which builds arm)
[07:17] <infinity> pitti: We do, but let me give this a whirl locally first.
[07:18] <infinity> pitti: Was your nexus7 test with a buildd chroot?
[07:19] <pitti> infinity: no, just standard phablet installation
[07:19] <infinity> Is that saucy?
[07:20] <pitti> it's raring, but I got saucy's source
[07:20] <pitti> oh, I guess I should upgrade to saucy's glib
[07:20] <infinity> pitti: But not saucy's toolchain.
[07:20] <infinity> pitti: Which is gcc-4.8...
[07:20] <pitti> ack
[07:21] <infinity> pitti: Better off just grabbing the chroot tarball from LP and using that.
[07:21] <infinity> https://api.launchpad.net/1.0/ubuntu/saucy/armhf
[07:21] <pitti> oh, handy!
[07:22] <infinity> Just untar that, fix resolv.conf, mount /proc and /dev/pts, dist-upgrade, and go to town. :P
[07:22] <infinity> Should be easier than going piecemeal on your phablet install.
[07:22] <robru> didrocks: ok, done pushing the s/-common/-dev/ change for all webapps
[07:23] <robru> didrocks: is that all you need from me? I'm thinking about going to sleep ;-)
[07:23] <didrocks> robru: excellent! as you saw, the previous daily run worked, but it's in manual publishing mode due to the packaging changes (and upstream stack, like the QA one failing)
[07:23] <infinity> pitti: Anyhow, also running here on a Panda, but I really doubt the kernel or hardware are your issue here.
[07:23] <didrocks> robru: so I'll push -common once it's merged manually to bootstrap
[07:23] <didrocks> robru: then run the daily
[07:24] <robru> didrocks: you mean push -dev, but yeah
[07:24] <didrocks> robru: then manually publish (as the failure from QA stack doesn't impact us)
[07:24] <didrocks> robru: yeah, the source package containing both :)
[07:24] <didrocks> robru: and I think we'll be done then! :-)
[07:24] <robru> didrocks: the source package is called webapps-applications. I wonder if it would be too much of a pain to name that more meaningfully
[07:25] <didrocks> robru: yeah, I'm also trying to bzr branch lp:<something>-common, but let's keep it that way for now
[07:25] <robru> yeah, we would need to rename the lp project and everything, total pain
[07:25] <didrocks> yep
[07:26] <robru> didrocks: ok, g'night then.
[07:26] <didrocks> robru: enjoy your (relatively early this time ;)) night!
[07:40] <pitti> meh, no overlayfs or aufs on nexus kernel?
[07:40]  * pitti repacks the unpacked chroot to not have a top-level directory then, to use it in tarball mode
[07:43] <infinity> pitti: FFS, it didn't fail here.
[07:43] <infinity> My test chroot wasn't entirely clean, but...
[07:54] <pitti> aah, now I have schroot -c saucy working on the nexus at last
[07:54] <tjaalton> siretart: hey, any reason not to sync libva & intel-vaapi-driver from experimental for saucy? I have gstreamer-vaapi updated for gst1.0 and would like to test these on haswell too
[08:20] <infinity> pitti: Ah, the cache test failure is intermittent.  Re-running make check, I tripped it.
[08:20] <pitti> ah, it seemed to happen fairly consistently on the buildds in the last few builds
[08:20] <infinity> pitti: And, indeed, a retry on the buildd succeeded.
[08:20] <pitti> infinity: I now have sbuild etc. set up, libsoup building ATM
[08:20] <pitti> infinity: oh, handy; I'll still see if I can reproduce it here
[08:20] <pitti> buildds are pandas, right?
[08:21] <pitti> (i. e. slightly slower than nexus 7)
[08:21] <infinity> pitti: http://paste.ubuntu.com/5666948/
[08:22] <infinity> pitti: buildds are Pandas, yes.
[08:22] <pitti> "leaked GInputStream!
[08:22] <infinity> pitti: Took me about 10 tries to get that failure.
[08:23] <infinity> pitti: So, it could just be racy, and slow machines trip it more easily.
[08:23] <infinity> pitti: Which would explain my slightly faster Panda doing better than the slower ones in the DC.
[08:23] <infinity> pitti: And Debian's much slower buildds always failing.
[08:23] <infinity> pitti: And x86/ppc having no issues.
[08:23] <infinity> (ie: it might not be ARM-specific)
[08:23]  * pitti runs (set -e; for i in `seq 50`; do echo "[08:25]  * pitti runs again with a find / in the background
[08:25] <infinity> pitti: Same failure on mipsel (which is also notoriously slow) seems to back up my wild guess.
[08:25] <pitti> infinity: ack, very much sounds like a race; thanks for confirming!
[08:25] <infinity> pitti: Try to reproduce it on eder.debian.org ... No time like the present, doko's building GCC in the background. :P
[08:27] <seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=698305 ?
[08:27] <seb128> pitti, just pointing the bug for reference, it has no info/patch/...
[08:27] <pitti> yep
[08:28] <pitti> seb128: that's the one I have chased for the past two hours now..
[08:28] <seb128> pitti, thanks for looking into that!
[08:28] <seb128> pitti, I tried for a bit before pinged you, but had no luck :/
[08:33] <mbiebl> pitti: since you are a DD, you might try http://db.debian.org/machines.cgi (which I'm pretty sure you know about)
[08:33] <mbiebl> iirc, you should now be able to install b-deps without having to contact DSA
[08:33] <pitti> mbiebl: yes, I do (eder seems appropriate, it's really slow)
[08:34] <mbiebl> even for a small lib like libsoup2.4, ouch
[08:35] <pitti> I tried on my nexus7 with letting a cat /dev/urandom > /dev/null and a tar cj /usr running in the background, doing "echo 3 > /proc/sys/vm/drop_caches" all the time, and running the test endlessly, and it survived > 250 iterations so far
[08:44] <ogra_> pitti, cant you do that easier via sysctl (cache_timeout or so) instead of always echoing into /proc ?
[08:44] <ev> Daviey: it's not. Could stick it in on Thursday if you think we couldn't settle that one with a phone call?
[08:45] <Daviey> ev: I don't think it needs a dedicated session or anything.  Just need to work out, *if* it is worth doing .. *how* to do it.. and *who* to do it :)
[08:46] <rbasak> I'd love to see it. I think it'd be useful. Right now the best information we get is from bug reports, and most of those are from people who have misconfigured things and then send us reports for maintainer script failures.
[08:46] <rbasak> No idea *how* though.
[08:47] <Daviey> rbasak: Right, last time i spoke to ev about this.. we were interested in running it during the dev cycle, but turning off by default on production
[08:47] <rbasak> And many server operators may prefer not to send us anything from production servers.
[08:47] <Daviey> rbasak: do you think people would be happy running this on production servers?
[08:47] <rbasak> Right - thanks makes sense, and would be a great start.
[08:47] <rbasak> I think most people running production servers would want to vet reports, but wouldn't object if they had the option of sending reports.
[08:47] <rbasak> Eg. how about a CLI with a prompt on motd if there's pending stuff in /var/crash?
[08:48] <Daviey> That actually seems reasonable middleground.. :)
[08:48] <rbasak> A "talk me through it CLI" like ubuntu-bug
[08:48] <Daviey> maybe a session is warranted.. but our schedule is already full. Ugh
[08:49]  * Daviey suspects we'll need a third track next time.
[08:49] <rbasak> I think this is the sort of case where we really want an ML discussion thread first.
[08:49] <rbasak> Not sure we'd gain much from a session as-is.
[08:49] <ev> Daviey: we could just schedule a google hangout out of band
[08:49] <Daviey> rbasak: Fancy kicking that off?
[08:50] <ev> or that :)
[08:50] <Daviey> ev: that sounds crazy enough that it might just work.
[08:50] <rbasak> Sure. Give me a day though - I've some errands to run before vUDS.
[08:50] <Daviey> rbasak: thanks :)
[08:51] <mlankhorst> could one of the sru admins accept all the xorg related packages in https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text= ?
[08:55] <siretart> tjaalton: no, please do. I just don't have the time and ressources to actually test them right now, but they should be good for saucy!
[08:55] <Daviey> mlankhorst: is this the tracking bug 1177679?
[08:56] <tjaalton> siretart: one glitch I found is that libva-dev probably needs to depend on libva-drm1 too, but we can fix that later
[08:56] <tjaalton> siretart: but yeah, I'll sync the current versions, thanks
[08:56] <siretart> tjaalton: well, patches, as always, are very welcome  :-)
[08:56] <tjaalton> :)
[08:57] <mlankhorst> Daviey: yeah
[09:00] <Daviey> mlankhorst: I think the bug report probably needs expansion TBH.  FOllowing the SRU template would be helpful, and linking to related discussion on the xserver ennoblement agreements made already?
[09:01] <mlankhorst> Daviey: lts-quantal didn't even have a tracking bug at all
[09:01] <mlankhorst> and it's pretty much s/quantal/raring s/ltsq/ltsr/
[09:02] <Daviey> mlankhorst: Okay, I wasn't involved in that.  Maybe ping the person that handled that?
[09:03] <mlankhorst> Daviey: code is at https://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/files running 'lts-stack raring' in an empty directory on raring grabs all the right versions. rerunning on precise in that directory with dev tools installed will make all the packages
[09:06] <ev> rsalveti, apw: mornin'! What's the latest on the grouper kernel? Are you still fighting gcc bugs, or was this an issue with the kernel config?
[09:06] <mlankhorst> but there is no way for this to break existing things anyway, they're all new packages
[09:13] <Laney> mardy: I hear you want to hear about bugs like bug #1180297 :-)
[09:14] <mardy> Laney: in a way, yes :-)
[09:17] <mardy> Laney: damn, Facebook is redirecting to plain http again :-(
[09:17] <apw> ev, it was an interaction between the kernel and compiler, who is to blame is unresolved, but the kernel in the archive is bootable
[09:20] <ev> apw: oh? I hadn't noticed a new upload in saucy-changes
[09:20] <ev> weird
[09:20] <ev> I'll give it a bash today
[09:20] <ev> thanks
[09:21] <apw> ev, hmmmm maybe i am getting them all the different versions mixed up
[09:22] <ev> nexus 7 :)
[09:22] <cjwatson> That'd be "grouper"
[09:23] <infinity> It was mako and/or manta that we were fiddling with gcc-4.8 issues on, wasn't it?
[09:23] <infinity> Or did grouper suffer the same issue and need a rebuild?
[09:38] <seb128> pitti, can you see https://code.launchpad.net/~nottheoilrig/ubuntu/quantal/python-gnutls/fix-for-1013798/+merge/154767 as merged? (went in quantal:  https://launchpad.net/ubuntu/+source/python-gnutls/1.2.4-1ubuntu0.1à
[09:38] <pitti> seb128: done
[09:39] <seb128> pitti, danke
[09:52] <pitti> infinity: sheesh -- now that eder finally built that thing, "cache-test: OK" *grumpf*; but i'll try some iterations
[09:59] <infinity> pitti: Hahaha.  D'oh.
[09:59] <seb128> pitti, can you reject https://code.launchpad.net/~vandersonmr/gnome-screenshot/bugfix1169904/+merge/161262 ?
[09:59] <pitti> done
[09:59] <seb128> thanks
[10:00] <pitti> ok, it does reproduce quite often on eder
[11:19] <tkamppeter> Any Upstart expert around? Can I start daemons on-demand with upstart, for example triggered by an access to a given port (like xinetd does) or to a given domain socket?
[11:19] <tkamppeter> systemd is capable of this.
[11:20] <doko> jodh, xnox: ^^^
[11:21] <jodh> tkamppeter: see socket-event(7)
[11:27] <tkamppeter> jodh, so if CUPS would have "start on socket PROTO=unix /var/run/cups/cups.sock, a client ("lpr" or anything else using libcups2) accessing /var/run/cups/cups.sock would trigger the start of cupsd and the access gets processed by cupsd?
[11:32] <jodh> tkamppeter: "yes", but cupsd would need to be modified such that it does not call socket() et al itself - it would simply need to call accept(2) on the socket fd passed to it via the UPSTART_FDS env var. I believe systemd requires something similar.
[11:33] <pitti> something like http://pkgs.fedoraproject.org/cgit/cups.git/tree/cups-systemd-socket.patch
[11:43] <tkamppeter> pitti, thanks.
[11:43] <tkamppeter> jodh, can you have a look into patch and see whether this can also be used with Upstart?
[11:45] <rbasak> Looks like the patch is very systemd specific, but the general mechanism is the same.
[11:48] <seb128> cjwatson, infinity: is https://launchpadlibrarian.net/138772411/saucy.debdiff fine to sponsor (just asking in case you have another upload planned for live-build)?
[11:49] <seb128> (to sru for raring as well)
[11:49] <cjwatson> seb128: sure
[11:49] <seb128> cjwatson, thanks
[11:56] <tkamppeter> rbasak, pitti, could someone of you help me to add upstart support to the patch?\
[11:56] <pitti> seb128: I sent some analysis to gnome bug 698305, but I stop at this now; at this point I really don't understand glib weak refs and threading well enough, and as we can just give back the package it's not immediately urgent
[11:56] <tkamppeter> pitti, is there also a patch for the cupsd to stop after a certain time being idle?
[11:56] <pitti> tkamppeter: you can check http://pkgs.fedoraproject.org/cgit/cups.git/tree/, but I don't think there is
[11:57] <pitti> you usually don't want cups to stop
[11:57] <seb128> pitti, ok, thanks ... did you manage to get it to build after retries? we had a few on the buildds and it never went through
[11:57] <pitti> and you usually don't want to start cups at the time when you need it first, but much earlier
[11:57] <pitti> as remote printer detection will just take a while (DNS-SD announcements are only sent every 30 seconds or so)
[11:57] <pitti> seb128: yes, infinity gave it back once, and it's built now
[11:57] <rbasak> It looks non-trivial to me :(
[11:58] <seb128> pitti, great, thanks again!
[11:59] <rbasak> Although from that patch it looks like systemd provides a library as a general mechanism. It might be worth considering if it's worth implementing an equivalent compatibility library that supports upstart's socket bridge that could be used in place of it and support the same API. I'm not sure how likely systemd upstream are to change the API though. But it would be nice to easily support anything that supports systemd socket activation in this way. Bu
[12:01] <tkamppeter> rbasak, pitti, we had discussion about starting cupsd and cups-browsed on-demand on mobile devices yesterday on the OpenPrinting Summit.
[12:02] <tkamppeter> rbasak, pitti, to save some memory, battery, resources.
[12:03] <rbasak> Is there a general Zeroconf story to fix the DNS-SD delay?
[12:09] <tkamppeter> rbasak, not AFAIK.
[12:47] <pitti> tkamppeter: yes, I think starting on demand on a mobile device is an acceptable compromise (the first time you want to print you just have to wait a bit)
[12:48] <pitti> tkamppeter: I just wouldn't do it on a desktop; I think "start cups after one minute or when requested" keeps it out of the boot path, and yet has it ready when you realistically need it
[12:49] <pitti> I guess on a mobile phone we actually do want to shut it down after some time, too
[12:49] <pitti> on a desktop one usually has swap, so if it's not being used, it just gets swapped out
[13:17] <GridCube> tedg, hello :) can you review https://wiki.ubuntu.com/GridCube/HUD_in_Xubuntu_Rationale please?
[13:19]  * tedg clicks
[13:20] <GridCube> :D thanks
[13:22] <tedg> GridCube, Looks good to me!
[13:24] <GridCube> :) excellent
[13:25] <GridCube> by the way, could you consider joining the vUDS tomorrow at 20hs UTC to follow https://blueprints.launchpad.net/xubuntu-desktop/+spec/client-xubuntu-1305-software
[13:26] <GridCube> if you cant there its no problem, but i do think you could bring some interesting help in the topic, sadly i wont be able to join :(
[13:28] <ogra_> infinity, do you think it would be possible to build udev against klibc ?
[13:37] <rsalveti> ev: for grouper it's probably a config issue still, didn't have time to investigate yet, was in vac last week
[13:41] <roadmr> Hey folks! question about SRU. I have prepared a SRU bug 1059544, added a task for the affected Ubuntu release, and uploaded a branch with a fix. I have upload rights for the package. Should I just merge and upload this to -proposed, or do I need approval from e.g. release team?
[13:52] <ev> rsalveti: *nods*
[13:55] <rbasak> roadmr: AIUI, you upload -proposed, and then it sits in Unapproved until the SRU team review the upload. But IANAUbuntuDeveloper.
[13:55] <roadmr> rbasak: thanks! well that makes sense. I'll probably do just that
[14:31] <stokachu> stgraber: did you get my ping last night?
[14:33] <stgraber> stokachu: I saw it but I'm rather busy at the moment between UDS and other tasks, will try to take a look later this week.
[14:34] <stokachu> stgraber: ok thanks
[15:36] <mpt> ev, how's the error rate recalculation going?
[16:49] <cjwatson> mlankhorst: https://launchpadlibrarian.net/139941740/buildlog_ubuntu-saucy-amd64.ubiquity_2.15.2_FAILEDTOBUILD.txt.gz - hmm, is this X's fault?
[16:57] <mlankhorst> cjwatson: seems more like a lack of root on xserver
[16:58] <cjwatson> Nothing should have changed there ... trying a local build
[17:02] <mlankhorst> but honestly I have no idea what's going on there :)
[17:03] <cjwatson> Looks like I can't check properly until the 3FP outage is sorted out
[17:12] <JordiGH> Is there a clean way to get an upstream Debian git-buildpackage archive and use it to maintain several different releases (the P, Q, and R releases) in a PPA for Ubuntu?
[17:12] <JordiGH> Something hopefully cleaner than this: https://github.com/dac922/octave-pkg-octave/network
[17:29] <rbasak> I've decided that gnome-terminal should have messaging indicator support for terminal beeps. Just putting it out there, in case someone wants to implement it :-/
[17:29] <sarnold> I'd be happy if unity would do something with the URGENT flag..
[17:31] <dobey> anyone know what the maximum value a digit in the version string of a package can have, with dpkg?
[17:31] <dobey> rbasak: i don't see how that would belong in the messaging indicator
[17:32] <rbasak> dobey: for when the thing inside the terminal signals a message with a beep.
[17:32] <dobey> rbasak: a beep is not a message. a message is a commincation from another person, to the user, in terms of the messaging indicator.
[17:32] <rbasak> But yeah, it isn't a good fit. Just solves my particular issue with missing irssi notifications.
[17:33] <dobey> write an irrssi plug-in that puts irssi in the messaging indicator?
[17:33] <rbasak> I would like to do that, yes.
[17:33] <rbasak> I'd also like one for mutt.
[17:33] <rbasak> And the terminal beep covers both cases.
[17:34] <rbasak> (and it also covers the case when I'm attached to remote screen that's running irssi without having to forward the indicator plugin somehow)
[17:37] <sarnold> rbasak: you can "this bug affects me" on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1108348 ... :D
[17:38] <rbasak> sarnold: I'm pretty sure I've seen Unity wiggle the icon on the left. But I only occasionally see it continously wiggle until cleared. I never figured out what it was supposed to do.
[17:40] <sarnold> rbasak: hrm. I've seen something vaguely similar with an update widget thingy, but it surely isn't the URGENT flag that does that, or I'd have seen it thousands of times by now...
[17:40] <rbasak> I'm not familiar enough with X and window managers to understand this stuff in detail.
[17:41] <rbasak> My gnome-terminal doesn't even beep audibly. No idea why. Probably some setting somewhere I've inherited from a dozen releases ago.
[17:41] <sarnold> hehe
[17:50] <cjwatson> dobey: Er.  9?
[17:50] <pitti> rbasak: beep?
[17:50] <cjwatson> dobey: (You may mean something else by "digit" ...)
[17:50] <pitti> rbasak: it's not supposed to beep around
[17:51] <cjwatson> dobey: If you mean a numeric part of a version, there's no upper limit
[17:52] <dobey> cjwatson: i mean i can't use the infinity symbol, and dpkg complains that it's not a "digit" if i use it for the version number
[17:52] <cjwatson> If you're trying to find a version greater than all other versions, there isn't one
[17:53] <dobey> cjwatson: so just looking for the next best thing. wasn't sure if it converted it to an int, or kept it as a string, and just complained if it wasn't between 0-9
[17:53] <cjwatson> dpkg's version comparison algorithm works on strings
[17:53] <dobey> right. would be great if it treated the infinity character correctly, though
[17:53] <cjwatson> And digits are only 0-9
[17:59] <achiang> would a patch to unity-2d that a) adds a performance optimization but b) hides it behind a gconf setting to preserve existing behavior be acceptable for a 12.04 SRU?
[18:00] <stgraber> achiang: provided very good justification for the added "feature", yes, it's something we may allow
[18:01] <achiang> stgraber: see r1157 here - https://code.launchpad.net/~unity-2d-team/unity-2d/trunk
[18:01] <achiang> stgraber: considering unity-2d is meant for low-end devices *and* this feature saves memory... it's very appropriate from my pov
[18:03]  * sarnold idly notes that Unicode Character 'RIGHT ANGLE' (221F) is greater than 'INFINITY' (221E) ...
[18:07] <stgraber> achiang: I think that's reasonable assuming you have a reasonably large pool of users who want that feature. Technically this doesn't fit in the standard SRU process but the TB can grant an exception for those.
[18:08] <achiang> stgraber: i think potential ubuntu for android customers would count as a large pool of users? :)
[18:08] <stgraber> achiang: agreed
[18:09] <xnox> achiang: a few performance related only SRU have been pushed into precise, kind of hand-in-hand with hardware enablement story of low-end devices =)
[18:09] <xnox> and scale-out workloads (well, maybe not for unity ;-) )
[18:10] <stgraber> achiang: can you send an e-mail to the TB mailing-list about this? kind of in the middle of a meeting now so it'll be the best way to remind me to do a proper review and grant an exception
[18:10] <doko> slangasek, mailx doesn't support maildir folders
[18:10] <achiang> stgraber: yes, i can send an email. is there anything else i should do, considering the code is already in unity-2d trunk?
[18:10] <slangasek> doko: is this in the context of my c-m fixing upload of lsb?
[18:11] <doko> slangasek, yes
[18:11] <stgraber> achiang: ideally a bug with a debdiff ready for upload attached to it would help
[18:11] <achiang> stgraber: ah, ok. sounds good
[18:11] <slangasek> doko: I was only restoring the previous state of affairs; if you think we should be kicking bsd-mailx out of main and replacing it with mailutils, that's fine with me, but I don't care about it and didn't want to be on the hook for an MIR
[18:12] <doko> ok
[18:12] <slangasek> doko: I would rather kick the lsb binary packages out of main than do an MIR for any of this stuff :)
[18:32] <hallyn> ubuntu@server-f94526fe-8f7f-44df-93d7-710c86eb8927:~$ pull-lp-source lxc raring-updates
[18:32] <hallyn> pull-lp-source: Error: The source package 'lxc' does not exist in the Ubuntu primary archive in raring-updates
[18:33] <hallyn> this happens to me both in canonistack instances and my home laptop...  not sure why
[18:34] <hallyn> oh i see - it shouldn't be there.  but also pull-lp-source lxc raring gives me 0.9.0-0ubuntu3.1
[18:46] <barry> bdmurray: two questions re: the eof/pyc problem.  could this be related to a missing fsync at some place?  is there any way to identify whether this is happening primarily on laptops/mobiles or always-on desktops/servers?
[18:49] <bdmurray> barry: I think we'd could only guess if it is a server based off InstallationMedia in the bug reports
[18:50] <barry> bdmurray: i just wish we had a way to reproduce it ;/
[18:53] <bdmurray> barry: maybe look for these types of bugs from ubuntu developers to see if they know more about the system that experienced it?
[18:54] <bdmurray> or active community members
[18:55] <barry> bdmurray: it's probably worth a message to ubuntu-devel anyway.  i'll write one to u-d and one to python-dev
[20:21] <bkerensa> <jono> beer hangout: everyone welcome - https://plus.google.com/hangouts/_/2e35c93b7aca2d5bc4ce8eeaae65aba61ae84205?authuser=0&hl=en
[21:42] <bdmurray> barry: maybe I should be telling people how to workaround this error since I am looking at all these bugs.  Any tips on what to say?
[21:56] <mwhudson> eh?
[21:57] <mwhudson> why is there no linux-tools-$VERSION for armhf in raring?
[21:57] <mwhudson> https://launchpad.net/ubuntu/+source/linux/3.8.0-19.30/+build/4538742
[21:59] <mwhudson> ah https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1171580
[22:00] <mwhudson> ah proposed
[22:26] <sarnold> barry: re: busted .pyc files, what feels to me more likely than a race condition is an abrupt marshal process death, before it has had an opportunity to flush stdio buffers -- or, not checking an fclose() error return value that might indicate a write error for some edge case internal to the marshaling code..
[23:37] <mwhudson> how many times does building the python2.7 debian package run test suite??
[23:42] <doko> one for the static build, one for the shared build, and one for the debug build
[23:42] <mwhudson> oh ok
[23:43] <mwhudson> i think i'm on the last one then...
[23:43] <doko> but you can disable it using DEB_BUILD_OPTIONS=nocheck