[00:36] <ndowens> I have a quick question pertaining to packaging.uscan reports that an older version is newer than what I am packaging. How would I stop that?
[00:45] <cjwatson> ndowens: You probably want to do something with uversionmangle to get the upstream version into a canonical form that uscan can compare consistently with dpkg --compare-versions, or else tighten up the regex.  See 'man uscan' for details.
[00:55] <ndowens> cjwatson: I haven't a idea on how I would mangle it
[00:56] <cjwatson> Nor do I, since you haven't given any details :-)
[00:57] <ndowens> it is from SF. it gives me that version 0.20 is newer than 1.3. I just tried to s/0.20// in uversionmangle and then it reported that 0.15 is newer
[00:57] <infinity> ndowens: What's the current package version, and the filename of the upstream version?
[00:57] <cjwatson> Full 'uscan --verbose --report' output and the current contents of debian/watch would help.
[00:58] <cjwatson> (Use paste.ubuntu.com or similar)
[00:58] <ndowens> http://dpaste.com/802354/
[00:59] <cjwatson> That's saying that 1.3 is newer than 0.20.
[01:00] <cjwatson> So I think you've misunderstood the output.
[01:01] <cjwatson> Where did the source for your 1.3 package come from, given that uscan is reporting that nothing called lince 1.3 is available on the upstream site?
[01:02] <cjwatson> (And a quick browse around sourceforge.net/projects/lince seems to confirm that)
[01:02]  * infinity guesses http://sourceforge.net/projects/lincetorrent/files/
[01:02] <ndowens> yup
[01:02] <ndowens> wait hmm
[01:02] <infinity> So, it also seems likely what your debian/watch is wrong. :P
[01:02] <cjwatson> Ah.  Fix your watch file to point to the right upstream URL then.
[01:02] <ndowens> maybe because it is named lincetorrent instead of lince
[01:02] <ndowens> duh me!
[01:02] <cjwatson> And I'd recommend naming the package after the upstream name, too.
[01:03] <ndowens> there we go
[01:03] <cjwatson> Otherwise it'll be trouble for somebody who comes along later and wants to package sourceforge.net/projects/lince
[01:03] <ndowens> There named the package lincetorrent
[01:04] <ndowens> Eventually my Debian package will be available to Ubuntu. Dwb, suppose to be in the latest version of Ubuntu coming out
[01:08] <ndowens> Maybe some people will like it. It is a terminal browser
[02:01] <bryceh> are there any archive admins available?
[02:02] <bryceh> alberto uploaded nvidia-graphics-drivers-experimental on Friday and has been in the acceptance queue over the weekend.
[02:02] <bryceh> we're going to need to rename that package as per the Tech Board decision today, so if that package is still in the queue please reject it.  We'll get a properly renamed package in soon.
[02:03] <RAOF> Will do.
[02:04] <RAOF> bryceh: That's in quantal, yes?
[02:06] <RAOF> Too late; it's accepted.
[02:07] <bryceh> ah well
[02:07] <infinity> We can, however, remove it. :P
[02:08] <RAOF> You can :)
[02:08]  * infinity does so.
[02:08] <bryceh> thanks
[02:08]  * RAOF probably has the power to, but doesn't know how, and definitely doesn't have the authority to :)
[02:08] <infinity> bryceh: Done.
[02:13] <bryceh> RAOF, infinity procedural question...
[02:15] <bryceh> since instead of having a single nvidia-experimental package where we can do the package-acceptance, MIR, SRU processes one time, we're presumably going to have a series of nvidia-experimental-NNN packages - are we going to need to go through these processes every time we add another experimental driver, or can we simplify that process overhead down?
[02:25] <RAOF> bryceh: Are we going to have one nvidia-experimental-NNN per driver series? I'd have thought that would just contain the latest experimental series?
[02:28] <bryceh> RAOF, yeah one per driver series.  It solves two issues.
[02:29] <bryceh> RAOF, the first being that if a user installs say 123.11 required by game A, and then later on game B requires 130.08 so we update nvidia-experimental to 130.08, that would get automatically loaded, so we're exposing the user to a new beta driver unnecessarily
[02:32] <bryceh> RAOF, the second is that in order to ensure the user gets moved to nvidia-current when they do a distro upgrade, at upgrade time the package is a dummy that will depend on nvidia-current.  So having the package named nvidia-experimental-NNN will allow this to be done.
[02:32] <RAOF> Ah, ok. I've got an incorrect understanding of the purpose of -experimental, then.
[02:34] <bryceh> yeah, it's not really intended to be "xorg-edgers for the nvidia masses" but a way to resolve dependencies for games
[02:37] <bryceh> RAOF, infinity so, thoughts on my question above^^ ?
[02:38] <RAOF> My understanding is that the tech board can remove arbitrarily many process constraints.
[02:39] <RAOF> So, there could conceivably be some special-casing for it.
[02:40] <bryceh> ok, great.  I'll clarify with them.
[02:42] <stgraber> bryceh: I'm assuming you have a well documented procedure on how to create one of these new source packages?
[02:43] <stgraber> bryceh: if so, I'd think that we could agree to simplify the New processing as long as the packaging is identical and the "source tarball" comes from the same place
[02:44] <bryceh> stgraber, yes there is a README.debian that covers how to create nvidia packages in general.  The only additional step is the actual rename, which is just a setting in one .in file.
[02:47] <bryceh> stgraber, yes we should be able to arrange for that.  My goal is to basically script the whole process (it's already mostly scripted with a few paint-by-numbers steps).  So the packaging is going to be very predictable.
[02:48] <bryceh> anyway, thanks everyone.  I'm EOD and going afk.
[03:51] <StevenK> steven@undermined:~% ps aux | grep mpc | grep -c 'ZN'
[03:51] <StevenK> 183
[03:51] <StevenK> RAOF: ^
[03:51] <StevenK> Awesome, is it not? :-)
[03:52] <ajmitch> the zombie hordes are attacking?
[03:52] <StevenK> ajmitch: It's a mono bug I'm trying to guilt RAOF into fixing.
[03:53] <StevenK> I'm not sure if its working.
[03:53] <ajmitch> yeah I know, bug with it not waiting properly on children
[04:39] <ScottK> micahg: How do you feel about releasing the chromium-browser SRU in precise?
[04:59] <TheMuso> 4;3~/c
[05:28] <ScottK> ;b!?
[05:35] <pitti> Good morning
[06:55] <dholbach> good morning
[07:03] <slangasek> sbeattie: is this stub icedtea-7-jre-cacao needed for upgrades to precise from an earlier release, or for upgrades within precise?
[07:06] <dholbach> TheMuso, hey Luke - how are you doing?
[07:06] <dholbach> do you know if pyatspi has a ~ubuntu-desktop branch or something?
[07:07] <dholbach> I just uploaded a small fix for it
[07:09] <didrocks> dholbach: are you fixing bug #1052331? (seems to only be missing () around print)
[07:09] <didrocks> hey btw :)
[07:10] <dholbach> didrocks, yes
[07:10] <didrocks> dholbach: doesn't seem to have an ubuntu-desktop branch to me
[07:10] <dholbach> ok good
[07:12] <didrocks> thanks dholbach :)
[07:15] <tsdgeos> could the builder bot besides building also install the package?
[07:15] <tsdgeos> this solve this kind of problem, would it?
[07:49]  * Laney spots a dholbach fixing upgrade bugs!
[08:03] <dholbach> Laney, I felt in the mood for it this morning ;-)
[08:06] <mitya57> barry: good morning
[08:06] <mitya57> did you have a look at my py3-defaults fix?
[08:45] <jamespage> doko_, whens the next rebuild test scheduled for? looking at a fix for maven-debian-helper to auto-install to /usr/share/java if the package is a java library
[08:46]  * ogra_ thinks that will likely happen during the freeze
[08:46] <ogra_> since the buildds will be idling anyway
[08:53] <dholbach> @pilot in
[09:12] <cjwatson> bryceh: we can simplify the process requirements, but I do not think it is worth special-case code in Launchpad to stop them going through NEW at all
[09:29] <jamespage> dholbach, hmm - that sync of uglifyjs might create a problem
[09:30] <jamespage> I'd not noticed that the nodejs/node conflict had been resolved in Debian
[09:30] <cjwatson> by way of a Debian Technical Committee resolution, yes
[09:32] <jamespage> yep - but quantal still carries pre-fixed nodejs version
[09:32] <jamespage> so that will generate an unfulfilable dependency
[09:33] <jamespage> nodejs (>= 0.6.19~dfsg1-3)
[09:33] <dholbach> ugh :(
[09:33] <dholbach> sorry, let me take a look at it
[09:33] <cjwatson> is there any chance we can move forward rather than back on this?
[09:34] <cjwatson> i.e. take the new nodejs?
[09:34] <jamespage> cjwatson, I think so; the breaks are pretty explicitly defined in nodejs 0.6.19~dfsg1-3
[09:35] <cjwatson> I realise that would be a merge, and tracking down the other things that need to be synced/merged as consequences
[09:37] <jamespage> ~90 packages (probably)
[09:38] <cjwatson> substantial enough; happy to defer to your judgement on whether that's best
[09:39] <dholbach> maybe it's less packages, 0.6.19~dfsg1-4 says:
[09:39] <dholbach> +    + Break only packages actually calling /usr/bin/node (directly or
[09:39] <dholbach> +      via env).
[09:39] <jamespage> yeah - I just looked at the Breaks in latest Debian unstable
[09:39] <jamespage> its much shorter
[09:54] <ogra_> lol, dholbach thanks for sponsoring the classmate-tools fix, that remonds me that i forgot to ask for package removal ...
[09:54] <ogra_> *reminds
[09:55] <dholbach> ogra_, did you have a good time in Berlin without me? :-P
[09:55] <ogra_> dholbach, not at all ... i had a horrid drive (6h for 350km) and was just super exhausted when i arrived
[09:55] <dholbach> next time then :)
[09:55] <dholbach> I can't believe we never manage to meet
[09:56] <ogra_> and given that i usually dont get much sleep on the sofa over there, my sat. wasnt much better
[09:56] <ogra_> but for the ride back i picked up a cute hitchhiker ;)
[09:57]  * xnox ponders at what point did above conversation drift to #-offtopic?! =)
[09:57] <ogra_> dholbach, yeah, next time i'll drive on thu and return on monday evening, that should give me some time to actually do something
[09:57] <dholbach> sounds good :)
[09:57] <dholbach> xnox, all my fault
[09:58]  * xnox no worries, it's funny though how both of you are avoiding each other, not on purpose ;-)
[09:58] <ogra_> xnox, its not offtopic we are coordinating workplace joint ventures :P
[09:58] <xnox> trinken sprint?
[10:01] <ogra_> heh, exactly
[10:03] <davmor2> Hey guys the light blue hue around the password box on lightdm is it meant to be blue?  it just looks odd considering all the others hilights are orange on the system
[10:16] <ev> mpt: https://errors.ubuntu.com/ - ever so slowly 12.04 is creeping upward and 12.10 is moving further and further away from it. Yikes.
[10:19] <mpt> ev, I predict that the former is bug 1046269 -- i.e. once we fix that, the 12.04 graph will flat-line
[10:19] <mpt> ev, the latter might be the same bug -- Q has always been that unstable, it's just that until recently people haven't been using it for hours on end.
[10:20] <ogra_> ev, its is totally normal that the amout of bugs rises after beta1
[10:21] <mpt> ev, and still the #1 problem is the ubiquity crash, which people would typically only ever encounter 0 or 1 times.
[10:21] <ogra_> (thats why we shouldnt drop milestones :) they give users confidence)
[10:22] <xnox> ev: I would expect stable release to eventually creep up, and +1 to move down. See for example these charts http://bugs.debian.org/release-critical/ blue is stable, green is +1, when they "reset" it's a release.
[10:23] <mpt> ogra_, xnox, these aren't bug reports. The number of errors encountered per calendar day is poorly correlated, if at all, with the number of open bug reports.
[10:26] <xnox> i wonder how this is solved in economics with e.g. daily sales figures. In different sectors there will be different "business-lunch" & "weekend-brunch" sales variations, which is ~ same as we are seeing here. Plus unlike sandwich shops we are open 24/7 in all time-zones.... not just one tiem-zone....
[10:26] <mpt> The huge temporary dips in the red line on <http://bugs.debian.org/release-critical/> tells me that each release they delude themselves about whether a bug is release-critical or not :-/
[10:27] <mpt> (I'd expect that if they had time-based releases, but not when they don't)
[10:27] <ogra_> well, they try to make a scheduled release date even though they arent time based
[10:27] <ev> ogra_: I don't care what's normal. I care about defining what we think is acceptable. If we really think that each release should creep up in instability and then make a massive effort to get the next LTS more stable than what we've recorded for the past, then lets stand behind that statement.
[10:27] <xnox> mpt: no, the dip in the red-line is the delta of the RC-bugs |stable - testing|, such that the dip is all the bugs closed in new release.
[10:28] <xnox> mpt: in debian they track all bugs per-series, we only track SRU worthy bugs per-series.
[10:28] <ogra_> ev, if we walk with "it *has* to be more stable than the last one from day one" we will kill progress completely ... i think what we need is a compromise or a new way to doing out work to make your requirements work
[10:28] <ogra_> s/to/of/
[10:29] <xnox> mpt: and after the release there is a flood of experimental -> testing uploads with many bugs =)
[10:29] <ogra_> s/out/our/
[10:29] <xnox> hence the jump-back after ~6 month freeze
[10:29] <ev> ogra_: and that conversation is what interests me.
[10:30] <ogra_> ev, right, i dont disagree with your view bit i disagree with the timeline you want to implement it in ... it can only work once we changed our way of working
[10:30] <ogra_> *but
[10:30] <ev> so lets change that come UDS.
[10:30] <ogra_> i think changing development processes has to come first here
[10:30] <mpt> xnox, even so, that curve is implausible. :-) The easy-to-fix bugs would get picked off first, so with genuine prioritization the curve would asymptotically approach zero, not plummet towards it.
[10:31] <ogra_> (and before thet infrastructure changes have to happen so the infrastructure can cope with the new processes)
[10:31] <ogra_> imho measuring comeas last :)
[10:32] <mpt> If you don't measure first you don't know whether any process changes helped
[10:32] <xnox> mpt: the red line is pointless, look at the growing delta between blue & green. release means that blue line becomes the green one. instantly on the day they release.
[10:32] <ogra_> mpt, oh, sure, measure as you like, just dont make policies out of it before we have infarstructure and processes right :)
[10:33] <mpt> xnox, I understand that part, but it's only the red line that interests me, sorry :-)
[10:33] <ev> policies drive process
[10:34] <ogra_> ev, but that doesnt help if the infrastructure cant cope :)
[10:34] <ev> it's simple science
[10:34] <ev> hypothesis: Ubuntu is progressively less stable
[10:34] <ev> we now have data that supports this
[10:34] <ogra_> experience tells differently i think
[10:34] <ev> then comes the solution
[10:35] <ev> ogra_: I trust data infinitely more than personal experience
[10:35] <ogra_> its constantly having instabilities i dont think it degrades
[10:35] <xnox> mpt: if the red line is the only one that interests you, why doesn't error.ubuntu.com show the total of all errors reported? e.g. 12.04 & 12.10 combined then?
[10:35] <ogra_> the areas of problems move around with each release
[10:35] <ricotz> infinity, hi, i don't know the details about the nvidia-experimental thing, but there is a "nvidia-settings-experimental" package too
[10:36] <xnox> mpt: the equivalent of the red line. (bundling together development and stable releases)
[10:36] <mpt> xnox, no it isn't. Once again, open bug reports and error reports are not even close to being the same thing.
[10:37] <ogra_> ev, the point is that with our current process you cant really do the measuring you plan ... we currently explicitly break stuff for 3 months to then fix it again in the other three months
[10:37] <ev> ogra_: that was the old model.
[10:37] <xnox> mpt: because 100 bugs hitting 1 user each != 1 bug hitting 10 000 users. I see. Ok.
[10:37] <ogra_> so you have on half of the cycle where it has to rise massively
[10:37] <mpt> ev, it's way too soon to make that kind of statement. We'll know once we have six months data.
[10:37] <ogra_> ev, well, thats still the used model
[10:37] <ev> no, it isn't.
[10:38] <ev> ogra_: my understanding from what I've been told is that the archive must remain stable from day 1
[10:38] <ev> the CDs must always be installable
[10:38] <xnox> but they weren't
[10:38] <ogra_> it had minor tweaks, but we still have three monts until FF
[10:38] <ev> and that we're now allowed to push things out past Feature Freeze if we can show test coverage and stability
[10:38] <ev> we're moving to a much more fluid, test-first model
[10:38] <ogra_> and during these first three months new code and new bugs land
[10:38] <xnox> ev: we don't redirect all uploads to  dev-proposed, so by definition we cannot make CD installable every day, we can't even build CDs every day.
[10:38] <ev> ogra_: lets be honest - new code and bugs land for six months
[10:38] <xnox> ev: so maybe next cycle.
[10:39] <ogra_> ev, right, "we are moving to" ... thats what i mean
[10:39] <ev> xnox: I'm not saying it's impossible for CDs to be broken
[10:39] <ogra_> ev, well, not if people actually stick to the processes
[10:39] <ogra_> (which i agree not all of us do)
[10:39] <ev> I'm saying that the engineering leadership stood up and said it's unacceptable that CDs are uninstallable
[10:40] <ogra_> and withoout an infrastucture that catches that (staging areas for testing etc) we cant change the process yet
[10:40] <mpt> xnox, bugs almost certainly follow a Zipf distribution, e.g. Microsoft's statement that 1% of bugs account for 50% of errors, and 20% of bugs for 80% of errors
[10:40] <ogra_> while we have minor process tweaks (upload to proposed etc) that doesnt fix the whole yet and is only a start
[10:41] <mpt> Zipf or Pareto
[10:41] <ev> ogra_: we have these things. We need to drive people into them faster. We can't sit around waiting for the perfect infrastructure.
[10:41] <ev> If we slow down before we speed up, so be it.
[10:41] <ogra_> i.e. for installer changes we would need a staging area for the images since you can only really test the installer in context
[10:41] <ogra_> etc etc
[10:43]  * ogra_ looks forward to discuss that at UDS and have some proper planning afterwards 
[10:44] <ogra_> all this "we have to .... " without proper technical, process and infrastructure backing doesnt really help
[10:44]  * xnox really wants generate ISOs -> let jenkins auto-test images -> only then release them to cdimage.ubuntu.com
[10:45] <ogra_> xnox, ++
[10:45] <ogra_> so we have at least the installability covered automatic
[10:45]  * xnox had "fun" remarking tens of reported bugs as dupes.... it's like well can I yank the image from cdimage, cause it's borked for ~ 50% of people?
[10:45] <ogra_> but even that has its traps :)
[10:46] <mpt> xnox, and #1 is assigned to you ;-)
[10:46] <ogra_> do you hold back all images of one build if ppc fails this teast (to make sure to not break image consistency across areces) ?
[10:46] <Laney> what do you mean by installability?
[10:46] <xnox> true, but you know basic things.... e.g. if it doesn't boot in a VM / panda-feeder
[10:46] <Laney> you can't even build the live images if you don't have that
[10:46] <ogra_> s/areces/arches/
[10:46] <xnox> ogra_: no, i would hold off just the ppc image. Plus we don't have automatic way to test ppc =)
[10:46] <ogra_> well, then take arm
[10:46] <xnox> ogra_: autotest ppc images that is =)
[10:47] <ogra_> currently we try to keep all images in snyc
[10:47] <ogra_> especially during milestones ...
[10:47] <ogra_> if we drop milestones, how do we guarantee thois consistency ?
[10:48] <ogra_> i doubt all this is doable in one release ... too many established processes that grew over years have to be changed completely
[10:52] <soren> xnox: How'd you debug the problems found by Jenkins if you can't get to the images?
[10:53] <xnox> soren: good point. How'd you stop manual auto testing if the images are borked?
[10:53] <xnox> soren: after jenkins / first person finds out they are borked?
[10:53]  * xnox s/manual auto testing/manual testing/
[10:56] <ogra_> soren, you just fish it out of the staging area where jenkins pulled it from
[10:57]  * ogra_ is out to customs office
[11:00] <soren> xnox: What's "manual auto testing"?
[11:01] <soren> xnox: Anyways, we could probably make Jenkins push a .b0rken file to cdimage akin to the .oversized marker we have.
[11:04] <pitti> ev: hey Evan, how are you?
[11:04] <pitti> ev: do you have an opinion on https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1050853/comments/3 wrt. the tags we should use?
[11:04] <ev> pitti: excellent, thanks. How are you?
[11:04] <pitti> ev: je suis bien, merci :)
[11:05] <pitti> err, "je vais bien"
[11:06] <ev> pitti: :)
[11:06] <ev> pitti: I'm not sure where the tags even come in. http://daisy.ubuntu.com definitely doesn't pay attention to tags from Launchpad.
[11:07] <pitti> ev: ah, it can't/won't look at report['Tags']?
[11:07] <ev> ohhh
[11:07] <pitti> I think Launchpad-wise a "proposed" tag woudl make mose sense
[11:07] <pitti> most
[11:07] <pitti> but of course this needs to work for errors.u.c. as well, otherwise it's missing the point
[11:08] <pitti> ev: I'm also fine with a different field, but on LP bugs this would be more clutter and harder to search for
[11:09] <cjwatson> ev: I was very clear that the intent of the +1 maintenance effort was to make CDs installable *from alpha-1 onwards*, and Rick has supported that qualification; so I'd appreciate it if you didn't generalise that beyond what's promised.
[11:09] <ev> cjwatson: I misunderstood then. Sorry.
[11:09] <cjwatson> (Well, an intent.  There are several.)
[11:10] <cjwatson> Sigh.  You know what I hate?  Reaching a bug on my to-do list, and the first thing I have to do is undo lots of misguided metadata changes.
[11:11] <ev> pitti: so where apport puts it really doesn't matter to me, so long as it's done independent of the Launchpad infrastructure
[11:11] <pitti> ev: it'd be something like 'proposed' in report['Tags']
[11:11] <ev> that is, as long as it's in a field that whoopsie can parse at the time we mark the report for uploading, then that's sufficient
[11:11] <pitti> ev: or to be really correct, 'proposed' in report['Tags'].split()
[11:12] <ev> hmm, so "precise proposed" would be in the tags?
[11:12] <pitti> yes, and potentially lots more
[11:12] <ev> and never precise quantal proposed?
[11:12] <pitti> well, I can't really promise what tags package hooks add
[11:12] <ev> :)
[11:13] <pitti> ev: for the release I'd advise to look at DistroRelease:
[11:13] <ev> ah yes, of course
[11:13] <ev> and that solves my next concern
[11:13] <pitti> (I guess/hope that's what you are using already0
[11:13] <ev> which would've been mapping from the release nicknames to the actual numbers
[11:13] <ev> which we're getting from DistroRelease
[11:13] <ev> so excellent
[11:13] <ev> sounds like we have a solution
[11:13] <pitti> splendid
[11:14] <pitti> we can also call it "package-from-proposed" to reduce the chance of hitting an already existing tag with a different meaning
[11:14] <pitti> mvo: OOI, how does apt manage to record the origin of an installed package?
[11:15] <pitti> mvo: I do understand how the origin of the candidate works, but I didn't think that the installed package origin was recorded anywhere
[11:17] <pitti> mvo: or does it just mix'n'match the installed version number against the available candidates?
[11:18] <cjwatson> It doesn't
[11:18] <cjwatson> I mean, it doesn't record it.  Any notion of the origin is synthesised later
[11:18] <pitti> mvo: i. e. if I see archive:'precise-proposed', can I rely on that it really came from -proposed, or only that it is in -proposed (but it might have the same version in -updates)?
[11:18] <pitti> cjwatson: ok, that's what I thought, thanks
[11:18] <mvo> pitti: yes, its just picking from the available ones, it would be great if it would record the origin but it does not currently
[11:18] <pitti> so I guess to answer "is this a proposed package", I'd rather check the available version numbers myself
[11:19] <mvo> pitti: you can iterate over the available origins
[11:19] <mvo> pitti: if its both in -updates and in -proposed then it should have them both in pkg.installed.origins
[11:20] <pitti> mvo: ah, that's helpful
[11:30] <jamespage> cjwatson, please could you accept the nodejs-legacy binary package in the quantal NEW queue
[11:45] <pitti> == Tags [11:45] <pitti>  precise package-from-proposed running-unity
[11:45] <pitti> ev: ^ voila
[11:48] <pitti> ev, mvo: crude, but effective (I don't want to call Pyton and wait for an apt.Cache() object, apt-cache showpkg is faster): http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/2088
[11:49] <pitti> ev: this should hopefully be SRUable, too
[12:00] <cjwatson> jamespage: done - sorry for the delay
[12:00] <jamespage> cjwatson, np - thanks
[12:04] <ev> pitti: cheers! Do we not also want a tag for -updates?
[12:07] <xnox> -security?
[12:07] <xnox> backports?
[12:12] <doko> jamespage, was waiting for the gnome update, so I should be able to start Wed/Thu
[12:13] <jamespage> doko, OK - I have a fix for m-d-h to make it a little more intelligent with regards to when it installs to /usr/share/java
[12:13] <jamespage> but the test suite in the package is rubbish - its not deterministic
[12:13] <jamespage> I can run it three times a get different results each time
[12:28] <jamespage> it also in no way simulates what m-d-h does when it actually builds a package either...
[12:47] <pitti> ev: would that be any useful?
[12:47] <ev> I guess not as it's really the same view as the release by itself
[12:47] <ev> so ignore me :)
[12:49] <cjwatson> So, I'm working on bug 1047550, and am slightly freaked that this didn't come up in beta-1 testing output as far as I saw
[12:50] <cjwatson> Did I miss it, or do we not do any (non-Mac!) UEFI ISO testing at the moment?
[12:51] <xnox> My laptop doesn't boot ISOs in UEFI mode =( and I am yet to convert my laptop to UEFI manually.
[12:51] <xnox> cjwatson: maybe we need to add another test case / config to the iso tracker with non-mac UEFI
[12:52] <xnox> such that it will hopefully be tested.
[12:53] <cjwatson> Possibly, but I'd like to know first whether I just missed the output
[12:57] <dholbach> can somebody please reject https://code.launchpad.net/~bkerensa/ubuntu/quantal/wulfware/move-homepage-field/+merge/124137?
[12:59] <pitti> dholbach: *zap*
[12:59] <dholbach> thanks
[13:05]  * didrocks wonders where his libsecret, gcr, gnome-keyring, libcryptui, seahorse-nautilus upload went
[13:05] <pitti> right -> there? https://launchpad.net/ubuntu/+source/libsecret/0.10-0ubuntu1
[13:06] <didrocks> did you get some emails on quantal-changes?
[13:06]  * pitti chuckles about didrocks's most intriguing changelog in https://launchpad.net/ubuntu/+source/gnome-keyring/3.5.92-0ubuntu1
[13:06] <pitti> didrocks: it seems emails are stalled
[13:06] <didrocks> pitti: urgh :)
[13:06] <pitti> I didn't get an ack mail for apport either
[13:06] <didrocks> pitti: it's a secret!
[13:06] <pitti> didrocks: *shh* it's secret!
[13:06] <dholbach> @pilot out
[13:06]  * pitti ^5s didrocks
[13:07] <didrocks> pitti: ok, when I saw the email for linux-meta at 14:59, knowing I updated those 30 minutes ago, I started to wonder
[13:07]  * didrocks ^5s pitti :)
[13:38] <jamespage> broder, ping re lintian.ubuntuwire.org
[13:38] <jamespage> I'd like to get a experimental check enabled for quantal - is that possible?
[13:49] <cjwatson> Ah.  The UEFI installation bug above is a bit more constrained than I previously thought, so even if we do test it I have an explanation for why ISO testing wouldn't have run across it.
[13:50] <xnox> bug 1024202 apport crash report about apport crashing =) oh the irony
[13:50] <xnox> ... marking as being affected.
[13:51] <TheLordOfTime> lol, i've seen taht before, that's not the first time i've seen that in the past few days :P
[14:05] <sbeattie> slangasek: upgrades within precise
[14:08] <barry> mitya57: thanks for the reminder, i'm looking at it right now
[14:09] <mitya57> barry: great!
[14:30] <broder> jamespage: hey - i'm swamped this week, but could do it next, or maybe this weekend. can you send me an email with the details?
[14:33] <jamespage> broder, thanks - details on the way
[14:43] <tkamppeter> Laney, doko, hi
[14:44] <tkamppeter> Laney, doko, I have a problem with Avahi
[14:52] <doko> tkamppeter, why do you ask me? ;)
[15:08] <tkamppeter> Laney, doko, host names with NAME.local do not get resolved and an Avahi service (remote printer) does not get resolved via avahi_service_resolver_new()
[15:08] <tkamppeter> doko, sorry, you were in debian/changelog of avahi-daemon
[15:15] <didrocks> dholbach: I will probably switch my patch pilot for next week
[15:16] <didrocks> dholbach: can't do it tomorrow with all PS crazyness
[15:17] <tkamppeter> slangasek, can you help me with an Avahi issue?
[15:20] <ev> mpt: http://poppy-dev.local/?launchpad=false - should asynchronously load the colors
[15:21] <mpt> ev, works in Firefox :-)
[15:22] <ev> mpt: I tested it there too :)
[15:23] <mpt> ev, have you figured out why bug 1027648 is highlighted as a regression? It was never marked fixed.
[15:24] <ev> I'll have a look in a moment
[15:25] <xnox> ev, mpt: well.... maybe it should be as it is resurrected bug 792652 and should have the same crash signature
[15:28] <mpt> ok
[15:35] <ev> mpt: fixed
[15:59] <elmo> tkamppeter: around?
[16:23] <dholbach> didrocks, sure sure
[18:32] <paultag> jodh: Hey, I saw your ITP, and replied without thinking to ask if I got it right. Any idea if I used a silly argument? I'd be happy to clear it up without causing more of a ruckus
[18:56] <paultag> Ah, I see you already replied, jodh. Toodles.
[19:12] <xnox> jbicha: what installation about ubiquity is there?
[19:12] <xnox> jbicha: I want some UIFe for ubiquity crypt & regression w.r.t. scrollbars
[19:13] <xnox> bug 1042649 and bug 1052040
[19:14] <xnox> jbicha: installation docs that is.
[19:19] <Laney> poor docs team
[19:20] <jbicha> xnox: oh, I was out this morning and didn't get a chance to reply to your email; the Docs Team handles help.ubuntu.com but we don't have any control over ubuntu.com
[19:20] <xnox> jbicha: ok. And how about granting those UIFe =)))) from docs team perspective? do they affect docs much.
[19:21] <xnox> jbicha: there is only screenshots from 10.04 on the Graphical install wiki page.
[19:21] <xnox> jbicha: nothing that I can see on the plain help.ubuntu.com
[19:21] <jbicha> right, ubuntu-docs doesn't really have ubiquity docs; so no objections from the Docs Team
[19:21] <TheLordOfTime> jbicha, so if help.ubuntu.com needs updating, do i go poke the docs team, or...?
[19:21] <xnox> jbicha: but I don't know about about localised and / or ubuntu books etc.
[19:21] <xnox> jbicha: ok, thanks.
[19:22] <jbicha> I've not heard any one from the Ubuntu books complain yet, I don't think it will cause a problem for the Ubuntu Manual
[19:22] <TheLordOfTime> whoops, wrong location to ask, sorry
[19:22] <jbicha> does the crypt stuff add new strings for translation though?
[19:23] <jbicha> TheLordOfTime: if it's help.ubuntu.com/community you should be able to update the wiki yourself; otherwise yeah you can file a bug
[19:23] <xnox> jbicha: no it does not. I have added the strings in advance before translation freeze.
[19:24] <xnox> jbicha: I had all the mock-ups so I new the strings up front =) and I withhold urges to change strings.
[19:24]  * xnox withheld?
[19:24] <Laney> i'd say resisted
[19:24]  * xnox chooses native speaker option. 
[19:24] <xnox> I resisted urges to change strings =)
[19:50] <Caesar> Could someone running quantal please do cal | hexdump -C and stick the output in a pastebin for me? Want to see if a bug in precise is still in quantal
[20:01] <xnox> Caesar: http://paste.ubuntu.com/1213597/
[20:17] <Caesar> Thanks xnox
[20:42] <trism> weird message from launchpad about being unable to import the translations in es.po from gnome-control-center 1:3.4.2-0ubuntu15, looking at the file there are a bunch of carriage returns which it seems to be failing on. It isn't part of the diff from ubuntu14 to ubuntu15 so it must have been in the last upload as well, should I worry about it?
[20:43] <xnox> trism: don't worry about it =)
[20:43]  * xnox had similar one before
[20:43] <trism> xnox: alright, thanks :)
[20:43] <xnox> trism: lp side fails to parse some bits which are actually valid or something like that.
[22:18] <bdmurray> stgraber: testing bug 946406 with a 12.04.1 iso I am not able to recreate it
[22:19] <stgraber> bdmurray: yeah, I know but the italians say they can...
[22:22] <stgraber> bdmurray: added a comment asking for a lot more details on what exactly they're doing
[22:49] <mwhudson> obscure question i guess, but why might an upstart job that has
[22:49] <mwhudson> start on runlevel [23]
[22:49] <mwhudson> not start on boot?
[22:50] <mwhudson> this is on a nano image on a beagle xm fwiw
[22:50] <mwhudson> i've added --verbose to the kernels args and see _some_ upstart activity...
[22:51] <sarnold> what does runlevel(8) report as the runlevel once your system is running?
[22:51] <mwhudson> ah so you see
[22:51] <mwhudson> the fun thing is that i can't get into the system :-)
[22:51] <sarnold> oh! that's fun. :)
[22:51] <mwhudson> the upstart job i am curious about is the one that starts a console on the serial line
[22:51] <mwhudson> and the image doesn't have openssh or anything like that
[22:52] <sarnold> is openssh-server too large for th...
[22:52] <sarnold> drat :)
[22:52] <mwhudson> i can mount the sd card and play chroot games i guess
[22:52] <mwhudson> not sure how i'd determine the ip address though
[22:53] <sarnold> dhcpd logs?
[22:53] <mwhudson> i guess
[22:53] <sarnold> tcpdump and look for arp who-has requests? IIRC the Linux stack will query for its own IP when coming online..
[22:55] <mwhudson> hee /sbin/ldconfig: 15: cannot create /dev/null: Permission denied
[22:55] <mwhudson> i guess i forgot something when chrooting then
[23:12] <mwhudson> oh what, i boot it with a network cable attached and i get the console on the serial line
[23:12] <mwhudson> nevermind though
[23:14] <sarnold> mwhudson: heh, but if you unplug the nic the serial console goes away too?
[23:22] <mwhudson> sarnold: don't know
[23:22] <mwhudson> sarnold: don't actually care either :)
[23:23] <sarnold> :)
[23:23] <mwhudson> (i'm just using the device to test some host-side debugging stuff, i just need it running)