[00:09] Hello [00:09] I'm wondering about licensing issiues regarding ubuntu development [00:11] I'm working on an enterprise app that would interface with my software on Ubuntu [00:11] the android app would be paid, the Ubuntu part is intended to be open sourced on via launchpad [00:12] can I use any part of Ubuntu logo on the paid android app? === Tonio_aw is now known as Tonio_ [00:22] ironhalik: http://www.ubuntu.com/aboutus/trademarkpolicy [00:23] ironhalik: (short answer: no) [00:24] Or I need to contact canonical :> [00:26] Thanks for the link [00:43] bdmurray: still there? === cpg is now known as cpg|away [00:43] GunnarHj: yes [00:44] bdmurray: Good. I don't see any signs in Launchpad of your SRU uploads. [00:45] GunnarHj: well its there - https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1 [00:46] GunnarHj: somebody from the SRU admin team needs to approve it so it ends up in -proposed [00:46] bdmurray: Aha, didn't know that. Thanks! === cpg|away is now known as cpg === cpg is now known as cpg|away [02:23] Hello. If anyone is willing to help, I'm having a unique problem in 12.04 [03:52] 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] Launchpad bug 926676 in gcalctool (Ubuntu) "False result after special character input" [Medium,Fix committed] [03:52] mfisch, yes, if it's in quantal [03:53] robert_ancell: it is as far as I can tell === Logan_ is now known as Guest30878 === Logan__ is now known as Logan_ [04:45] Good morning [04:45] infinity: initramfs-tools> pinky thanks! [04:46] pitti: Thank me when I get it done. Working on an obscure glibc bug right now. :P === cpg|away is now known as cpg [05:37] cjwatson: FYI, just filed bug 1076237; nice example of how autopkgtest detects regressions introduced by a new proposed apt :) [05:37] Launchpad bug 1076237 in apt (Ubuntu) " /etc/kernel/postinst.d/apt-auto-removal creates comment with invalid # character" [Undecided,New] https://launchpad.net/bugs/1076237 [06:07] pitti: Except that it got the regression target wrong. [06:08] pitti: Unless you meant "this is a regression IN $version"... "from" makes it sound like that version was okay. [06:13] infinity: what I meant is that this upload introduced the wrong "#" comment [06:14] pitti: Ahh. The wording was ambiguous, then. ;) [06:14] infinity: so grammatically, "regression in " is better? [06:14] pitti: Or, rearrange the sentence entirely to "This regression appeared in $version" [06:14] even better :) [06:17] 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] autopkgtest doesn't necessarily have a concept of which version worked, only that the current one's broken. [06:18] True :( [06:18] It's assumed to be a regression only because we assume the tests all currently pass. [06:19] (Which won't be true in the case of racy and nondeterministic test-suites, but we need to stamp those out) [06:19] yeah, autopkgtest didn't tell me that, I just reviewed the diffs and checked which upload introduced it [06:19] all tests passing also isn't true if we start TDDD, where we define the behavioural tests prior to patching packagegs. [06:20] persia: You may have one too many Ds. [06:20] I most decidedly don't. [06:20] Test-driven dessert development? Yum. [06:20] Test driven distribution development [06:20] See liw's blog posts from ages ago [06:20] o/ [06:21] lifeless: Is the highlight on "TDD" or "TDDD" or just fuzzy neural matching semantics beneath the threshold of conciousness? [06:21] godlike powers of observation [06:21] Ah, I knew it was something [06:22] 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] (whlie liw's blog posts are old, some of these discussions were active in the just passed UDS) [06:23] I think at the beginning cjwatson only wanted to introduce blocking on autopkgtest regressions [06:23] That's my understanding also. [06:23] persia: I consider an XFAIL a pass, from the POV of not regressing. [06:23] i. e. if a package test already fails in -release, a -proposed failure wouldn't block [06:23] infinity: Excellent then. [06:23] that's still a bad situation of course, as eternally failing tests render the whole idea moot [06:24] (Granted, I'd prefer if all our software were in a state where XFAIL wasn't ever needed, but whatever) [06:24] pitti: Are we running against -release for comparison, for packages that haven't been updated since warty? [06:24] persia: yes, we run both [06:24] https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/ [06:24] Ah, then I misunderstood. Excellent. [06:24] we started with that, and in quantal we introduced testing against -proposed, too [06:25] pitti: Thanks for the quick overview: helps me to catch up :) [06:25] pitti: Anyhow, yay for it catching a bug, fix uploaded. [06:26] infinity: oh, thanks; I was going to wait for mvo for upstreamization, etc. [06:26] pitti: This isn't upstream. [06:26] so I guess we don't really want to support the # character there then [06:27] 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] funny debdiff (http://launchpadlibrarian.net/122343308/apt_0.9.7.6ubuntu2_0.9.7.6ubuntu3.diff.gz) [06:27] pitti: So, was just a goof on vorlon's part when he used #, that's all. [06:27] yay for having autom4te.cache in packages.. [06:27] Yeah, apt's build system is a mess. [06:28] Refreshing the po files on every version bump is lunacy too. [06:28] so, thanks! [06:28] infinity: btw, I found that "debuild -S -nc" helps with those cases [06:29] but yes, it's still mad [06:29] and more important for SRUs [06:29] pitti: I use -nc all the time, I don't -nc apt intentionally cause this is also how it updates its version. [06:29] (Granted, the version will update on clean during the build, but it'll be wrong in the source until then) [06:29] Um, isn't needing to use -nc a bug as clean wouldn't be idempotent? [06:30] persia: clean is idempotent for apt. [06:30] persia: If you mean to use the actual meaning of the word. :P [06:31] 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] Right, that's what it means. And it is. [06:31] the problem here is what it does at the first time :) [06:31] It's that the first run of clean won't leave you at the same state as you were pre-clean. [06:31] Doing it 17 more times won't change state. [06:32] But I don't understand how this could be important for SRUs, as presumably the last upload was also clean. [06:32] (Well, except for automate.cache jumping line ordering around, but we'll ignore that) [06:32] persia: I meant, it's better to have minimal diffs for SRU reviews [06:32] persia: It just makes SRU diffs more readable, other than that, it matters not. [06:32] rather than diffs which are full of autom4te and .po update noise, which make the actual changes harder to see [06:32] And, honestly, our SRU reviewers are smart enough to filter noise from diffs. [06:33] 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] persia: Every new version/upload will change some bits on clean. That's not a problem. [06:33] infinity: actually, I don't think it's idempotent as the .po file timestamps would always change [06:33] (Well, it's a horrible build system and silly decision, but it's not actually buggy, just gross) [06:34] 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] Anyhow, fixing that mess is somewhere low on the TODO of pretty much everyone who's ever uploaded the package. [06:34] One of us will get annoyed enough to do it some day. [06:35] Ah, then it is a bug, just not an important bug. My worldview is restored. [06:35] It's only a bug in the world where "wishlist" = "bug", which is questionable in some people's minds. [06:35] It's a feature request that the build system not suck. [06:35] It's not buggy that it does suck. [06:36] (In that it produces sane results, just suboptimally) [06:37] 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] Rather disconcerting. [06:38] It may as well make a sucking noise while it's doing it. [06:44] PATCH: Add staring-at-phone face detection to lock screen [06:44] isn't facelock doing pretty much that already? :-) [07:03] Where are patch pilots? :( [07:06] cjwatson: ping [07:43] good morning [07:47] dholbach: good night [07:48] (off to bed :P ) [07:48] dholbach: Have a nice day :) [07:48] IanWizard-Cloud, sleep tight :) [07:48] thx [08:06] 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] FourDollars: helps to say what you want ... [08:06] cjwatson: ah, ok; I'm mostly concerned about those which never succeeded [08:07] we should fix them anyway, of course [08:07] Or, rather, those that are failing currently in raring, even if they passed previously. [08:07] well, if it's really intractable, worst case we disable them [08:08] yeah, at least until we fix them; I'd love to just have them always pass, it just will take a bit === smb` is now known as smb [08:23] 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] The Ubuntu kernel package is randomly native or not depending on whether the kernel team remembers to put the orig in place :-) [08:25] (as far as I can tell) [08:29] cjwatson: https://code.launchpad.net/~fourdollars/ubuntu/precise/ubiquity/lp1046241/+merge/132653 [08:29] cjwatson: https://code.launchpad.net/~fourdollars/language-selector/singleton_and_escape_key/+merge/132595 [08:30] cjwatson: Could you help to review my patches? [08:30] 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] 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] cjwatson: Thanks for your information. [08:48] smb: So it's native until upstream release, then non-native? === mcclurmc_away is now known as mcclurmc [08:54] persia, yes [08:54] persia, right we don't really have a valid .orig until linus releases with the version we are using [08:55] 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] Usually something like appending ~gitYYYYMMDD to the orig version string. [08:57] 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] 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] FourDollars: I can go ahead and backport that patch to the right branch now if you like [09:03] FourDollars: unless you already have something in progress [09:03] cjwatson: If you can do that, that will be great. :D [09:04] cjwatson: Thanks a lot. [09:08] 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] cjwatson: Got it, Thanks. :) [09:08] can someone drop the xorg-xserver in the sru queue for quantal? [09:09] mlankhorst: apparently someone already did, I don't see it [09:09] https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=xorg only has nouveau [09:10] ah k :) [09:10] mlankhorst: unless you uploaded it in the last 4 minutes? [09:10] nah [09:10] pitti: Could you help to review https://code.launchpad.net/~fourdollars/language-selector/singleton_and_escape_key/+merge/132595 ? [09:11] 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] missing Architecture: lines in the test Packages files; now to determine whether that's a deliberate increase in strictness or a bug [09:15] pitti: I see. Thanks. [09:16] pitti: Do you know where is the Patch Pilots schedule? Any wiki page? [09:16] there's a google calendar for it [09:17] pitti: Could you give me the link? [09:17] it's on https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews [09:18] pitti: Excellent! thanks a lot. === henrix_ is now known as henrix === dbarth__ is now known as dbarth [10:15] 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] let's see how many of those actually work [10:16] \o/ [10:16] :-) [10:16] I saw that Debian got a jenkins instance too: http://jenkins.debian.net/ [10:17] but I couldn't find the autopkgtests in there [10:17] yes, that mass bug filing started because of that [10:17] and 4 of those bugs are already marked wontfix :/ [10:17] it was just set up, it's not yet doing autopkgtest [10:17] dholbach: yeah, Jakub Wilk did that without explanation [10:18] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685508#10 [10:18] Debian bug 685508 in src:sphinx "Please add "XS-Testsuite: autopkgtest" header in debian/control" [Wishlist,Open] [10:19] ah [10:20] so, we'd need to convince LP to generate a Contents-source.gz [10:30] dholbach: pitti: did anybody talk to jwilk? [10:30] not me, I just saw his response [10:31] so if they want to use that field for jenkins.d.o, that certainly works [10:32] but we need to add it until Soyuz learns about contents-source.gz [10:34] it's not certain if he's just a lone voice yet though [10:48] ev, hi, I just experienced bug 1012358. Anything I can provide to help debug it? [10:48] Launchpad bug 1012358 in apport (Ubuntu) "This problem report is damaged and cannot be processed." [Undecided,Confirmed] https://launchpad.net/bugs/1012358 [10:48] tseliot: ping [10:48] mpt: attach the report to the log [10:48] it will be in /var/crash === caribou_ is now known as caribou [10:49] and ew, a python tuple in an error message [10:49] mpt: we really need to turn that UDS presentation of yours into a thousand error dialog paper cuts or something similar [10:50] 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] five errors, I mean [10:51] is the dialog still up? [10:51] yes [10:52] mpt: xprop | grep WM_PID in a terminal window [10:52] click on the error dialog [10:52] that will get you the PID [10:52] then ps aux | grep $whatever_the_pid_is [10:52] oh, now one of the others did the same thing [10:52] ok [10:52] and that *should* give you something like /usr/share/apport/apport-gtk /var/crash/the_report_file.crash [10:53] I hope [10:54] 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] oh right [10:54] because it's being launched from update-notifier in "process all the outstanding reports" mode [10:55] maybe just send a zip of your entire /var/crash directory [10:55] Ah, that's why I get five at once? [10:55] yup [10:55] Yeah, we should fix that :-) [10:55] bug please [10:55] be sure to tag it :) === ubott2 is now known as ubottu [10:58] 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] janimo: ^^ [10:59] 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] mpt: use gksudo and feel all "gnomish" =) [11:01] xnox, file-roller should use PolicyKit to get permission to read the files [11:02] * xnox > seb128 [11:03] xnox, patches are welcome ;-) [11:03] dholbach: ah, thanks [11:07] work items are great and all, but I'd love to be able to indicate finer grained progress for individual items [11:08] but compared to what we used to deal with, I'm so happy to have this [11:10] ev, split the item in more details? [11:10] Where can I find more info on how Ubuntu syncs packages from Debian? [11:10] ..for the development release of Ubuntu, that is [11:10] seb128: yeah, perhaps this is the equivalent of a code smell. I need to refactor my work items :) [11:11] 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] ev, I added the archive [11:12] mpt: cheers, I'll have a look momentarily === _salem is now known as salem_ [11:14] Or more specifically, from which Debian repo(s) does Ubuntu development release get their packages from? testing/experimental? [11:15] zequence, unstable by default [11:15] zequence, testing for LTS releases [11:16] diwic: In practice, but aren't there some package-specific hints for some packages in the sync scripts? [11:16] persia, if so, that's more than I know of [11:18] persia: No. [11:18] 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] (Will need discussion.) [11:19] zequence: the auto-sync script in https://code.launchpad.net/+branch/ubuntu-archive-tools is what actually does the work. [11:20] cjwatson: Thanks [11:21] 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] Or possibly just self-service syncs by developers. [11:22] My memory of that predates that facility, but yes, that is likely more true now :) [11:24] We did occasionally use to get requests to sync stuff from experimental; I don't remember doing so routinely, only on request [11:24] (But you may not necessarily have seen the requests, of course :-) ) [11:25] Indeed, as there were N fora in which they appeared :) [11:32] 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 === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ [11:35] 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] oh, and there is https://android.googlesource.com/device/asus/grouper/+/7fce7d56cb077e869b9509cd2770d92e8cf29dcc/audio/ with some .c files [11:36] 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] mpt: I think I tried to turn whoopsie-daisy into that, but because it was already a project it didn't work [11:37] any suggestions for a name [11:37] ? [11:37] 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] ev, ubuntu-error-tracker? [11:42] janimo: I think it's sauce [11:43] mpt: at what point did you see this error dialog? Was it after you hit show details or continue? [11:44] 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] (for two of the ones, rather) [11:45] 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] pitti: ^ are you okay with me adding the apport project to an ubuntu-error-tracker project group? === Tonio_ is now known as Tonio_aw [11:47] ev: sure, that sounds sensible [11:47] cool === Tonio_aw is now known as Tonio_ [11:52] pitti, mpt: https://answers.launchpad.net/launchpad/+question/213666 [11:52] ev: thanks, subscribed [12:08] caribou: pong === Ursinha is now known as Ursinha-afk === Ursinhal is now known as Ursinha === MacSlow is now known as MacSlow|lunch === Ursinha-afk is now known as Ursinha === Tonio_ is now known as Tonio_aw [12:44] 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 === Tonio_aw is now known as Tonio_ [12:45] tseliot: I'm back. [12:45] tseliot: just wanted to let you know that my Nvidia install issue automagically disapeareed [12:46] tseliot: I was able to enable nvidia-current. But I suspect that, in the meantime, I installed the linux-headers pkg [12:46] tseliot: and it was needed for the dkms build === cpg is now known as cpg|away === Sweetsha1k is now known as Sweetshark === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ === mpt_ is now known as mpt === attente_zzz is now known as attente === notgary_ is now known as notgary [13:47] caribou: ah, good === MacSlow|lunch is now known as MacSlow === dendrobates is now known as dendro-afk [13:56] xnox: hey, are you looking to merge autofs? [13:58] Daviey: yes. [13:58] Daviey: you want it urgently? [14:00] xnox: no,just going through the packages i care most for :) [14:00] ;-) [14:00] pitti: can you hit "Change details" on http://launchpad.net/apport and put "ubuntu-error-tracker" in the "Part of" field? [14:00] considering debian has been in freeze.. the list is larger than i hoped :) [14:01] ev: oui, je peux [14:01] cheers [14:01] ev: done [14:01] yay [14:02] mpt: bam! https://launchpad.net/ubuntu-error-tracker [14:02] ev: that just made me aware of an OMGcritical bug [14:02] oh? [14:02] ev: daisy and whoopsie SO MUCH need a proper icon! [14:02] hahaha I was just thinking that a moment ago [14:03] mpt? :) === dendro-afk is now known as dendrobates [14:03] 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] Error: malone bug 1059938 not found [14:03] I'd quickly assume it's hardware (which we should handle, regardless), but I'm not ruling out something more nefarious [14:04] 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] ev: yeah, if it doesn't have dupes, I'm inclined to attribute it to cosmic rays [14:07] pitti, it's happened to me three times today, and sunspot activity has been quiet this week [14:07] god damn I love errors.ubuntu.com [14:08] I mean, I realise that's slightly self-congratulatory [14:08] mpt: oh, you can reproduce this? [14:08] but I looked at apport and there was just that one instance [14:08] then I looked at https://errors.ubuntu.com/?package=apport-gtk&from=year [14:08] and it's the #3 most common issue in apport [14:08] ev: wow, and look at the rate 13.04 is getting better :) [14:09] pitti, no, it's just three that happened to appear today [14:09] :) mpt has some math to smooth those spikes out [14:09] ok, so that is real then [14:09] pitti, I think the first day of 13.04 was just 12 of the same problem [14:09] or something like that [14:09] it still looks nice :) [14:15] 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] (with it expanding on the right hand side to include the next release day) [14:19] pitti: you said that ddebs.u.c was back to normal, right? [14:19] ev: it should, yes [14:19] yay [14:20] the bug got closed anyway [14:20] :) [14:20] cheers [14:20] I've notified webops === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ === Guest30312 is now known as vibhav === Quintasan_ is now known as Quintasan [14:44] * xnox did something naughty [14:44] * xnox -> lunch [14:54] xnox: explain. [14:54] bdrung: nudge [14:55] Quintasan: you are desperately waiting for it? [14:56] bdrung: Not really THAT impotant but just nudging you [14:56] okay :) [14:57] Quintasan: the fingerprints lay on my desk. so i will not forget to sign the keys. [14:57] Oh [14:57] That's quite a good idea [14:57] * Quintasan spreads the keys on his desk [14:58] 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] at least the keys are not buried under more staff :) [14:59] blog post [14:59] crap [14:59] * Quintasan goes off to do something productive instead of annoying poeple [14:59] people* [15:01] Quintasan: i recommend to work on that: http://reqorts.qa.ubuntu.com/reports/sponsoring/ [15:01] alt+f4 [15:01] bdrung: :P === BenC_ is now known as BenC [15:18] 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] +1 [15:20] Laney: you can go ahead and kill that cloud instance you set up for me to debug python-apt - thanks! [15:20] cjwatson: righto - nailed down? [15:21] eet eez deleted [15:21] Laney: well, mostly [15:22] 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] 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] pitti: what "old libraries" are talking about? =))) http://launchpadlibrarian.net/122375899/ndisgtk_0.8.5-1_0.8.5-1ubuntu1.diff.gz === Tonio_ is now known as Tonio_aw [15:24] xnox: oh, err, wow! [15:25] pitti: I found out that there is no kernel module at the final step of testing in the live cd.... [15:25] :) [15:27] can i get someone to approve the u1db binnew in raring-proposed so it gets to raring? [15:28] mpt, ev: I found a similar bug which is very very likely the same reason, and duplicated bug 1059938 [15:28] Error: Launchpad bug 1059938 could not be found [15:28] the new master is public and has some analysis [15:28] xnox: "replace program with new program" :-) === attente is now known as attente_zzz [15:28] anyway, time to stop sitting in front of that computer for today and play some Badminton, cu tomorrow! [15:29] dobey: looking [15:29] cjwatson: "[14:44] * xnox did something naughty" [15:29] heh, I wondered [15:29] xnox: what about * Port Windows drivers to Linux"? [15:29] * pitti ducks and heads off [15:30] pitti: that was done part of canonical re-writting linux kernel in python, wasn't it? [15:31] dobey: done [15:33] cjwatson: thanks! === Tonio_aw is now known as Tonio_ [15:36] is there a guide for making changes to a package and then submitting them for approval? [15:38] jetsaredim: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff might work? [15:40] astraljava: possibly [15:47] ev, can you stagger alternating milestone markers? [15:48] ev, i.e. odd-numbered ones higher than even-numbered ones [15:48] 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] ev, eventually. [15:49] mpt: so you'd like to see if we can include all the data we have so far for the default view? [15:50] ev, definitely, I'd like to see the past five years in the default view [15:50] okay, I'll give that a bash [15:50] (even if the horizontal scale ends up a log scale to show the past few months in more detail) [15:53] mpt: wouldn't that be confusing given that our x-axis currently only shows values for the milestone dates? [15:53] it would be hard to see that it was in fact a log scale [15:54] ev, it would, we'd need to add other tick marks before then [15:54] or at the same time [15:56] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry [16:02] * dholbach hugs mterry [16:02] :) === Tonio_ is now known as Tonio_aw [16:10] 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 === Tonio_aw is now known as Tonio_ [16:11] 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] what is the review process for a patch to a quantal package? [16:12] ev: well, its bug 875879 where the error was in aptdaemon not update-manager. [16:12] Launchpad bug 875879 in aptdaemon (Ubuntu Quantal) "update-manager crashed with AttributeError in show_diff(): 'NoneType' object has no attribute 'group'" [High,Fix released] https://launchpad.net/bugs/875879 [16:14] 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] 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] brb [16:21] 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] 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] ev: I guess I'd like to "subscribe" to the bucket and get emails regarding counts [16:25] ogra_: it certainly is supposed to affect which tty the splash appears on [16:25] 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] slangasek, http://paste.ubuntu.com/1342880/ [16:26] the nexus bootloader has a hardcoded console=none ... we override that with the kernel cmdline options to console=tty1 [16:26] but it seems to pick none as default no matter what i do [16:27] add_consoles_from_kernel_command_line:console /dev/none found! [16:27] and that is a clear lie :) [16:28] ogra_: oh; but console != tty of course [16:28] there is no /dev/none anywhere [16:28] so this would be a bug in plymouth's /proc/cmdline parsing [16:28] yeah, it should ignore =none [16:28] (IIRC, one you've run into in the past on ARM :P) [16:29] i only ran into the "serial ttys foirce splash to off" one [16:29] yes, which is the same bug :) [16:29] and that seems fixed since 0.8.5 [16:29] (which we dont have yet) [16:29] plymouth should support multiple specifications of console= and DTRT with them [16:29] ok [16:29]