[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_<IP_ADDRESS>ubuntu2_<IP_ADDRESS>ubuntu3.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<EMAIL_ADDRESS>[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<PHONE_NUMBER>0 ?        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 :/


[12:16] <nhaines> Ubuntu 13.04 has been released. :)
[18:55]  * MarkDude responded to Removing the Community (from header)
[18:55] <MarkDude> https://plus.google.com/u/1/105095769731159704550/posts/KYEjCB954ds
[18:55] <darthrobot> [R: plus.google.com] Title: [Mark Terranova - Google+ - #ubuntu #fail Most folks in #FOSS will admit Ubuntu is…]
[18:55] <MarkDude> Also commented on bug now marked wont fix
[18:55] <MarkDude> That was closed 20 hours after dialog was implied
[19:10] <Torikun> good post MarkDude
[19:14]  * MarkDude has seen wont fix overused
[19:15] <MarkDude> dialog did not happen
[19:15]  * MarkDude will debate Jorge more if he wants to
[19:15] <MarkDude> Really hoping Ubuntu people take the lead
[19:15]  * MarkDude has no issue doing it tho
[19:16] <MarkDude> The goes beyond one Distro
[19:16] <MarkDude> Community is key to everything
[19:16] <Torikun> yup
[19:16]  * MarkDude 's motivation here is pure
[19:16] <Torikun> but ubuntu delivers
[19:16] <Torikun> well
[19:16] <MarkDude> full disclosure; Me pointing out Ubuntu does not have Linux on its site was a jab
[19:17] <MarkDude> Fully
[19:17] <Torikun> yeah
[19:17] <Torikun> they should
[19:17]  * MarkDude really understands the logic of it tho
[19:17] <MarkDude> And figure that does not upset Ubuntu's Community as much as some in FOSS
[19:17] <MarkDude> Anyway
[19:18] <Torikun> they way ubuntu is going now, they will likely replace all teh GNU tools lol
[20:21] <MarkDude> https://lists.ubuntu.com/archives/ubuntu-us-ca/2013-April/002211.html
[20:21] <darthrobot> Title: [[Ubuntu-US-CA] Community removal;am I over-reacting here? Where is the discussion?]


[11:30] <jonnylamb> There are two branches for each maemo module on Launchpad, "ubuntu" and "trunk". Am I right in thinking that trunk is automatically merged with each svn commit on the maemo.org end; and the ubuntu branch is simply a branch of trunk, for the purpose of cleaning up the package for Ubuntu?
[12:27] <Mithrandir> jonnylamb: that is correct.
[12:27] <Mithrandir> the trunk is an import of svn to bzr
[12:45] <jonnylamb> Mithrandir: Thanks.
[12:45] <jonnylamb> Why do you do that though?
[12:46] <jonnylamb> Why are you taking each commit?
[12:46] <jonnylamb> Why not just use the releases?
[12:49] <Mithrandir> because preserving history is important
[12:49] <Mithrandir> and working without the support from a revision control system is horrible
[12:51] <jonnylamb> Oh I think I understand now. You're merging in changes only when a release comes out? Only this way, the bzr history is lovely and full of changes made to maemo svn?
[12:52] <jonnylamb> I was "worried" you were packaging and _releasing_ stuff that was trunk material, i.e. not necesserily stable.
[01:04] <mdz> jonnylamb: we are packaging trunk in many cases, yes
[01:04] <mdz> jonnylamb: but we are not releasing until October
[01:06] <jonnylamb> Is the reason of using this vcs-imports method to keep history even on the stage.maemo.org side? As in keeping track of all their commits?
[01:09] <mdz> jonnylamb: it's so that we can maintain our own distributed branches
[01:10] <mdz> it's like being able to work inside svn, but without requiring accounts etc.
[01:10] <mdz> so we have all the benefits of revision control but the flexibility of decentralization
[01:36] <lool> Hi there
[01:36] <lool> I'm sorry I couldn't attend the meeting, I would have loved offering my help on a couple of things such as Gtk bits
[01:37] <lool> I discussed some implementation details with seb128 and other folks
[01:41] <lool> Hmm I see agoliveira already found about g_key_file_free() instead of g_free()
[01:44] <Mithrandir> yeah, he did
[01:44] <Mithrandir> according to a mail he sent me yesterday, the theme builder now works
[01:56] <Mithrandir> oh, docs, why do you hate me so?
[01:57] <tko_> gtk-doc problems?
[01:58] <Mithrandir> make run in the top level directory doesn't run make docs
[01:58] <Mithrandir> which makes dh_install quite unhappy.
[01:58] <tko_> I thought I hacked my way around that
[01:59] <tko_> hmm, no, I did the hack in hildon-1
[01:59] <lool> Mithrandir: I simply passed --disable-gtk-doc here  O:-)
[01:59] <Mithrandir> lool: I made debian/rules call make doc too
[01:59] <Mithrandir> hm, why is the --disable-gtk-doc there?  That might explain it
[02:00] <tko_> because we don't have recent enough gtk-doc
[02:00] <Mithrandir> but we do
[02:00] <lool> --disable-gtk-doc instructs to not build doc at make time, but disted tarball should use --enable-gtk-doc and ship the pre-built docs
[02:00] <lool> You don't want to build the doc on each build, except if you're running autogen
[02:01] <Mithrandir> hmm
[02:01] <Mithrandir> shouldn't just the normal make rules govern that?
[02:01] <lool> Not sure what you mean
[02:02] <lool> Hmm where's the gtkdocize call in autogen?
[02:02] <Mithrandir> why is this a configure flag rather than just having a rule in the Makefile that rebuilds the docs if the sources have changed?
[02:02] <Mithrandir> no gtkdocize call there
[02:02] <lool> Mithrandir: There's such a rule _if_ you pass --enable-gtk-doc I think
[02:02] <Mithrandir> oh, ok.
[02:03] <Mithrandir> then I think passing --enable-gtk-doc should be fine.
[02:03] <lool> Well, only if you autogen
[02:03] <Mithrandir> -fm does that automatically at first.
[02:03] <lool> If you don't want to autogen, you should prebuild the docs oo
[02:03] <Mithrandir> why shouldn't they be built as part of the package?
[02:04] <lool> The gtk-doc rules are using autotools convention which suggest that they should be make disted
[02:04] <lool> For example, dist-hook, maintainer-clean-local, etc.
[02:05] <Mithrandir> we can change it later if we think that makes sense; I'll just pass --enable-gtk-doc for now.
[02:05] <lool> It's a choice the gtk-doc developers made that their gtk-doc.make will help you _produce tarballs_ with doc, but not produce tarballs which build doc
[02:05] <lool> Mithrandir: Ok, but be aware that it wont possibly clean properly
[02:06] <Mithrandir> true, make distclean doesn't clean it.
[02:07] <lool> Exactly
[02:07] <Mithrandir> but the package builds that way, which I think is more important.
[02:08] <lool> I would personally call autogen.sh in this case
[02:08] <lool> But right, the important thing is to get forward :)
[02:08] <Mithrandir> I'm tempted to say "this wouldn't be a problem if we had proper upstream releases", something I'm confident will happen sometime soonish.
[02:08] <lool> I concur fully
[02:09] <lool> Exactly like striping the debian/ out is currently a pain because I'm using non-native mode; this will disappear with upstream tarball releases
[02:09] <lool> I wonder why it build for me here though
[02:10] <lool> Haha, I passed --enabled-gtk-doc :)
[02:10] <lool> Do like I say, not like I do
[02:11] <Mithrandir> haha. :-)
[02:12] <lool> Ah I recall why now; this debian/rules did not have a special autogen.sh section
[02:12] <Mithrandir> config.status: if [ ! -x configure ] ; then ./autogen.sh; fi
[02:12] <Mithrandir> with a newline after the first :
[02:13] <lool> Yeah, but no "configure" rule lke some others
[02:13] <lool> with flags passed to autogen.sh
[02:13] <Mithrandir> ah, point.
[03:00] <Mithrandir> tko_: is there any reason not to let hildon-fm depend on hildon-fm-l10n with a specific version number rather than using the mr / mr0 /mrX approach?
[03:15] <tko_> I don't recall the details why the packaging was done the way it was. presumably because depending on virtual package doesn't install any concrete one
[03:16] <Mithrandir> which is why you'd have something like Depends: hildon-fm-l10n-english | hildon-fm-l10n and have all the different hildon-fm-l10n-XX packages provide the former.
[03:16] <Mithrandir> the former = hildon-fm-l10n in this case
[03:23] <Mithrandir> dpkg-deb: Bygger pakken libhildondesktop0 i ../libhildondesktop0_0.0.14-2ubuntu2_i386.deb.
[03:23] <Mithrandir> \o/
[03:25] <mdz> Mithrandir: !
[03:26] <Mithrandir> no idea if it installs yet, but we're getting there.
[03:55] <bintut> what filesystem do you use for the upcoming ubuntu-mobile?
[06:23] <tko> btw, I just realized I've been doing tarball releases of sapwood since the beginning..
[06:23] <tko> it is causing me some extra pain :)
[06:34] <lool> tko: Do you know how the move to gnome.org is going?
[06:34] <tko> http://live.gnome.org/Hildon/MigrationToGnome
[06:35] <lool> Great; looks good
[06:35] <tko> basically the order was 1) accounts, 2) svn, 3) bugzilla
[06:36] <lool> I see
[06:36] <tko> once we have svn enabled on gnome side, we still need to get svn dump from our side and also get a hole in the firewall
[06:37] <lool> I wonder how the vcs-import switch will happen; promises some fun :)
[06:37] <lool> tko: Ah for SSH I suppose
[06:37] <tko> oh right, and then we're waiting for jdub to set up hildon mailing list
[06:38] <tko> yep
[06:38] <tko> our firewall is a bit paranoid
[06:39] <inz> slight understatement ;)
[07:09] <jonnylamb> May I ask /why/ you're moving to gnome.org?
[07:50] <tko> we want to make hildon less strongly tied with nokia and run it as a true upstream project
[08:01] <tko> btw, who's coming to CA next week? me and moises could use a ride
[09:16] <lool> tko: Is there an IRC chan where mdk is around?
[09:16] <lool> tko: Or perhaps you can fix the weird "AC_ARG_ENABLE " alone on line 117 of libhildon/hildon-1?
[09:19] <tko> lool: I suppose he'd be here or #maemo when he's online, but I'll try fixing it (don't have a checkout here)
[09:19] <lool> tko: Ok, I've fired bugzilla now; want a bug?
[09:19] <tko> lool: give me a minute to finish the checkout..
[09:19] <lool> tko: Right, I see him in the backlog now; thanks
[09:20] <lool> Is there a way to tell the SVN rev from the bzr rev?
[09:20] <lool> This is how bzr log looks: http://paste.debian.net/29986
[09:21] <tko> lool: that would be r11820 but I don't know how you'd get it
[09:21] <tko> bzr-svn maybe?
[09:23] <lool> bzr-svn hung for me when I tried importing haf's SVN; after taking some 1.5 GB RAM + swap, it encountered some incomprehensible error
[09:23] <lool> So I've given up there :-/
[09:23] <lool> tko: I wish it would be visible in the log just like in git-svn
[09:23] <tko> git-svn had no problems with gtk :)
[09:23] <lool> hehe
[09:24] <tko> (our gtk.. I didn't feel like waiting to mirror the whole upstream)
[09:24] <lool> bzr-svn is supposedly transparently integrated, and I have it installed and didn't see anything in the log
[09:24] <lool> (You're supposed to use bzr "normally", for example "bzr branch svn://...")
[09:26] <lool> bzr viz is quite nice
[09:30] <jonnylamb> Certainly is!
[09:30] <jonnylamb> Is there anything like this for git?! :D
[09:31] <lool> gitk I guess
[09:33] <lool> It's cute too; too bad it's not in Gtk
[09:34] <inz> How can they name it gitk, if it's not Gtk?-)
[09:34] <lool> It's in tk :)
[09:35] <tko> lool: committed
[09:35] <jonnylamb> gitk looks damn ugly, but it does the job.
[09:35] <inz> lool, uh, then I guess it's acceptible ;)
[09:35] <lool> tko: thanks!
[09:36] <lool> tko: I'll file a bug directly next time; it's WE after all :)  I was mostly curious as to whether you were using a private IRC channel, but seems not
[09:37] <tko> lool: if we were it would be somewhere in the intranet :)
[09:37] <tko> remember, we're only moving towards being an upstream project :)
[09:44] <Knowledge_> Ubutu Mobile + n800 = dream machine...
[09:44] <Knowledge_> if the mobile version is anything like the desktop version...
[09:50] <tko> Knowledge_: what is lacking in the software shipped with n800 ?
[09:51] <Knowledge_> tko: honestly nothing, I love it...I just like modding stuff....
[09:51] <tko> :)
[09:51] <Knowledge_> I'm not one of those "ohhh the 770/n800 are so terrible because I can't run apache on it"....yadda yadda...I bought it because of what it was advertised to do...and it does that flawlessly....
[09:51] <tko> there's always hex editor.. :-P
[09:52] <tko> I thought someone already ported apache.. or some other web server atleast (forgot the name)
[09:54] <Knowledge_> oh...well you get what I mean...there's people on the iTt forums that whine and whine cause the device doesn't suck their....well, I'm pretty sure you know what I'm getting at
[09:55] <tko> yeah, I know
[09:55] <Knowledge_> I love the device...
[09:55] <Knowledge_> barely use it and it's still the best $400 I've ever spent
[10:09] <lool> tko: lighthttpd perhaps
[10:10] <lool> or lighttpd either
[10:10] <tko> lool: no, it was some other indian IIRC
[10:22] <tko> cherokee
[10:30] <lool> Ah right
[10:30] <lool> I was thinking about a project hosted in India
[12:00] <jonnylamb> What does "mce" stand for?
[12:01] <jonnylamb> Forgive me, "Mode Control Entity". However, I'm a little unsure on what it is/it does ?
[12:01] <jonnylamb> It seems to be mentioned, but not documented here: https://lists.ubuntu.com/archives/ubuntu-mobile/2007-May/000098.html


[02:18] <pleia2> copying things over now, I'll do editorial review of my own tomorrow (have to leave for a concert soon, oops)
[02:38] <pleia2> Unit193: link check? https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue405
[02:38] <pleia2> and sending to editors
[02:40] <Unit193> Juuust the normally broken ones, all good.
[02:40] <pleia2> thanks :)
[16:36] <PaulW2U> Editorial Review underway, trying apply the style guidelines to all summaries.
[16:37] <PaulW2U> I agree with imnichol, Canonical summaries are the most difficult to write (and correct)
[16:38] <imnichol> I guess that makes me a thought leader ;)
[16:38] <imnichol> PaulW2U, anything I can do to help?
[16:39] <PaulW2U> pleia2: Please wave your magic wand over Canonical's articles and make the summaries good :)
[16:41] <PaulW2U> imnichol: Just reviewing what we've done, reviewing the wiki summaries, tidying up ready for publication.
[16:51] <PaulW2U> imnichol: If you feel you can improve any of the Cloud or Canonical summaries then please do so.
[16:51] <PaulW2U> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue405
[16:52] <imnichol> No promises ;)
[16:52] <PaulW2U> I'm not liking the way some of the second/third sentences of the summaries start.
[16:56] <imnichol> Is that under section 10?
[16:56] <imnichol> Or under the Cloud News section?
[16:57] <PaulW2U> Both
[17:13] <pleia2> PaulW2U: thanks, I'll have a look soon (just waking up now :))
[17:23] <PaulW2U> Only waking up? Some of us have just finished a day's work! If only the word were flat :)
[17:23] <pleia2> haha
[17:23] <PaulW2U> s/word/world/
[17:23] <pleia2> 9:23AM here :)
[17:25] <PaulW2U> 17:23, cooking my evening meal :)
[17:26]  * pleia2 sips coffee
[21:23] <PaulW2U> Added Xubuntu article to the wiki. Review done.
[21:23] <pleia2> PaulW2U: hm, that was published today
[21:24] <pleia2> we typically only include through Sunday
[21:24] <PaulW2U> It's dated 22nd at 0042 ???
[21:24] <pleia2> ah, the date on it is the 22nd, weird!
[21:24] <pleia2> I think that's when I made the draft
[21:24] <pleia2> goofy thing, oh well, you're right then :)
[21:24] <pleia2> thanks
[21:25] <pleia2> I have a dr appointment soon, will review+publish after I get home
[21:27] <PaulW2U> Ok. By the way, spelling/grammar error line 6 :(
[21:29] <pleia2> line 6?
[21:30] <PaulW2U> Of the article -- where should be were
[21:31] <pleia2> ah, gotcha, thanks :)


[09:34] <m_tadeu> good morning. is there a way to recover a system (failing I'm guessing due to a bad update), by mounting the disk on another system?
[09:37] <lotuspsychj3> m_tadeu: try ubuntu's recoverymode from grub first
[09:38] <lotuspsychj3> m_tadeu: you got a lot of options to try there, fix packages with apt, boot into a previous kernel, manualy install packages on a rootshell etc
[09:38] <m_tadeu> lotuspsychj3: I don't think I have access to the boot stage...it's a aws instance
[09:38] <m_tadeu> at least I don't know how
[09:41] <lotuspsychj3> check perhaps if a shift hold or ESC brings you into grub m_tadeu
[09:48] <m_tadeu> lotuspsychj3: unfortunately I can't find a way to do that. is there something I can change in the grub config to trigger that?
[09:49] <lotuspsychj3> not sure sorry m_tadeu maybe someone else has ideas
[09:50] <lotuspsychj3> if you running ubuntu server, you should be at least able to boot into a previous kernels for when things get wrong right
[09:52] <m_tadeu> lotuspsychj3: thanks...well I launch the instance but then I don't have direct access to the machine. I have to connect to it. by that time, the boot menu is long gone
[09:52] <lotuspsychj3> can you ssh into it?
[09:53] <m_tadeu> nop, since it doesn't boot properly...doesn't even get to start the network
[09:55] <lotuspsychj3> yikes
[09:55] <lotuspsychj3> if it doesnt boot properly, we can also not edit grub to try things to boot
[09:59] <m_tadeu> damn...finally was able to get in....after standing for a lot of errors, I'm in bash as root...trying to recover
[10:00] <lotuspsychj3> ah nice
[10:00] <lotuspsychj3> enable networking + rootshell in there
[10:10] <m_tadeu> system recovered...
[10:10] <m_tadeu> lotuspsychj3: appreciate your help
[10:10] <lotuspsychj3> !yay
[10:18] <JanC> doesn't Amazon have something like a remote console?
[10:20] <JanC> or a rescue boot image?
[10:51] <m_tadeu> kind of...I was able to create a new machine that supports serial console connections...then I was able to get it as root (since the boot failed). and despite lots of error messages just popping up, I was able to 'dpkg --configure -a', which fixed the issue
[11:23] <esv> hey folks, are there Ubuntu repos that might match this regular expression ? "http:\/\/[a-z][a-z]\.archive\.ubuntu\.com\/ubuntu"
[11:24] <esv> that looks odd to me but rather check here than just tossing it out
[11:25] <esv> ahhhh maybe country specific?
[11:39] <lotuspsychj3> esv: maybe a question for the #ubuntu-mirrors crew?
[11:39] <blahdeblah> esv: That definitely matches many mirrors
[11:40] <esv> thnx
[11:41] <blahdeblah> https://wiki.ubuntu.com/Mirrors and https://launchpad.net/ubuntu/+archivemirrors have more info if you need it
[11:42] <esv> great


[12:44] <StudioUser72> how do I get the task bar to show on both my screens?
[16:58] <cjdg> Hi there
[16:58] <cjdg> well you can make another panel, unfortunally on plasma 5 its been a feature not available
[17:55] <Eickmeyer> cjdg: They left hours ago.
[17:59] <cjdg> ou
[17:59] <cjdg> :x


[00:59] <mhall119> MichelleQ and I are doing a session in #ubuntu-classroom in about....2 minutes
[03:55] <Chloric> evening strangers
[03:55] <mhall119> hey Chloric
[03:56] <Chloric> hey mhall, hows it going?
[03:56] <Chloric> hows qimo going along?
[03:58] <mhall119> it's coming along
[03:58] <mhall119> looks like I'm not going to make the alpha2 target
[03:58] <mhall119> but I think it's getting closer
[04:03] <Chloric> anything i can do to help?
[04:08] <mhall119> do you know how to build a bootable livecd from scratch?
[04:13] <Chloric> oh man no =/ im a social science major xD
[04:44] <govatent> hey Chloric
[17:12] <mhall119> cjohnston: there was a fire at the Caribe Royale yesterday
[17:19] <cjohnston> yup
[17:19] <cjohnston> pretty good sized one
[17:19] <cjohnston> i posted that in some channel already
[17:20] <cjohnston> maybe -community-team
[17:20] <mhall119> ah, I'm not in that one
[17:23] <cjohnston> fail
[17:28] <MichelleQ> boo.