[00:09] <ironhalik> Hello
[00:09] <ironhalik> I'm wondering about licensing issiues regarding ubuntu development
[00:11] <ironhalik> I'm working on an enterprise app that would interface with my software on Ubuntu
[00:11] <ironhalik> the android app would be paid, the Ubuntu part is intended to be open sourced on via launchpad
[00:12] <ironhalik> can I use any part of Ubuntu logo on the paid android app?
[00:22] <slangasek> ironhalik: http://www.ubuntu.com/aboutus/trademarkpolicy
[00:23] <slangasek> ironhalik: (short answer: no)
[00:24] <ironhalik> Or I need to contact canonical :>
[00:26] <ironhalik> Thanks for the link
[00:43] <GunnarHj> bdmurray: still there?
[00:43] <bdmurray> GunnarHj: yes
[00:44] <GunnarHj> bdmurray: Good. I don't see any signs in Launchpad of your SRU uploads.
[00:45] <bdmurray> GunnarHj: well its there - https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1
[00:46] <bdmurray> GunnarHj: somebody from the SRU admin team needs to approve it so it ends up in -proposed
[00:46] <GunnarHj> bdmurray: Aha, didn't know that. Thanks!
[02:23] <ubuntu_user2> Hello. If anyone is willing to help, I'm having a unique problem in 12.04
[03:52] <mfisch> robert_ancell: can we mark this as fix released?  seems to be fixed in Q: https://bugs.launchpad.net/ubuntu/+source/gcalctool/+bug/926676
[03:52] <robert_ancell> mfisch, yes, if it's in quantal
[03:53] <mfisch> robert_ancell: it is as far as I can tell
[04:45] <pitti> Good morning
[04:45] <pitti> infinity: initramfs-tools> pinky thanks!
[04:46] <infinity> pitti: Thank me when I get it done.  Working on an obscure glibc bug right now. :P
[05:37] <pitti> cjwatson: FYI, just filed bug 1076237; nice example of how autopkgtest detects regressions introduced by a new proposed apt :)
[06:07] <infinity> pitti: Except that it got the regression target wrong.
[06:08] <infinity> pitti: Unless you meant "this is a regression IN $version"... "from" makes it sound like that version was okay.
[06:13] <pitti> infinity: what I meant is that this upload introduced the wrong "#" comment
[06:14] <infinity> pitti: Ahh.  The wording was ambiguous, then. ;)
[06:14] <pitti> infinity: so grammatically, "regression in <that version>" is better?
[06:14] <infinity> pitti: Or, rearrange the sentence entirely to "This regression appeared in $version"
[06:14] <pitti> even better :)
[06:17] <persia> When talking about regressions, I think it's important to not only mention when it was introduced, but also against which version it is being compared (as this may not always be the immediately prior version, for example when discovering regressions during release upgrade testing)
[06:18] <infinity> autopkgtest doesn't necessarily have a concept of which version worked, only that the current one's broken.
[06:18] <persia> True :(
[06:18] <infinity> It's assumed to be a regression only because we assume the tests all currently pass.
[06:19] <infinity> (Which won't be true in the case of racy and nondeterministic test-suites, but we need to stamp those out)
[06:19] <pitti> yeah, autopkgtest didn't tell me that, I just reviewed the diffs and checked which upload introduced it
[06:19] <persia> all tests passing also isn't true if we start TDDD, where we define the behavioural tests prior to patching packagegs.
[06:20] <infinity> persia: You may have one too many Ds.
[06:20] <persia> I most decidedly don't.
[06:20] <infinity> Test-driven dessert development?  Yum.
[06:20] <persia> Test driven distribution development
[06:20] <persia> See liw's blog posts from ages ago
[06:20] <lifeless> o/
[06:21] <persia> lifeless: Is the highlight on "TDD" or "TDDD" or just fuzzy neural matching semantics beneath the threshold of conciousness?
[06:21] <lifeless> godlike powers of observation
[06:21] <persia> Ah, I knew it was something
[06:22] <persia> infinity: So, anyway, the point being that there are ongoing discussions that would lead to actions diametrically opposed to stamping out tests that fail, although the concept of expected-to-pass and expected-to-fail need to be introduced to Jenkins for things to be sensible before that happens.
[06:23] <persia> (whlie liw's blog posts are old, some of these discussions were active in the just passed UDS)
[06:23] <pitti> I think at the beginning cjwatson only wanted to introduce blocking on autopkgtest regressions
[06:23] <persia> That's my understanding also.
[06:23] <infinity> persia: I consider an XFAIL a pass, from the POV of not regressing.
[06:23] <pitti> i. e. if a package test already fails in -release, a -proposed failure wouldn't block
[06:23] <persia> infinity: Excellent then.
[06:23] <pitti> that's still a bad situation of course, as eternally failing tests render the whole idea moot
[06:24] <infinity> (Granted, I'd prefer if all our software were in a state where XFAIL wasn't ever needed, but whatever)
[06:24] <persia> pitti: Are we running against -release for comparison, for packages that haven't been updated since warty?
[06:24] <pitti> persia: yes, we run both
[06:24] <pitti> https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/
[06:24] <persia> Ah, then I misunderstood.  Excellent.
[06:24] <pitti> we started with that, and in quantal we introduced testing against -proposed, too
[06:25] <persia> pitti: Thanks for the quick overview: helps me to catch up :)
[06:25] <infinity> pitti: Anyhow, yay for it catching a bug, fix uploaded.
[06:26] <pitti>  infinity: oh, thanks; I was going to wait for mvo for upstreamization, etc.
[06:26] <infinity> pitti: This isn't upstream.
[06:26] <pitti> so I guess we don't really want to support the # character there then
[06:27] <infinity> pitti: No, it's a pleasant coincidence that some bits of apt respect POSIX shell style comments, but the only documented correct comment style is C++.
[06:27] <pitti> funny debdiff (http://launchpadlibrarian.net/122343308/apt_0.9.7.6ubuntu2_0.9.7.6ubuntu3.diff.gz)
[06:27] <infinity> pitti: So, was just a goof on vorlon's part when he used #, that's all.
[06:27] <pitti> yay for having autom4te.cache in packages..
[06:27] <infinity> Yeah, apt's build system is a mess.
[06:28] <infinity> Refreshing the po files on every version bump is lunacy too.
[06:28] <pitti> so, thanks!
[06:28] <pitti> infinity: btw, I found that "debuild -S -nc" helps with those cases
[06:29] <pitti> but yes, it's still mad
[06:29] <pitti> and more important for SRUs
[06:29] <infinity> pitti: I use -nc all the time, I don't -nc apt intentionally cause this is also how it updates its version.
[06:29] <infinity> (Granted, the version will update on clean during the build, but it'll be wrong in the source until then)
[06:29] <persia> Um, isn't needing to use -nc a bug as clean wouldn't be idempotent?
[06:30] <infinity> persia: clean is idempotent for apt.
[06:30] <infinity> persia: If you mean to use the actual meaning of the word. :P
[06:31] <persia> I think I mean that when you do it, and you do it again, and you do it again, and you do it again, and you get sick of doing it, you notice that doing it once got the same result as doing it all the extra times.
[06:31] <infinity> Right, that's what it means.  And it is.
[06:31] <pitti> the problem here is what it does at the first time :)
[06:31] <infinity> It's that the first run of clean won't leave you at the same state as you were pre-clean.
[06:31] <infinity> Doing it 17 more times won't change state.
[06:32] <persia> But I don't understand how this could be important for SRUs, as presumably the last upload was also clean.
[06:32] <infinity> (Well, except for automate.cache jumping line ordering around, but we'll ignore that)
[06:32] <pitti> persia: I meant, it's better to have minimal diffs for SRU reviews
[06:32] <infinity> persia: It just makes SRU diffs more readable, other than that, it matters not.
[06:32] <pitti> rather than diffs which are full of autom4te and .po update noise, which make the actual changes harder to see
[06:32] <infinity> And, honestly, our SRU reviewers are smart enough to filter noise from diffs.
[06:33] <persia> pitti: Sure, but if I didn't upload -nc last time, I presumably ran clean, so I don't see how running clean again generating a different diff should not be considered a bug.
[06:33] <infinity> persia: Every new version/upload will change some bits on clean.  That's not a problem.
[06:33] <pitti> infinity: actually, I don't think it's idempotent as the .po file timestamps would always change
[06:33] <infinity> (Well, it's a horrible build system and silly decision, but it's not actually buggy, just gross)
[06:34] <infinity> pitti: Well, okay.  True.  It's logically idempotent, but not literally. :P
[06:34]  * persia agrees with pitti, but admits that this is considered unimportant
[06:34] <infinity> Anyhow, fixing that mess is somewhere low on the TODO of pretty much everyone who's ever uploaded the package.
[06:34] <infinity> One of us will get annoyed enough to do it some day.
[06:35] <persia> Ah, then it is a bug, just not an important bug.  My worldview is restored.
[06:35] <infinity> It's only a bug in the world where "wishlist" = "bug", which is questionable in some people's minds.
[06:35] <infinity> It's a feature request that the build system not suck.
[06:35] <infinity> It's not buggy that it does suck.
[06:36] <infinity> (In that it produces sane results, just suboptimally)
[06:37] <infinity> Hrm.  I need to file a UI bug with Android: "Please don't tick the battery meter down on the lockscreen when I'm staring at it".
[06:37] <infinity> Rather disconcerting.
[06:38] <infinity> It may as well make a sucking noise while it's doing it.
[06:44] <jk-> PATCH: Add staring-at-phone face detection to lock screen
[06:44] <pitti> isn't facelock doing pretty much that already? :-)
[07:03] <FourDollars> Where are patch pilots? :(
[07:06] <FourDollars> cjwatson: ping
[07:43] <dholbach> good morning
[07:47] <IanWizard-Cloud> dholbach: good night
[07:48] <IanWizard-Cloud> (off to bed :P )
[07:48] <IanWizard-Cloud> dholbach: Have a nice day :)
[07:48] <dholbach> IanWizard-Cloud, sleep tight :)
[07:48] <IanWizard-Cloud> thx
[08:06] <cjwatson> pitti: that was my initial plan, but I changed my mind during UDS; it'll involve much less fragile tracking to just say that any failure, regression or not, blocks migration, and I don't think we have so many autopkgtests that it's necessary to set up a ratchet
[08:06] <cjwatson> FourDollars: helps to say what you want ...
[08:06] <pitti> cjwatson: ah, ok; I'm mostly concerned about those which never succeeded
[08:07] <pitti> we should fix them anyway, of course
[08:07] <persia> Or, rather, those that are failing currently in raring, even if they passed previously.
[08:07] <cjwatson> well, if it's really intractable, worst case we disable them
[08:08] <pitti> yeah, at least until we fix them; I'd love to just have them always pass, it just will take a bit
[08:23] <janimo> slangasek, I just did as with previous kernel packages I co-maintained, just used native packaging. The ubuntu kernel package seems to be native too. But I agree having upstream + delta would be nicer
[08:25] <cjwatson> The Ubuntu kernel package is randomly native or not depending on whether the kernel team remembers to put the orig in place :-)
[08:25] <cjwatson> (as far as I can tell)
[08:29] <FourDollars> cjwatson: https://code.launchpad.net/~fourdollars/ubuntu/precise/ubiquity/lp1046241/+merge/132653
[08:29] <FourDollars> cjwatson: https://code.launchpad.net/~fourdollars/language-selector/singleton_and_escape_key/+merge/132595
[08:30] <FourDollars> cjwatson: Could you help to review my patches?
[08:30] <cjwatson> FourDollars: I can look at ubiquity but not language-selector.  However you need to work based on lp:~ubuntu-installer/ubiquity/precise-proposed
[08:31] <smb> cjwatson, Huh? Oops, which release has not? Usually it should happen as soon as there is a orig from the upstream I would believe...
[08:31] <FourDollars> cjwatson: Thanks for your information.
[08:48] <persia> smb: So it's native until upstream release, then non-native?
[08:54] <smb> persia, yes
[08:54] <apw> persia, right we don't really have a valid .orig until linus releases with the version we are using
[08:55] <persia> For other packages, we tend to create a fake (incorrect) .orig, marked to indicate it's a git snapshot in a version-safe way.
[08:56] <persia> Usually something like appending ~gitYYYYMMDD to the orig version string.
[08:57] <persia> Depends if you ever want to upload something with just packaging or sauce changes, rather than upstream changes.  If so, saves bandwidth to have an orig.  If not, doesn't matter that much except insofar as it might be confusing to others.
[09:01] <cjwatson> smb: ah, yes, you're right, only 3.7.0 lacks it right now which is sane enough.  It used to be more haphazard, so thanks for fixing your process :-)
[09:03] <cjwatson> FourDollars: I can go ahead and backport that patch to the right branch now if you like
[09:03] <cjwatson> FourDollars: unless you already have something in progress
[09:03] <FourDollars> cjwatson: If you can do that, that will be great. :D
[09:04] <FourDollars> cjwatson: Thanks a lot.
[09:08] <cjwatson> FourDollars: OK, done.  Not uploading quite yet because I'm going to need to upload ubiquity soonish for secure boot patches which I haven't yet backported
[09:08] <FourDollars> cjwatson: Got it, Thanks. :)
[09:08] <mlankhorst> can someone drop the xorg-xserver in the sru queue for quantal?
[09:09] <pitti> mlankhorst: apparently someone already did, I don't see it
[09:09] <pitti> https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=xorg only has nouveau
[09:10] <mlankhorst> ah k :)
[09:10] <pitti> mlankhorst: unless you uploaded it in the last 4 minutes?
[09:10] <mlankhorst> nah
[09:10] <FourDollars> pitti: Could you help to review https://code.launchpad.net/~fourdollars/language-selector/singleton_and_escape_key/+merge/132595 ?
[09:11] <pitti> not right now, but I'll be patch-piloting on Monday and can get to it then
[09:13]  * cjwatson starts to get a handle on the python-apt failure
[09:13] <cjwatson> missing Architecture: lines in the test Packages files; now to determine whether that's a deliberate increase in strictness or a bug
[09:15] <FourDollars> pitti: I see. Thanks.
[09:16] <FourDollars> pitti: Do you know where is the Patch Pilots schedule? Any wiki page?
[09:16] <pitti> there's a google calendar for it
[09:17] <FourDollars> pitti: Could you give me the link?
[09:17] <pitti> it's on https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews
[09:18] <FourDollars> pitti: Excellent! thanks a lot.
[10:15] <pitti> that's going to be fun: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=missing-testsuite-header;users=autopkgtest-devel@lists.alioth.debian.org
[10:15] <pitti> let's see how many of those actually work
[10:16] <Laney> \o/
[10:16] <dholbach> :-)
[10:16] <Laney> I saw that Debian got a jenkins instance too: http://jenkins.debian.net/
[10:17] <dholbach> but I couldn't find the autopkgtests in there
[10:17] <pitti> yes, that mass bug filing started because of that
[10:17] <dholbach> and 4 of those bugs are already marked wontfix :/
[10:17] <pitti> it was just set up, it's not yet doing autopkgtest
[10:17] <pitti> dholbach: yeah, Jakub Wilk did that without explanation
[10:18] <Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685508#10
[10:19] <pitti> ah
[10:20] <pitti> so, we'd need to convince LP to generate a Contents-source.gz
[10:30] <xnox> dholbach: pitti: did anybody talk to jwilk?
[10:30] <pitti> not me, I just saw his response
[10:31] <pitti> so if they want to use that field for jenkins.d.o, that certainly works
[10:32] <pitti> but we need to add it until Soyuz learns about contents-source.gz
[10:34] <Laney> it's not certain if he's just a lone voice yet though
[10:48] <mpt> ev, hi, I just experienced bug 1012358. Anything I can provide to help debug it?
[10:48] <caribou_> tseliot: ping
[10:48] <ev> mpt: attach the report to the log
[10:48] <ev> it will be in /var/crash
[10:49] <ev> and ew, a python tuple in an error message
[10:49] <ev> mpt: we really need to turn that UDS presentation of yours into a thousand error dialog paper cuts or something similar
[10:50] <mpt> ev, unfortunately, this is one of (cough) five error reports I'm being asked about at the moment ... How do I tell which one it is? :-)
[10:50] <mpt> five errors, I mean
[10:51] <ev> is the dialog still up?
[10:51] <mpt> yes
[10:52] <ev> mpt: xprop | grep WM_PID in a terminal window
[10:52] <ev> click on the error dialog
[10:52] <ev> that will get you the PID
[10:52] <ev> then ps aux | grep $whatever_the_pid_is
[10:52] <mpt> oh, now one of the others did the same thing
[10:52] <mpt> ok
[10:52] <ev> and that *should* give you something like /usr/share/apport/apport-gtk /var/crash/the_report_file.crash
[10:53] <ev> I hope
[10:54] <mpt> ev, no such luck ... it just gives me "mpt       5024  0.1  1.4 160076 28520 ?        Sl   10:44   0:00 /usr/bin/python3 /usr/share/apport/apport-gtk"
[10:54] <ev> oh right
[10:54] <ev> because it's being launched from update-notifier in "process all the outstanding reports" mode
[10:55] <ev> maybe just send a zip of your entire /var/crash directory
[10:55] <mpt> Ah, that's why I get five at once?
[10:55] <ev> yup
[10:55] <mpt> Yeah, we should fix that :-)
[10:55] <ev> bug please
[10:55] <ev> be sure to tag it :)
[10:58] <cjwatson> ogra_: Do you know if there's any chance of overlayfs being turned on in the nexus7 kernel?  I don't quite know where to file bugs
[10:59] <persia> janimo: ^^
[10:59] <dholbach> cjwatson, there's a ubuntu-nexus7 project in LP
[10:59]  * mpt uses "sudo file-roller" to add root files to the archive, and feels dirty
[11:01] <xnox> mpt: use gksudo and feel all "gnomish" =)
[11:01] <mpt> xnox, file-roller should use PolicyKit to get permission to read the files
[11:02]  * xnox > seb128 
[11:03] <seb128> xnox, patches are welcome ;-)
[11:03] <cjwatson> dholbach: ah, thanks
[11:07] <ev> work items are great and all, but I'd love to be able to indicate finer grained progress for individual items
[11:08] <ev> but compared to what we used to deal with, I'm so happy to have this
[11:10] <seb128> ev, split the item in more details?
[11:10] <zequence> Where can I find more info on how Ubuntu syncs packages from Debian?
[11:10] <zequence> ..for the development release of Ubuntu, that is
[11:10] <ev> seb128: yeah, perhaps this is the equivalent of a code smell. I need to refactor my work items :)
[11:11] <ogra_> cjwatson, well, there is a linux-nexus7 package in the queue, waiting to enter the archive i think ... once thats in, that should be the bug target, for now dholbach is right, use the nexus7 project
[11:12] <mpt> ev, I added the archive
[11:12] <ev> mpt: cheers, I'll have a look momentarily
[11:14] <zequence> Or more specifically, from which Debian repo(s) does Ubuntu development release get their packages from? testing/experimental?
[11:15] <diwic> zequence, unstable by default
[11:15] <diwic> zequence, testing for LTS releases
[11:16] <persia> diwic: In practice, but aren't there some package-specific hints for some packages in the sync scripts?
[11:16] <diwic> persia, if so, that's more than I know of
[11:18] <cjwatson> persia: No.
[11:18] <cjwatson> diwic is correct, although if our current stability work turns out well then we may just stick with unstable for the next LTS too.
[11:18] <cjwatson> (Will need discussion.)
[11:19] <cjwatson> zequence: the auto-sync script in https://code.launchpad.net/+branch/ubuntu-archive-tools is what actually does the work.
[11:20] <zequence> cjwatson: Thanks
[11:21] <persia> cjwatson: Hrm.  I thought I remembered some continued syncs from experimental, but indeed, it seems that was the result of concientious archive-admins rather than autosync.
[11:22] <cjwatson> Or possibly just self-service syncs by developers.
[11:22] <persia> My memory of that predates that facility, but yes, that is likely more true now :)
[11:24] <cjwatson> We did occasionally use to get requests to sync stuff from experimental; I don't remember doing so routinely, only on request
[11:24] <cjwatson> (But you may not necessarily have seen the requests, of course :-) )
[11:25] <persia> Indeed, as there were N fora in which they appeared :)
[11:32] <janimo> cjwatson, ogra_ overlayfs is not part of our 3.1 based Nexus kernel. We'll need to backport if it is required for the installer. If it is a SAUCE patch in Ubuntu it will be part of the sync-up that should happen so the nexus kernel is as close to Ubuntu's as possible
[11:35] <ogra_> diwic, i dont see you in #ubuntu-arm, for the nexus there are two android files at https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/audio_policy.conf and https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/mixer_paths.xml , nots sure that helps though :)
[11:35] <ogra_> oh, and there is https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/audio/ with some .c files
[11:36] <mpt> ev, on the tagging thing, I think it might be a bit quicker overall if you use a project group, containing apport, whoopsie, daisy, and errors
[11:37] <ev> mpt: I think I tried to turn whoopsie-daisy into that, but because it was already a project it didn't work
[11:37] <ev> any suggestions for a name
[11:37] <ev> ?
[11:37] <mpt> ev, because LP can show an aggregated bug listing for a project group. So instead of the chore being tagging whoopsie-daisy bugs in every project, the chore would then be making sure apport bugs were filed upstream. Still a chore, but you'd need to do that for fewer bugs.
[11:38] <mpt> ev, ubuntu-error-tracker?
[11:42] <cjwatson> janimo: I think it's sauce
[11:43] <ev> mpt: at what point did you see this error dialog? Was it after you hit show details or continue?
[11:44] <mpt> ev, I got it twice. I think I had clicked "Show Details" in all five. I don't know whether the error was for one of the ones I'd already clicked "Continue" for.
[11:45] <mpt> (for two of the ones, rather)
[11:45] <ev> I think this may be dependent on information it's collecting as part of that Show Details step, as I can't seem to reproduce it here
[11:46] <ev> pitti: ^ are you okay with me adding the apport project to an ubuntu-error-tracker project group?
[11:47] <pitti> ev: sure, that sounds sensible
[11:47] <ev> cool
[11:52] <ev> pitti, mpt: https://answers.launchpad.net/launchpad/+question/213666
[11:52] <pitti> ev: thanks, subscribed
[12:08] <tseliot> caribou: pong
[12:44] <diwic> ogra_, yeah, that's the same files I've seen as well, but as cyagenomod. That's where I got the idea to try 44100 kHz only, thinking that Pulseaudio's initial probing might cause something to stall
[12:45] <caribou> tseliot: I'm back.
[12:45] <caribou> tseliot: just wanted to let you know that my Nvidia install issue automagically disapeareed
[12:46] <caribou> tseliot: I was able to enable nvidia-current. But I suspect that, in the meantime, I installed the linux-headers pkg
[12:46] <caribou> tseliot: and it was needed for the dkms build
[13:47] <tseliot> caribou: ah, good
[13:56] <Daviey> xnox: hey, are you looking to merge autofs?
[13:58] <xnox> Daviey: yes.
[13:58] <xnox> Daviey: you want it urgently?
[14:00] <Daviey> xnox: no,just going through the packages i care most for :)
[14:00] <xnox> ;-)
[14:00] <ev> pitti: can you hit "Change details" on http://launchpad.net/apport and put "ubuntu-error-tracker" in the "Part of" field?
[14:00] <Daviey> considering debian has been in freeze.. the list is larger than i hoped :)
[14:01] <pitti> ev: oui, je peux
[14:01] <ev> cheers
[14:01] <pitti> ev: done
[14:01] <ev> yay
[14:02] <ev> mpt: bam! https://launchpad.net/ubuntu-error-tracker
[14:02] <pitti> ev: that just made me aware of an OMGcritical bug
[14:02] <ev> oh?
[14:02] <pitti> ev: daisy and whoopsie SO MUCH need a proper icon!
[14:02] <ev> hahaha I was just thinking that a moment ago
[14:03] <ev> mpt? :)
[14:03] <ev> pitti: ps. I'm trying to get a handle on this lovely one: https://launchpadlibrarian.net/118068239/Traceback.txt https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1059938
[14:03] <ev> I'd quickly assume it's hardware (which we should handle, regardless), but I'm not ruling out something more nefarious
[14:04] <mpt> pitti, ev: I requested a better icon for the error alerts themselves, but yes, it would be sweet to have related icons for the components
[14:05] <pitti> ev: yeah, if it doesn't have dupes, I'm inclined to attribute it to cosmic rays
[14:07] <mpt> pitti, it's happened to me three times today, and sunspot activity has been quiet this week
[14:07] <ev> god damn I love errors.ubuntu.com
[14:08] <ev> I mean, I realise that's slightly self-congratulatory
[14:08] <pitti> mpt: oh, you can reproduce this?
[14:08] <ev> but I looked at apport and there was just that one instance
[14:08] <ev> then I looked at https://errors.ubuntu.com/?package=apport-gtk&from=year
[14:08] <ev> and it's the #3 most common issue in apport
[14:08] <pitti> ev: wow, and look at the rate 13.04 is getting better :)
[14:09] <mpt> pitti, no, it's just three that happened to appear today
[14:09] <ev> :) mpt has some math to smooth those spikes out
[14:09] <pitti> ok, so that is real then
[14:09] <mpt> pitti, I think the first day of 13.04 was just 12 of the same problem
[14:09] <mpt> or something like that
[14:09] <pitti> it still looks nice :)
[14:15] <ev> mpt: how wide do you think the range of dates for the average number of errors per calendar day graph should be? Too wide and we run the risk of the milestone markers overlapping
[14:16] <ev> (with it expanding on the right hand side to include the next release day)
[14:19] <ev> pitti: you said that ddebs.u.c was back to normal, right?
[14:19] <pitti> ev: it should, yes
[14:19] <ev> yay
[14:20] <pitti> the bug got closed anyway
[14:20] <ev> :)
[14:20] <ev> cheers
[14:20] <ev> I've notified webops
[14:44]  * xnox did something naughty
[14:44]  * xnox -> lunch
[14:54] <highvoltage> xnox: explain.
[14:54] <Quintasan> bdrung: nudge
[14:55] <bdrung> Quintasan: you are desperately waiting for it?
[14:56] <Quintasan> bdrung: Not really THAT impotant but just nudging you
[14:56] <bdrung> okay :)
[14:57] <bdrung> Quintasan: the fingerprints lay on my desk. so i will not forget to sign the keys.
[14:57] <Quintasan> Oh
[14:57] <Quintasan> That's quite a good idea
[14:57]  * Quintasan spreads the keys on his desk
[14:58] <bdrung> Quintasan: there are 5 other items on the disk that require my action. there are ~10 mails waiting for my reply. there are at least 2 patches that i should look at. i want to write a blog post...
[14:59] <bdrung> at least the keys are not buried under more staff :)
[14:59] <Quintasan> blog post
[14:59] <Quintasan> crap
[14:59]  * Quintasan goes off to do something productive instead of annoying poeple
[14:59] <Quintasan> people*
[15:01] <bdrung> Quintasan: i recommend to work on that: http://reqorts.qa.ubuntu.com/reports/sponsoring/
[15:01] <Quintasan> alt+f4
[15:01] <Quintasan> bdrung: :P
[15:18] <pitti> xnox: FWIW, if nobody complained about the lack of ndiswrapper since precise, let's try and drop it for good; it uses a ton of old libraries which we try to get rid of
[15:19] <stgraber> +1
[15:20] <cjwatson> Laney: you can go ahead and kill that cloud instance you set up for me to debug python-apt - thanks!
[15:20] <Laney> cjwatson: righto - nailed down?
[15:21] <Laney> eet eez deleted
[15:21] <cjwatson> Laney: well, mostly
[15:22] <cjwatson> Laney: I'm still a bit nervous that it was only reproducible on some systems, but it amounted to apt being at least vaguely intentionally stricter about Packages stanzas without an Architecture field
[15:22] <cjwatson> so after debugging for hours to try to figure out where the discrepancy was, I gave up and made the trivial test fix since it was clearly busted anyway
[15:24] <xnox> pitti: what "old libraries" are talking about? =))) http://launchpadlibrarian.net/122375899/ndisgtk_0.8.5-1_0.8.5-1ubuntu1.diff.gz
[15:24] <pitti> xnox: oh, err, wow!
[15:25] <xnox> pitti: I found out that there is no kernel module at the final step of testing in the live cd....
[15:25] <stgraber> :)
[15:27] <dobey> can i get someone to approve the u1db binnew in raring-proposed so it gets to raring?
[15:28] <pitti> mpt, ev: I found a similar bug which is very very likely the same reason, and duplicated bug 1059938
[15:28] <pitti> the new master is public and has some analysis
[15:28] <cjwatson> xnox: "replace program with new program" :-)
[15:28] <pitti> anyway, time to stop sitting in front of that computer for today and play some Badminton, cu tomorrow!
[15:29] <cjwatson> dobey: looking
[15:29] <xnox> cjwatson:  "[14:44] * xnox did something naughty"
[15:29] <cjwatson> heh, I wondered
[15:29] <pitti> xnox: what about * Port Windows drivers to Linux"?
[15:29]  * pitti ducks and heads off
[15:30] <xnox> pitti: that was done part of canonical re-writting linux kernel in python, wasn't it?
[15:31] <cjwatson> dobey: done
[15:33] <dobey> cjwatson: thanks!
[15:36] <jetsaredim> is there a guide for making changes to a package and then submitting them for approval?
[15:38] <astraljava> jetsaredim: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff might work?
[15:40] <jetsaredim> astraljava: possibly
[15:47] <mpt> ev, can you stagger alternating milestone markers?
[15:48] <mpt> ev, i.e. odd-numbered ones higher than even-numbered ones
[15:48] <ev> mpt: you mean raise or lower their height? Won't that ultimately have the same problem (at the cost of a lot of extra computation)
[15:49] <mpt> ev, eventually.
[15:49] <ev> mpt: so you'd like to see if we can include all the data we have so far for the default view?
[15:50] <mpt> ev, definitely, I'd like to see the past five years in the default view
[15:50] <ev> okay, I'll give that a bash
[15:50] <mpt> (even if the horizontal scale ends up a log scale to show the past few months in more detail)
[15:53] <ev> mpt: wouldn't that be confusing given that our x-axis currently only shows values for the milestone dates?
[15:53] <ev> it would be hard to see that it was in fact a log scale
[15:54] <mpt> ev, it would, we'd need to add other tick marks before then
[15:54] <mpt> or at the same time
[15:56] <mterry> @pilot in
[16:02]  * dholbach hugs mterry
[16:02] <mterry> :)
[16:10] <bdmurray> ev: is there a way to track current error counts for a bucket?  I know a fix for a crash has been released and I want to make sure it drops to 0
[16:11] <ev> bdmurray: I'm not sure I follow. How is this different to looking at the instance count for the version you just uploaded?
[16:12] <jetsaredim> what is the review process for a patch to a quantal package?
[16:12] <bdmurray> ev: well, its bug 875879 where the error was in aptdaemon not update-manager.
[16:14] <bdmurray> ev: I was thinking about something like https://errors.ubuntu.com/api/1.0/problems-count/?format=json&period=day&limit=14 but for the specific bucket
[16:21] <ev> hmm, that's doable, but I wonder if that's the ideal solution, given others are going to run into this and not know about the API
[16:21] <ev> brb
[16:21] <seb128> can somebody set https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422 to Work In Progress to get it out of the sponsoring queue? (c.f comments, it's not ready to be uploaded)
[16:23] <ogra_> slangasek, do you happen to know what the --tty= option of plymouth does exactly ? i was trying to use it to force a splash on the nexus but it doesnt seem to affect the splash side of things, only stdio
[16:24] <bdmurray> ev: I guess I'd like to "subscribe" to the bucket and get emails regarding counts
[16:25] <slangasek> ogra_: it certainly is supposed to affect which tty the splash appears on
[16:25] <ogra_> hmm, i think i added --tty=/dev/tty1 to all plymouthd calls in the boot process, but it still seems to use the console= option
[16:26] <ogra_> slangasek, http://paste.ubuntu.com/1342880/
[16:26] <ogra_> the nexus bootloader has a hardcoded console=none ... we override that with the kernel cmdline options to console=tty1
[16:26] <ogra_> but it seems to pick none as default no matter what i do
[16:27] <ogra_> add_consoles_from_kernel_command_line:console /dev/none found!
[16:27] <ogra_> and that is a clear lie :)
[16:28] <slangasek> ogra_: oh; but console != tty of course
[16:28] <ogra_> there is no /dev/none anywhere
[16:28] <slangasek> so this would be a bug in plymouth's /proc/cmdline parsing
[16:28] <ogra_> yeah, it should ignore =none
[16:28] <slangasek> (IIRC, one you've run into in the past on ARM :P)
[16:29] <ogra_> i only ran into the "serial ttys foirce splash to off" one
[16:29] <slangasek> yes, which is the same bug :)
[16:29] <ogra_> and that seems fixed since 0.8.5
[16:29] <ogra_> (which we dont have yet)
[16:29] <slangasek> plymouth should support multiple specifications of console= and DTRT with them
[16:29] <slangasek> ok
[16:29] <ogra_> right
[16:30] <ogra_> http://cgit.freedesktop.org/plymouth/commit/?id=6baab7a8f889f6b48cb559fd5a62750203f62c3b
[16:30] <ogra_> (at leats that one is lonked from https://bugs.freedesktop.org/show_bug.cgi?id=22239)
[16:31] <jodh> ogra_: have you tried the '--kernel-command-line=...' option? See https://wiki.ubuntu.com/Plymouth
[16:31] <slangasek> we certainly don't want to embed something like that
[16:31] <ogra_> slangasek, well, but it might help for a test :)
[16:31] <slangasek> sure
[16:32] <ogra_> i at least would like to see a splash at some point to make sure the framebuffer driver doesnt mess up
[16:32] <jodh> slangasek: purely for testing :)
[16:33] <slangasek> ogra_: btw, I guess you missed my question over the weekend about not being able to ssh into my nexus
[16:33] <ogra_> hmm, no splash
[16:34] <ogra_> slangasek, well, did you install openssh-server ?
[16:34] <ogra_> we dont ship it preinstalled
[16:34] <slangasek> am I being trolled
[16:34] <ogra_> heh, sorry
[16:34] <ogra_> the dev images used to have it by default
[16:34] <slangasek> ogra_: yes, I can tell the difference between a machine that's running an ssh server and one that isn't ;)
[16:35] <ogra_> we only disabled it in the last build before UDS, thats why i'm asking
[16:35] <slangasek> ogra_: the problem I'm seeing is that the connection hangs *after* authentication, once the tty is supposed to be opened
[16:35] <slangasek> and I then can't kill the client using either ^C or ~.
[16:35] <ogra_> wow, weird
[16:35] <slangasek> so it's in some weird state
[16:36] <ogra_> never had that prob here, did you create your own user or do you use ubuntu@ ?
[16:36] <slangasek> ubuntu@
[16:36] <slangasek> I don't see how it could be related to the user, though
[16:36] <slangasek> I'm suspecting a bug in the network drivre
[16:36] <slangasek> driver
[16:36] <slangasek> because there are some suspicious retransmits shown in a packet trace
[16:37] <ogra_> might be, but its the first time i hear about it
[16:37] <slangasek> you should bring your nexus over to my wireless, to see if it's reproducible :P
[16:37] <ogra_> hahaha, ok, approve the flight and i'll be right there
[16:37] <seb128> mdeslaur, did you see https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1068486 while doing piloting yesterday?
[16:37] <slangasek> ok, if you haven't heard anything about it I guess I'll keep futzing until I figure it out :)
[16:37]  * ogra_ could need the miles
[16:38] <seb128> mdeslaur, (I guess security uploads need sponsoring from somebody in the security team)
[16:38] <ogra_> mfisch, did you ever see any issues with ssh'ing into the nexus ?
[16:38] <ogra_> (or heard about them)
[16:39] <bdmurray> fwiw I haven't had any issues and I'm closer to slangasek
[16:40] <mfisch> ogra_: I had issues more with wifi/connectivity
[16:40] <mdeslaur> seb128: no, didn't notice that yesterday...jdstrand is on community this week, so he'll go down the security sponsoring list at some point
[16:40] <slangasek> bdmurray: I thought the Columbia river was a barrier passable only through heroic effort and at great personal risk ;)
[16:40] <seb128> mdeslaur, ok, thanks
[16:40] <mfisch> ogra_: where I'd have to try ssh 2-3 times before I could get in, but I haven't seen that at home
[16:40] <mfisch> whats the issue?
[16:41] <ogra_> mfisch, for slangasek the connect attempt seems to hang the whole connection
[16:41] <mfisch> I never saw that
[16:41] <ogra_> i have seen that before but never on the nexus
[16:41] <slangasek> mfisch: see scrollback for details; summary: connected to wifi, the ssh connection consistently hangs right after sending env variables (according to ssh -v), leaving the client in limbo
[16:41] <mfisch> we had those early issues with the certs, but those were all fixed
[16:41] <ogra_> (in a way that you cant ctrl-c out of it and need to kill -9 from another termianl)
[16:42] <slangasek> bdmurray: but yeah, happy for you to swing by sometime and check if this is reproducible, or trade off hardware or something
[16:42] <ogra_> and now that i think about it, i have actually only ever seen it on arm
[16:42] <mfisch> I'll be back in 20, will catch up on SB then
[16:42] <slangasek> (much though it would pain me to part with nexus7-geekiest)
[16:43] <ogra_> lol, well, newer images  just use uuidgen now
[16:43] <ogra_> no more shiny names
[16:43] <ogra_> there are to many explicit words in dict
[16:46] <xnox> jodh: you rock! =)
[16:47] <jodh> xnox: autopkgtest you mean?
[16:47] <xnox> yeah =)
[16:47] <ogra_> [main.c]          add_display_and_keyboard_for_console:adding display and keyboard for console /dev/none
[16:47] <ogra_> *sniff*
[16:48] <jodh> xnox: ... I'll send you one of my new grey hairs after spending the day poking it for that compliment! :-)
[16:48] <xnox> jodh: nah... I have enough thanks =)
[16:49] <jodh> xnox: haven't achieved full disentanglement, but I think its close.
[16:49] <ogra_> so the --kernel-commandline= option is ignored as well
[16:49] <ogra_> from the log it looks like it is a newly spawned process doing that though
[16:49] <Logan_> Can somebody please perform a requeue on the hives package, per Bug 714622?
[16:50] <Logan_> $ requeue_package.py --full hivex
[16:50] <Logan_> (meant hivex above as well)
[16:50] <cjwatson> Logan_: #bzr or #launchpad probably better
[16:50] <Logan_> Hmm, alright.
[16:51] <Logan_> I figured this would be the most specific channel for that kind of request.
[16:52] <xnox> Logan_: hmm.... but I don't think I pushed over-wrote hivex.
[16:53] <Logan_> Oh, weird.
[16:53] <xnox> Logan_: maybe it's the raring-proposed -> raring & britney interraction with udd?!
[16:53] <Logan_> There are so many packages with that error, I was beginning to speculate that push --overwrite wasn't the only thing causing it.
[16:53] <Logan_> Ooh, that's an interesting conjecture...
[16:54] <xnox> Logan_: what's the actual error/bug you are seeing with hivex?
[16:54] <Logan_> When I try to do bzr branch ubuntu:hivex, the branch is reported as "OUT-OF-DATE."
[16:54] <Logan_> I was going to do a Debian merge. :P
[16:56] <Laney> it happens, and shouldn't stop you - the old tools are still available
[16:56] <Laney> or you could likely use bzr import-dsc to still use the bzr workflow if in the end you supply a debdiff to be sponsored
[16:57] <slangasek> import-dsc of a Debian version is a good way to ensure the branch remains broken
[16:57] <slangasek> since that needs to happen on the Debian branch, which you won't be able to write to
[16:57] <Laney> I carefully suggested not pushing anything
[16:59] <slangasek> oh, you said debdiff, right
[16:59] <slangasek> sorry, had momentarily forgotten what those were ;)
[17:15] <ev> bdmurray: can you file a bug for this against http://bugs.launchpad.net/errors ? With your json API and subscription ideas
[17:15] <bdmurray> ev: of course
[17:15] <ev> thanks
[17:16] <ev> I just want to have more of a think of how this will look in the UI
[17:19] <seb128> could somebody reject https://code.launchpad.net/~carifio/lightdm/lightdm-lp967229/+merge/131478 ?
[17:20] <stgraber> seb128: done
[17:20] <seb128> stgraber, thanks
[17:20] <Laney> can we get an "ubuntu-13.04-feature-freeze" milestone?
[17:22] <stgraber> Laney: doing
[17:23] <Laney> I forget what we agreed at UDS - wasn't it monthly ones except for (as well as?) feature freeze and beta?
[17:23] <Laney> stgraber: thanks
[17:23] <stgraber> Laney: done. I also moved beta-1 to the proper date
[17:24]  * Laney hands stgraber a Launchpad Gardener achievement
[17:25] <jpds> Laney: I'm sure any garden next to a rocket launchpad is doomed
[17:27] <smoser> is there some way to convince 'do-release-upgrade' to just do the thing and not prompt me?
[17:27] <smoser> do-release-upgrade --just-do-it-already!
[17:39] <seb128> can somebody mark https://code.launchpad.net/~darkxst/ubuntu/quantal/telepathy-logger/lp1049210/+merge/131497 merged?
[17:40] <smoser> hm.. seems like : do-release-upgrade --frontend=DistUpgradeViewNonInteractive
[17:40] <smoser> seb128, that happened to me too recently.
[17:40] <smoser> "Ubuntu branches" was requested for the merge, and as a result i couldn't do anything.
[17:40] <smoser> was there some change that is causing this?
[17:42] <seb128> smoser, no, it was always like that, merge requests targeted to a stable serie are "stucked"
[17:43] <smoser> ah. so 'stable' was what was different.
[17:43] <seb128> quantal is frozen, the request should have been targetting an active serie, e.g quantal-proposed
[17:43] <smoser> right.
[17:43] <smoser> well, but annoyingly there is no 'quantal-proposed' for the first sru
[17:46] <seb128> smoser, yeah, UDD doesn't work great for SRUs
[17:48] <smoser> darkxst, ^ can you mark that merged?
[17:53] <dobey> barry: did you subscribe twisted-buildslaves to your ubuntuone-control-panel branch?
[18:12] <cjwatson> sigh, coreutils is one of those packages that can't build on overlayfs, isn't it ...
[18:13] <cjwatson> (tail -f tests run into broken inotify support)
[18:25] <xnox> cjwatson: $ mk-sbuild --vg scratchvg raring
[18:25] <xnox> =)))))))
[18:26] <xnox> lvm snapshots win over overlayfs =)
[18:27] <stgraber> that or just replace tail by a symlink to the busybox binary
[18:27] <cjwatson> that wouldn't be a terribly brilliant test of coreutils tail
[18:27] <stgraber> indeed :)
[18:28] <stgraber> I'm surprised nobody fixed the kernel to actually do inotify on overlayfs, that bug has been there for years now...
[18:29] <cjwatson> and yes, I'll start using lvm snapshots when I get round to rearranging partitions on my laptop
[18:29] <cjwatson> (i.e. not soon but ...)
[18:30] <Daviey> meh, i wouldn't switch back to lvm myself.
[18:31] <xnox> cjwatson: well I did partitions surgery late last cycle to have half disk encrypted lvm and the other half "unembargo" aka non-encrypted lvm for builds.
[18:31] <xnox> now, I need to test grub2+luks+lvm without separate /boot and then I can switch to that & convert my /boot to be come UEFI system partition
[18:32] <xnox> this is a surgery for this cycle =)
[18:33] <Sweetshark> doko_: I scped boost1.49_1.49.0-3.1ubuntu4 for raring to chinstrap btw
[18:48] <barry> dobey: re bug 1029094: do you need anything more from me?
[18:50] <dobey> barry: don't think so; but glyph was complaining about getting spammed by the bug (was actually the merge proposal); and it looks like for some reason twisted-buildslaves was subscribed to the branch which you proposed
[18:50] <barry> dobey: weird
[19:30] <darkxst> smoser, done.
[20:38] <alexbligh1> cdrom/try-usb was removed from cdrom-detect somewhere between lucid & precise; does something else in the installer use this flag?
[20:58] <Daviey> tyhicks: Geez, why do you still need a sponsor?
[20:58] <tyhicks> Daviey: Because I still don't know what I'm doing half of the time :)
[20:58] <Daviey> tyhicks: join the club :)
[20:58] <tyhicks> Daviey: I'm also waiting on sbeattie
[20:59] <Logan_> mterry: Regarding Bug 1038298 (which you just forwarded to Debian), that typo only appears in the Ubuntu delta...
[20:59] <Daviey> tyhicks: I've said the same to him.. but i think i went as far to say i wasn't going to sponsor his work anymore, to try and persuade him to apply.
[21:00] <tyhicks> Not a bad idea... :)
[21:00] <Daviey> tyhicks: I take that back, your upload isn't lintian clean. :)   E: acpid changes: bad-ubuntu-distribution-in-changes-file raring
[21:01] <tyhicks> See...
[21:03] <mterry> Logan_, shoot.  I looked at the changelog to see if that were the case, but I didn't look at the actual delta with debian
[21:03] <mterry> Logan_, OK, thanks.  I'll close that bug out then.  :-/
[21:03] <Logan_> mterry: Haha, alright. No worries.
[21:04] <Logan_> mterry: Also, any chance of approving my merge request, in that case?
[21:04] <mterry> Logan_, sure
[21:08] <barry> bdmurray: uploaded to quantal-proposed
[21:10] <tyhicks> Daviey: Actually, I just tried lintian again and didn't see that error. What am I missing?
[21:13] <Daviey> tyhicks: Sorry.. I did this from my 12.04 system, which didn't know raring was a valid release.  You did nothing wrong, i was pulling your chain.
[21:14] <tyhicks> Aha... I figured that was the problem :)
[21:40] <mterry> @pilot out
[21:55] <mightyiam> hiii raring here from upgrade from quantal. when logging in through lightdm i get thrown back to lightdm immediately. which logs should i check?
[21:59] <mightyiam> i've something in auth.log about dbus rejected send message seems to be from indicator-session-service to console-kit-daemon
[22:00] <mightyiam> otherwise i didn't find anything terrifying in the logs
[22:09] <mightyiam> libsecret-1-0 conflicts with itself. this causes a conflict between the amd64 and the i386 versions of it, breaking stuff when ia32-libs-multiarch is needed
[22:21] <mightyiam> submitted the libsecret issue as bug #1076766
[22:34] <mightyiam> issue where i can't login is submitted as bug #1076777
[23:02] <TheMuso> mightyiam: Are you possibly getting this bug? https://launchpad.net/bugs/1076787
[23:03] <slangasek> mmm
[23:03] <slangasek> xnox: ?
[23:05] <TheMuso> He was planning to turn in. I was following on in #ubuntu-desktop where he noted that he filed this bug.
[23:05] <slangasek> ok
[23:06] <slangasek> hmm, why does he have fglrx installed on an intel system?
[23:09] <slangasek> Sarvatt: fwiw the system in bug #1076787 is xnox's laptop, I'm reasonably certain he didn't have a removable AMD card in it
[23:10] <slangasek> which suggests to me that the fglrx may not have been of his choosing :/