[00:05] <ogra_> slangasek, so i discovered a quite bad bug with multiarch and am pondering what to file it against ...
[00:05] <xnox> stgraber: do we have wallpapers contest selected?!
[00:05] <ogra_> if you enable any ports arch apt-get update chockes (rightly) on security.ubuntu.com ...
[00:06] <stgraber> xnox: no idea
[00:06] <xnox> ogra_: yes. noticed that as well. hardly new news, one should limit arches on security.
[00:07] <xnox> stgraber: i'll poke seb128 tomorrow.
[00:07] <xnox> bdrung: kk.
[00:07] <xnox> good night all =)
[00:08] <ogra_> xnox, one ?
[00:08] <ogra_> xnox, i used dpkg --add-foreign-arch or some such ...
[00:08] <ogra_> and afterwards apt-get update was broken
[00:09] <ogra_> if we provide that level of automation, the automation should work :)
[00:50] <cjwatson> jamespage,zul: looks like python-babel needs an MIR?
[00:51] <cjwatson> Or else the dep needs to go - can't quite make it out from the diff
[00:53] <zul> cjwatson:  yeah will get to it tomorrow
[00:57] <cjwatson> Ta
[01:45] <ini> are any contributers free for a 5 minute conversation? i'm working on a paper about open source, and would love to hear from a developer
[05:22] <ikepanhc> @pilot in
[05:39] <pitti> Good morning
[05:40] <RAOF> pitti: Yo!
[05:44] <elky> Either apport just sent me to the page for a non-existent bug or to a bug locked for security. Is it supposed to do that? Known issue?
[05:45] <elky> I suspect the former, because incrementing/decrementing the number isn't bringing up any visible bugs.
[05:46] <StevenK> What's the number?
[05:47] <elky> 1142546
[05:47] <elky> doesn't seem to be anything within a range either side of it.
[05:48] <elky> either that, or a few dozen security bugs landed at once.
[05:49] <StevenK> It's private
[05:50] <elky> apport should probably check that...
[05:50] <StevenK> There's an open apport bug about it
[05:50] <elky> heh
[05:50] <StevenK> IIRC
[05:51] <elky> private too, i assume :P
[05:51] <StevenK> I don't think so, but I can't recall the number.
[05:52] <elky> Probably for the best, we'd risk overdosing on irony.
[05:53] <StevenK> elky: People keep blaming LP for this, but I don't think it's an LP problem.
[05:53] <elky> StevenK, for what, the apport not checking that value in the api response or whatever?
[05:54] <StevenK> I'm not sure how apport decides it's already reported as <private bug>
[06:02] <ScottK> Maybe apport has too many privileges on LP.  If it couldn't see the private bugs, it would never dupe against them ...
[06:06] <pitti> there is https://launchpad.net/~apport which owns all private crash bugs until they get retraced and the core dumps removed
[06:07] <pitti> then ~ubuntu-crashes are subscribed to them
[06:07] <StevenK> ScottK: And then you have tonnes of dupes.
[06:07] <StevenK> But we sort of do already
[07:47] <dholbach> good morning
[07:48] <dholbach> Quintasan, happy birthday! :)
[08:50] <mmrazik> cjwatson: morning
[08:51] <mmrazik> cjwatson: did nuclearbob follow up with you yesterday regarding the installing issues?
[08:52] <ikepanhc> @pilot out
[08:55] <seb128> gema_, hey, did you guys notice any issue with raring daily installs recently? mmrazik was looking at why jenkins/utah is failing to run on the unity setup and think it's a platform issue and that you guys probably ran into it as well?
[08:55] <mmrazik> gema_: nuclearbob was looking into that yesterday
[09:07] <gema_> seb128, mmrazik I had a problem installin yesterday but not sure if it is related
[09:07] <gema_> mmrazik: do you have a bug numbeR?
[09:08] <mmrazik> seb128, gema_: I'm just reporting a bug. Will paste the # in a minute here
[09:08] <gema_> mmrazik: ack
[09:09] <gema_> mmrazik: nuclearbob was investigating a problem with bootspeed testing that we had over the weekend as well, not sure if it is the same, though
[09:09] <mmrazik> it most likely is
[09:10] <gema_> mmrazik: ack, it doesn't look solved to me, he attempted to run bootspeed 6 times yesterday
[09:13] <gema_> with 0 success
[09:15] <mmrazik> gema_, seb128, cjwatson: Here is a bug with the issue: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1157065
[09:15] <mmrazik> I hope all the logs are there
[09:15] <mmrazik> if not, let me know
[09:17] <zyga> utlemming: ping
[09:17] <seb128> mmrazik, thanks a lot, I think it has the debug logs needed, let's wait for cjwatson
[09:17] <mmrazik> seb128: I just don't see anything obvious there :-/
[09:18] <mmrazik> hope cjwatson will see more
[09:18] <OdyX> pitti,tkamppeter: Damn, cups 1.6.2 is out, time for a big^2 merge; I'll likely have 'some' time to work on it this week and will start in a different branch (so that master stays buildable at all times)
[09:21] <gema_> mmrazik: thanks a lot
[09:22] <zyga> utlemming: vagrant got 7 new releases, we are still at 1.0.3 which refuses to start on raring with virtualbox 4.2, current vagrant upstream is 1.1.2, do you think we can work on getting FFE and get that package updated?
[09:22] <mpt> ev, did you hear any more from m4n1sh after helping him with the activity-log-manager integration?
[09:23] <ev> mpt: not yet
[09:23] <ev> we exchanged a couple of emails
[09:23] <ev> but I haven't heard anything since
[09:24] <mpt> hmmm
[09:24] <mpt> that's unfortunate
[09:29] <ev> mpt: he did say he felt it unlikely to get done in time for FF
[09:35] <OdyX> win 25
[10:32] <pitti> slangasek: I took the liberty to retarget https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration to s-series and milestone ubuntu-13.05 to reflect the declined FFE
[10:33] <tkamppeter> OdyX, pitti, we can go ahead of getting CUPS 1.6.2 into Ubuntu, seb128 is OK with it as the new release is bugfix-only.
[10:35] <OdyX> tkamppeter: I pushed master-1.6.2 to the git repository, now it needs patches review, refresh and drops, I'll do that later today, if you don't beat me to it.
[10:36] <tkamppeter> OdyX, great, if it gets tready today there is plenty of time that it gets tested in the Ubuntu environment. Please tell me when you are ready and I will sync it into Raring.
[11:16] <mmrazik|lunch> gema_: regarding the pre-seed stuff and lp:1157065 -- there is an utah-related question I can't answer. Can somebody look there?
[11:17] <cjwatson> Yeah, it looks to me as if the preseed file is simply not being applied
[11:18] <cjwatson> You're preseeding some questions successfully, but as far as I can see only because they're listed directly on the kernel command line (which doesn't scale) rather than relying on the preseed file for them
[11:22] <ogra_> oh, i didnt chgeck the cmdline ...
[11:22] <ogra_> *check
[11:27] <xnox> cjwatson: using that preseed and seeding it with url, still the keyboard page, where i had to manually click continue. watching the slideshow now.
[11:27] <xnox> (debian-installer/locale did work before, I'll test that with nexus7 as well, before filing a bug)
[11:31] <gema_> mmrazik|lunch: we'll have a look
[11:43] <cjwatson> xnox: the keyboard is being preseeded on the kernel command line, not in the preseed file
[11:43] <cjwatson> (in this case)
[11:46] <xnox> cjwatson: is it one of those that must be presseded before ubiquity (e.g. on the command line) anyone, i'd think many people would notice quickly if keyboard was getting people stuck.
[11:46] <xnox> s/anyone/anyway/
[11:51] <mdeslaur> @pilot in
[11:52] <cjwatson> xnox: the command line vs. preseed file distinction is only relevant to d-i, not to ubiquity
[11:53] <xnox> ok.
[11:53] <cjwatson> xnox: with ubiquity, *everything* is preseeded before ubiquity anyway, because ubiquity doesn't process preseed files - that's casper's job
[11:58] <mpt> Any geolocation experts in the house? I'm trying to write a caption to explain the effect of turning off GPS on Ubuntu Phone
[11:58] <xnox> mpt: considering we yet to have GPS capable framework in the OS, currently turning gps on/off makes no difference =)
[11:59] <ogra_> but you can talk about it in the UI :)
[11:59] <seb128> mpt, you can maybe try #ubuntu-touch if nobody on -devel has an opinion
[11:59] <ogra_> yeah
[11:59] <mpt> As I understand it, geolocation with GPS + Wi-Fi is excellent, GPS only is pretty good, Wi-Fi only is patchy, and with neither is down to the country level. Is that right?
[11:59] <ogra_> #ubuntu-touch would likely be better
[12:00] <seb128> xnox, speaking about geoclue, is this bug about hongkong not being in the ubuntu geoname db still on your list? we got a similar one that singapore is missing as well
[12:00] <xnox> mpt: there is also 3G network signal tower location based detection, if one is provided by your operator. That is usually "bundled" into GPS chip though.
[12:01] <xnox> seb128: yes, I was pondering about it. We used to have a bug of having too many duplicates, now I'm thinking we remove way too many. I'll add some unit tests.
[12:01] <seb128> ok
[12:03] <cjwatson> I don't think it's necessarily true that "with neither [it's] down to the country level" - it depends on the quality of the geoip database in use
[12:05] <xnox> mpt: yeah, with virgin media cable broadband it's down to roughly first part of the post-code at times.
[12:05] <xnox> for example.
[12:05]  * cjwatson tries to remember how to get geoname-lookup.ubuntu.com to actually give him an answer
[12:06] <xnox> cjwatson: http://geoname-lookup.ubuntu.com/?query=Kong
[12:06] <cjwatson> xnox: no, I mean for my IP
[12:06] <cjwatson> But anyway with the maxmind database installed there it's often at at least city level.  I suspect quality varies
[12:07] <cjwatson> Ah, what I actually meant was http://geoip.ubuntu.com/lookup
[12:08] <cjwatson> That claims I'm in London, so it's obviously not all the way there yet ...
[12:08] <cjwatson> Pretty sure I've seen it do better
[12:08] <mlankhorst> well there should probably at least be some validation the country is correct..
[12:12] <mpt> thanks xnox, cjwatson
[12:14] <xnox> mpt: http://geoip.ubuntu.com/lookup for me is just two digits away on the first part of the zipcode.
[12:15] <mpt> Thinks I'm in Bexley
[12:19] <cjwatson> zipcode?  American :P
[12:20] <ogra_> my zipcode is backwards ...
[12:20] <ogra_> (05 instead of 50)
[12:21] <ogra_> ah, wait, no, its the region code
[12:21] <ogra_> it doesnt actually show a zip code
[12:23] <cjwatson> Putting "ZipPostalCode" in the DTD for an allegedly geographically-agnostic service was a pretty bad design :)
[12:24] <cjwatson> (ZIP -> Zone Improvement Plan, a term used specifically by the US Postal Service)
[12:24] <ogra_> but at least it has improvement in the name :)
[12:35] <seb128> gema_, did you found anyone to answer the utah question in that bug? (would be good to see that fixed, it's blocking unity changes to land for some days)
[12:50] <gema_> seb128: I am waiting for nuclearbob to go online to ask him
[12:51] <nuclearbob> gema: ask me wt?
[12:51] <seb128> gema_, hum, k
[12:51] <gema_> nuclearbob: can you read the history on this channel
[12:51] <cjwatson> nuclearbob: question from me in bug 1157065, specifically
[12:51] <nuclearbob> gema: looks like seb128 was asking about a bug, do either of you have the bug number?
[12:52] <nuclearbob> cjwatson, thanks
[12:53] <nuclearbob> cjwatson seb128: do you want me to answer in the channel or respond to the bug?
[12:53] <cjwatson> bug, I guess
[12:53] <nuclearbob> thanks, doign that now
[12:53] <seb128> whatever works for cjwatson
[12:53] <seb128> thanks
[12:58] <gema_> nuclearbob: any chance we've changed something that may have broken the preseeding code?
[12:58] <nuclearbob> gema: we haven't updated the code on magners-orchestra yet, and the problem occurred before I even branched the testing code there
[12:58] <cjwatson> I followed up again.  I wonder if the new busybox might be implicated
[12:59] <cjwatson> Has this been broken perhaps for about four or five days?
[13:00] <seb128> cjwatson, we noticed yesterday the issues for the first time, but nobody is watching during the w.e
[13:00] <gema_> nuclearbob: ack
[13:08] <cjwatson> I'm grabbing a current image to see if I can tell whether casper-set-selections is just generally broken
[13:13] <zyga> utlemming: ping
[13:23] <zyga> mpt: do you think that clicking on the trash / rubbish bin icon should "focus" that icon in the launcher?
[13:23] <zyga> mpt: right now it opens nautilus which to me, feels wrong/confusing
[13:24] <cjwatson> casper-set-selections doesn't seem obviously broken
[13:24] <seb128> zyga, what do you mean "focus the icon"?
[13:25] <seb128> zyga, which is opening the "rubbish bin" location wrong when clicking on the corresponding icon?
[13:25] <zyga> seb128: show the triangle on the left side
[13:25] <zyga> seb128: start with an empty desktop
[13:25] <zyga> seb128: click on the trash can
[13:26] <zyga> seb128: you get nautilus, which is one of the fist few icons (counting from top)
[13:26] <zyga> seb128: I would have expected the tash window to be "active/focused" (correct me on the right term) and the nautilus icon remained as is
[13:26] <cjwatson> nuclearbob: another information request in that bug
[13:27] <zyga> cr3: hey! :)
[13:27] <seb128> zyga, known issue, same with device icons (usb sticks, cds, ...)
[13:27] <zyga> seb128: ah, thanks
[13:27] <seb128> zyga, it comes down to the fact that all those are nautilus views and the matching is not smart enough to make the difference
[13:27] <zyga> seb128: I just realized it and wondered if there should be a bug on that or not
[13:28] <seb128> trevinho from the unity team has been working on improving that
[13:28] <zyga> seb128: yeah, I realize that it's probably that :) I was thinking about the design aka how-it-should-work
[13:28] <seb128> like with the current version it will open locations only one
[13:28] <nuclearbob> cjwatson: I'll try to recreate that with that option on.  I'm seeing the same error on debian-installer based images as well, if that makes a difference
[13:28] <seb128> where it used to open new views every time you clicked
[13:28] <cjwatson> nuclearbob: Possibly.  What would help is a way to reproduce this outside of utah
[13:29] <cjwatson> Or at least locally without a big lab setup
[13:30] <nuclearbob> cjwatson: so far I can't even consistenly recreate it in utah, but I'm working on both.  as I've looked at it, we do set DEBCONF_DEBUG=developer on all server installs, but not desktop.  I'm trying to run with that on desktop now
[13:30] <cjwatson> Commonality with d-i would not conflict with the hypothesis that it's a busybox regression, but that's still a wild guess hypothesis
[13:30] <nuclearbob> okay
[13:31] <nuclearbob> I haven't had any luck recreating it on a vm so far, unfortunately, I'm still working on that
[13:31] <OdyX> tkamppeter: lol; no ipp14 is shipped in cups 1.6.1, at all.
[13:31] <OdyX> spotted that with unrelated lintian warnings
[13:32] <cr3> zyga: hi there, any updates on adopting subunit?
[13:33] <zyga> cr3: no, we're deep in SRU stuff, trying to get stuff to work enough to switch SRU process to plainbox
[13:34] <zyga> cr3: I was talking about the way we submit data to certification website but we don't expect any changes in that area until after we get all of plainbox + gui done
[13:34] <cjwatson> nuclearbob: FWIW d-i is usually easier for me to debug
[13:35] <cjwatson> nuclearbob: so if you can reproduce it there, especially if any more reliably, then we should start with that
[13:35] <nuclearbob> cjwatson: I can get it to show up more easily on d-i, I just don't know how to get the logs out then.  If you have access to the lab vpn, I can get you a system where it's failing
[13:35] <nuclearbob> cjwatson: I'm still trying to setup a recreate outside of the lab as well
[13:35] <cjwatson> nuclearbob: boot with serial console and the logs should come out there?
[13:36] <cjwatson> nuclearbob: can you link me to the directions for setting up the lab VPN so I can compare them against what bits of network I have?
[13:36] <cjwatson> I use VPNs so rarely that I honestly can't remember
[13:37] <cr3> zyga: when do you think plainbox will finally replace checkbox?
[13:37] <nuclearbob> cjwatson: we don't have anything attached to the serial port on most of these machines, but there's one I can try
[13:37] <nuclearbob> cjwatson: I'll see if I can find the lab vpn info
[13:38] <zyga> cr3: never, checkbox will stay as a project name and something people use, it will just use plainbox for everything not specific to checkbox itself
[13:38] <zyga> cr3: as for when it will be rolled out in any form
[13:39] <zyga> cr3: the SRU process is still using checkbox but we're doing a test SRU on one machine with plainbox, so far it does nothing but we're plugging the pieces, we basically have everything needed, it's just not plugged into that command
[13:39] <zyga> cr3: once that works and we iron out any bugs we'll look at what's the next step
[13:39] <cr3> zyga: very exciting!
[13:39] <zyga> cr3: probably GUI and then full replacement
[13:39] <zyga> cr3: I wrote a proposal for new job description format that hopefully plugs one issue with current jobs, would you like to have a look at that?
[13:40] <zyga> cr3: http://jobbox.readthedocs.org/en/latest/jobspec.html#jobbox-job-definition the interesting parts that matter are around parse-job-pattern
[13:40] <zyga> cr3: the rest is not essential, just 'cleanup'
[13:41] <zyga> http://jobbox.readthedocs.org/en/latest/jobspec.html#parse-job-pattern this is a better link
[13:41] <zyga> cr3: the idea is to be able to discover dependencies across local jobs
[13:42] <zyga> cr3: by creating 'maybe' jobs that _might_ be generated by a particular local job
[13:43] <zyga> cr3: so I could run for example "bandwith_test_wlan0" (hypothetical example) and have plainbox discover the dependencies to discover and run that job
[13:43] <cr3> zyga: I don't have enough brain to allocate to understand what parse-job-pattern does, I'm starting to swap
[13:43] <zyga> cr3: hehe, sorry to try to drag you into this parse-job-pattern is just a way to tell plainbox that a particular local job can only generate jobs that match some specified pattern
[13:44] <zyga> cr3: so that "bandwith_test_wlan0" job would come from "bandwith_tests" local job (all examples so far) that has parse-job-pattern equal to "bandwith_test_{interface}"
[13:45] <zyga> cr3: so any job that is not know to the core, that matches any of the local job patterns can be traced via that possible route to a local job, where we can already discover dependencies needed to run it
[13:52] <cr3> zyga: oh, that's nice indeed. thanks for the explanation!
[14:13] <mpt> zyga, I think that as long as the Launcher includes either the Trash or Web apps, and especially if it shows both,  it shouldn't try to highlight the focused app at all.
[14:14] <mpt> (And double-especially if it ever gets the ability to hold other folders and bookmarks.)
[14:14] <zyga> mpt: I wasn't clear, it's not just focus
[14:15] <zyga> mpt: it's the triangle that shows the app is running (correct me on how that is called)
[14:15] <zyga> mpt: unlike webapps, the trash is never 'active' in that sense
[14:15] <zyga> mpt: having both the trash and nautilus having triangle as with webapps would be a good consistent compromise probably
[14:15] <zyga> mpt: (actually focus is entirely not related to that, I just used the wrong term earlier)
[14:18] <mpt> zyga, I don't care about that. It was included as an issue in past Unity usability tests -- difficulty in telling which applications were running -- and I thought, "why is that even a problem?"
[14:18] <zyga> mpt: I'm not sure what that means, I'm trying to figure out if that's a problem according to you and if so, should there be a bug about that
[14:20] <zyga> mpt: if you mean that the function of the triangle is not relevant and that it will go away entirely then that's probably fine
[14:23] <mpt> zyga, I think you're confusing me with someone involved in the design of Unity. :-)
[14:23] <zyga> mpt: re-reading your first statement it makes the launcher act as a bar with buttons that each "do something to show the application", in that context it is accurate and especially with more mobile-like application lifecycle it's wrong to try to show the state of any application as we're building an ilusion that apps always work
[14:24] <zyga> mpt: sorry, you seem like a go-to person for questions regarding design issues, if you know who should I be talking to instead please redirect me
[14:25] <mpt> zyga, try #ubuntu-design perhaps
[14:25] <zyga> thanks
[14:25] <xnox> zyga: or #ubuntu-touch and #ubuntu-unity
[14:26] <zyga> I'll try -desing and -unity
[14:26] <ogra_> nuclearbob, does your casper script actually do more than just copying the preseed to / ? (might probably make sense to attch it too)
[14:26] <ogra_> *attach
[14:26] <nuclearbob> ogra_ yeah, it copies some other files we use in the success_command.  I'll attach it to the bug
[14:26] <ogra_> nuclearbob, but it doesnt have any code to apply the preseed ?
[14:27] <cjwatson> Not necessary anyway
[14:27] <cjwatson> casper applies it itself
[14:27] <cjwatson> As long as it's called /preseed.cfg in the initramfs, which AFAICS it is
[14:27] <ogra_> i'm not sure there is anything doing that by default
[14:27] <ogra_> ah k
[14:28] <nuclearbob> cjwatson and ogra_: during my testing, having it in the initramfs wasn't enough, I had to get it into the live fs for it to work.  I may have been doing something else wrong, but at this point, we copy it from the initramfs to the livefs with a casper-bottom script I'm about to uploda to the bug
[14:28] <cjwatson> I wish you'd reported that ...
[14:28] <cjwatson> Because it is meant to work
[14:28] <nuclearbob> sorry about that, at the time I was mostly assuming that all the process problems were my fault
[14:29] <nuclearbob> we also copy an rsyslog configuration file in that script, I'll upload it as well
[14:30] <cjwatson> In fact I'm really not sure whether copying the preseed achieves anything at all, although it's perhaps useful documentation
[15:01] <slangasek> pitti: retargeted> sounds good, thanks
[15:08] <tkamppeter> OdyX, you need to conserve the ipp14 patch. I have added ipp14 as Mike is refusing to fix certain regressions which came in with CUPS 1.5.x as he made the ipp backend more IPP-conforming. For the few people with these problems I have made avaialable the ipp backend of the old CUPS 1.4.x as ipp14.
[15:14] <mitya57> fginther: is there any reason why you didn't propose a merge for your branch lp:~fginther/+junk/python-coverage-fix-1109090 ?
[15:14] <mitya57> I've just run into the same issue
[15:22] <mitya57> fginther: nevermind, this is an issue in Debian patch so should be fixed there, not by adding a new patch. I'll now do this.
[15:22] <fginther> mitya57, sorry.  I was refresshing my memory
[15:23] <mitya57> will have a MP in 5 minutes
[15:23] <fginther> mitya57, yes, that sounds right. I realized it wasn't the right fix and never got around to doing it correctly
[15:23] <fginther> mitya57, I'll review
[15:29] <mitya57> fginther: https://code.launchpad.net/~mitya57/ubuntu/raring/python-coverage/lp1109090/+merge/154123
[15:29] <OdyX> tkamppeter_: build in progress, will push to Debian experimental 'soon'
[15:32] <fginther> mitya57, approved
[15:32] <mitya57> fginther: thanks!
[15:33] <mpt> katie, bug 1084979
[15:34] <slangasek> jodh`: daily upstart build failure on armhf that I don't understand: https://launchpad.net/~canonical-foundations/+archive/upstart-daily/+build/4381411
[15:34] <slangasek> jodh`: has this been ongoing, or is it new?
[15:34] <jodh`> slangasek: I think this might be the issue xnox has seen?
[15:35] <slangasek> jodh`: I don't know :)
[15:35] <jodh`> slangasek: I'll see if I can recreate...
[15:36] <xnox> jodh`: yes, that's what i have been seeing.
[15:37] <xnox> slangasek: we exhaust inotify watches in some parts of the test-suite, but if system makes one watch free, then the part of the tesuite that is running in "no inotify available" can fail as suddently inotify became available and e.g. jobs got automatically reloaded instead of manual reloading.
[15:38] <xnox> jodh`: make -C init -j4 check : is the quickest way to reproduce. Assuming you have multiple core machine.
[15:39] <OdyX> tkamppeter_: cups 1.6.2-1 uploaded to Debian experimental
[15:39] <slangasek> xnox: ugh, we're *exhausting* inotify?  This sounds like it could be a problem at runtime too, especially with user sessions
[15:41] <mdeslaur> @pilot out
[15:41] <xnox> slangasek: on purpose hitting the limit, to see what happens when there are no inotify watches left.
[15:42] <slangasek> ah, well then
[15:42] <xnox> otherwise it is quite large per user, and unlimited system wide.
[15:43] <xnox> slangasek: well the limit is max # of open file descriptors per process.
[15:45] <jodh`> xnox: well, the magic number happens to correspond to the same value on the buildds; we should really query that rlimit :)
[15:59] <jono> didrocks, hey, I noticed that most of these scopes in the PPA don't seem to display in the dash results
[15:59] <jono> is that normal?
[16:00] <didrocks> jono: the server is sending fake scope recommendations
[16:00] <didrocks> jono: so it's always starting the same
[16:00] <didrocks> the ETA to get it fixed is in 2 days IIRC
[16:01] <jono> didrocks, ahhh cool
[16:01] <jono> didrocks, it seems there is also an issue with queries happening after every keystroke
[16:02] <didrocks> jono: please opens bugs and tag them 100scopes
[16:02] <didrocks> jono: https://bugs.launchpad.net/unity/+bugs?field.tag=100scopes
[16:03] <jono> didrocks, will do now
[16:03] <didrocks> thanks :)
[16:06] <jono> didrocks, https://bugs.launchpad.net/unity/+bug/1157263
[16:09] <didrocks> jono: thanks!
[16:56] <tkamppeter> OdyX, thanks for updating CUPS on Debian, I am now waiting for Debian's build servers so that I can sync the new package.
[17:02] <ogra_> tkamppeter, oh since i saw you asking on the ML ... http://www.heise.de/open/artikel/Dells-Ubuntu-Ultrabook-im-Test-1823594.html there is a dell XPS review
[17:02] <tkamppeter> ogra_, thanks, will look ...
[17:04] <awe_> seb128, ping
[17:04] <seb128> awe_, hey
[17:04] <awe_> looking at the bt indicator I just reviewed https://bugs.launchpad.net/ubuntu/+source/indicator-bluetooth/+bug/1123115
[17:05] <awe_> and https://bugs.launchpad.net/ubuntu/+source/indicator-bluetooth/+bug/1116292
[17:05] <cjwatson> tkamppeter: FWIW you don't need to wait for Debian buildds to sync a package, only for the source package to be published in the archive and (shortly afterwards) noticed by the cron job in Launchpad that imports it into launchpad.net/debian/+source/<package name>
[17:05] <awe_> doesn't "Breaks/Replaces" cause gnome-bluetooth to not be installed?
[17:06] <awe_> and if so, doesn't that break support for "Setup New Device"?
[17:06] <seb128> awe_, no, it does "Breaks: gnome-bluetooth (<< 3.6.1-0ubuntu2)" which force a newer version to be installed
[17:06] <seb128> awe_, newer version = one without our indicator patch
[17:07] <awe_> ah OK
[17:07] <awe_> sorry I misunderstood
[17:07] <seb128> no worry ;-)
[17:07] <seb128> we still use gnome-bluetooth
[17:07] <seb128> that's what has the wizard ui
[17:07] <awe_> I missed the << part
[17:08] <awe_> looks like indicator-bluetooth is missing "sendto" though
[17:08] <seb128> awe_, you mean?
[17:08] <seb128> I've a "send files" entry in the submenu for my phone
[17:09] <awe_> wow, I'm batting 0 for 2
[17:10] <awe_> I really haven't worked with vala all that much, and it looks like "sendto" and "wizard" are handled differently
[17:10] <seb128> what do you call "sendto"? sending files to a device ?
[17:11] <seb128> and yes, it's possible things are different
[17:11] <seb128> I think robert_ancell tried to follow mpt's spec
[17:11] <awe_> correct
[17:11] <seb128> where the previous one was maybe not 100% conform to the spec
[17:11] <awe_> the wizard is launched via Process.spawn_command_line_async()
[17:12] <awe_> whereas as send_to is invoked via GnomeBluetooth.send_to_address()
[17:12] <seb128> is that an issue?
[17:12] <awe_> that's what threw me
[17:12] <awe_> I was just trying to confirm that these were both supported
[17:12] <awe_> also, they may need to be re-implemented for touch
[17:12] <BenC> cjwatson: where do I update the initrd on the server ISOs so I can include an IDE driver in it (for QEmu)?
[17:13] <awe_> seb128, just trying to ensure we have all of our work items in line for BT UI
[17:13] <seb128> awe_, yeah, I'm sure tweaks will be needed
[17:13] <seb128> awe_, I doubt we will want to keep the gtk wizard on touch anyway
[17:13] <seb128> so those parts will need to be reimplemented
[17:13] <awe_> right, and same for send-to
[17:13] <awe_> however neither of those are being tracked atm
[17:14] <cjwatson> BenC: those initramfses are built by debian-installer, but the change you probably actually need to make is to add the module to one of the udebs generated by the linux-ppc source package
[17:14] <awe_> maybe I'll add pending TODO items in the BT spec, and we can move them if needed
[17:14] <awe_> s/maybe//
[17:14] <seb128> awe_, yes, please do
[17:14] <awe_> k
[17:14] <awe_> thanks
[17:14] <seb128> awe_, yw, thanks for looking into those details
[17:14] <BenC> cjwatson: I suspect it is, but I need it to be in the initrd else it can't find the cdrom
[17:14] <awe_> seb128, np
[17:15] <seb128> awe_, we probably need to add "port the indicator to the new libindicator api/gmenumodel" as well
[17:15] <seb128> that one was not available so robert_ancell did the work using the current apis
[17:15] <awe_> larsgk, already has that covered
[17:15] <cjwatson> BenC: debian-installer already includes pata-modules in the cdrom initrd for powerpc
[17:15] <seb128> awe_, larsu you mean? ;-)
[17:15] <cjwatson> BenC: so just add it to pata-modules and it'll be picked up at the next debian-installer rebuild (which are frequent)
[17:15] <awe_> oops, yea
[17:15] <seb128> awe_, good
[17:16] <BenC> cjwatson: Ah, ok, thanks
[17:16] <roaksoax> slangasek: howdy!! where you able to review MAAS (maas, maas-provision)?
[17:38] <seb128> gema_, hey again, do you know if that utah issue is likely to be fixed today at this point? still blocking unity...
[17:44] <seb128> hum
[17:44] <seb128> so we didn't have any langpack update this cycle
[17:44] <seb128> is anyone looking at this? I would usually ping dpm but he's on holidays this week
[17:49] <pitti> for the record, we need Launchpad translation exports
[17:50] <seb128> pitti, is that purely launchpad issue? do you know if there is a ticket?
[17:50] <pitti> no, I don't
[17:50] <pitti> TBH I didn't deal with translations much this cycle, except asking dpm for exports a month ago or os
[17:50] <pitti> "so"
[17:52] <seb128> pitti, ok, thanks, trying to ping on the launchpad side (dpm is out, will have to wait next week otherwise)
[17:53] <xnox> seb128: speaking of which, it was in my todo to run the archive export & update app-install-data, let me start that now.
[17:54] <seb128> xnox, thanks, don't forget to fix geonames' db as well :p
[17:54]  * seb128 hides from xnox
[17:55] <slangasek> roaksoax: sorry, I failed at it on Friday - but I'm looking now
[17:55]  * xnox ponders how strange is it to look up instructions on how to do stuff...... in my own sent mail folder.
[18:09] <seb128> gema_, ?
[18:17] <lunitik> I noticed in Raring that gksu is no longer used to authenticate in the GUI, what is used instead?
[18:19] <seb128> pkexec in most places
[18:20] <lunitik> seb128: Makes sense, actually, thank you... and also thanks for all your great work still with Ubuntu/Gnome  :)
[18:21] <seb128> lunitik, yw, thanks for the nice comment ;-)
[18:27] <slangasek> roaksoax: this doesn't look right: +Pre-Depends: ${misc:Pre-Depends}, ${misc:Depends}
[18:27] <slangasek> roaksoax: pretty sure you want ${misc:Depends} in the Depends field
[18:38] <roaksoax> slangasek: ok cool. I'll update that
[18:42] <gema_> seb128: you need to talk to nuclearbob or doanac`
[18:42] <gema_> nuclearbob: ^^
[18:42] <seb128> gema_, k, I though you were tracking the issue/making sure things don't get stalled in your team
[18:42] <seb128> which they seem to be...
[18:43] <gema_> seb128: they are working on it, and they are in US time, I have all the confidence they are doing their best
[18:43] <gema_> seb128: I will have an email tomorrow morning with status whenever I get to work
[18:43] <seb128> gema_, thanks
[18:43] <nuclearbob> gema, seb128, are we still talking about the install issue?
[18:43] <seb128> yes
[18:43] <seb128> that's blocking unity tests for several days
[18:44] <seb128> so it's blocking any update to land as well
[18:44] <nuclearbob> an environment variable in jenkins changed, and we don't know why.  We've configured utah to ignore that environment variable while we figure out why it changed, and our tests are now working
[18:44] <nuclearbob> our attempt to rerun the autopilot tests seemed to work as well
[18:44] <seb128> oh ok, would have been good to update the bug saying that
[18:45] <doanac`> seb128: we just figured this out over lunch
[18:45] <nuclearbob> seb128: sorry abou tthat, good point.  I was hoping to have a more definitive answer than "something went wrong and we don't know why" but I'll post info about the workaround
[18:45] <doanac`> still can't say why jenkins has changed
[18:45] <seb128> things should be in shape enough for unity's tests to be retried on jenkins then?
[18:45] <slangasek> roaksoax: not SRU-critical, since misc:Depends is empty in this case
[18:46] <doanac`> seb128: yes.
[18:46] <seb128> doanac`, thanks, we are giving a retry to unity's stack
[18:46] <roaksoax> slangasek: ack!
[18:47] <doanac`> seb128: we've run this successfully as a test: http://10.97.0.1:8080/view/autopilot/job/ps-unity-autopilot-release-testing/122/
[18:47] <doanac`> nuclearbob: to double-check - we do still have the conf.d fix deployed, correct?
[18:47] <nuclearbob> doanac: correct
[18:47] <seb128> doanac`, ok, great, cyphermox is going to give a retry to http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/
[18:48] <seb128> oh, seems there is one running
[18:48] <seb128> cyphermox, ^
[18:49] <cyphermox> yup, just noticed
[18:54] <nuclearbob> cyphermox seb128: the job was started while we were testing the current deployed workaround, and thus not affected by the workaround.  I'm retrying it now that the workaround is in place
[18:54] <seb128> ok, thanks
[18:55] <slangasek> roaksoax: checking my IRC logs, I see that I wrote: however, looking at the package that's in raring, the /other/ Conflicts (on maas (<= ...) and maas-region-controller (<= ...)) should almost certainly be Breaks rather than Conflicts, since they're paired with Replaces
[18:55] <slangasek> roaksoax: I think this definitely should be fixed for the SRU, maas-region-controller shouldn't Conflicts: the old version of maas
[18:56] <slangasek> roaksoax: even if it doesn't cause any known issues, it's the wrong package relationship to use
[18:57] <roaksoax> slangasek: ok. I'll fix that and re-upload
[18:58] <cjwatson> It will at least cause suboptimal upgrade ordering
[18:58] <cjwatson> Which can turn into total upgrade failure when you least expect it, so indeed best to avoid
[18:58] <slangasek> roaksoax: ok.  The same applies to the Conflicts added on the python-maas-provisioningserver package; anywhere that you use Replaces: $pkg (<= $ver) + Conflicts: $pkg (<= $ver), you should be using Breaks instead of Conflicts
[18:58] <slangasek> and python-maas-client
[18:58] <slangasek> ... etc
[18:58] <cjwatson> You should probably also be using << first-version-with-new-layout rather than <= last-version-with-old-layout
[18:59] <cjwatson> It's friendlier to anyone producing modified versions of your packages
[19:03] <roaksoax> slangasek: yeah i'll update all of those
[19:03] <slangasek> roaksoax: not relevant to the SRU, but "BSD" and "MIT" in debian/copyright are both ambiguous; per http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/, these should be listed as BSD-3-clause and Expat
[19:03] <cjwatson> gema_: I have some fine-details-of-jenkins questions regarding better integration of smoke testing with cdimage, but it's probably a bit complex for IRC; whom would it be best for me to mail?
[19:08] <roaksoax> slangasek: thanks for the review! I'll address all of these and upload a new package.
[19:19] <slangasek> roaksoax: is there an authoritative Vcs branch for the maas package?  It's not listed in debian/control; I see a number of things in the maintainer scripts that I think should be cleaned up but shouldn't block the SRU, so I'd rather raise a MP
[19:21] <roaksoax> slangasek: there's various branches. Raring has its own, quantal has its own, and precise has its own (which is basically quantal + precise specific changes)
[19:21] <slangasek> roaksoax: well, the raring one is where I would start :)
[19:21] <slangasek> roaksoax: where would I find it?
[19:22] <roaksoax> slangasek: lp:~maas-maintainers/maas/packaging, lp:~maas-maintainers/maas/packaging.quantal, lp:~maas-maintainers/maas/packaging.precise.sru
[19:23] <slangasek> roaksoax: ta
[19:50] <roaksoax> slangasek: could you please rebase your MP? There was another branch that needed to land first, which will conflict with debian/changelog
[19:50] <slangasek> roaksoax: you guys don't fix changelog conflicts on the merge side?
[19:50] <slangasek> I can fix it up, sure
[19:52] <roaksoax> slangasek: no i don't think so, since its the bot that actually lands the MP's
[19:52] <slangasek> ah
[19:53] <slangasek> roaksoax: done
[19:53] <roaksoax> slangasek: awesome thanks!!
[19:59] <slangasek> roaksoax: whoops, just spotted a typo in the branc
[19:59] <slangasek> h
[20:00] <roaksoax> slangasek: hehe no worries, it wasn't landed :)
[20:00] <slangasek> roaksoax: fixed and repushed
[20:27] <stgraber> xnox: I just updated https://wiki.ubuntu.com/ImageBasedUpgrades/Mobile to include what I discussed with lool last week. I'll likely be doing a few more edits soon but it at least better covers the current state of things.
[20:46] <ogra_> stgraber, geez, that became a gigantic wikipage over time
[20:47] <stgraber> ogra_: could have been worse, I removed a few paragraphs in the update I did earlier today (and added a bunch more obviously ;))
[20:48] <ogra_> well, it reflects the complexity of the task :)
[21:52] <bdrung_> if raring is support for 9 month, raring will eol before quantal. how to upgrade from quantal once raring is eol? will upgrading directly from quantal to raring+1 supported?
[21:55] <cjwatson> bdrung_: yes, that will be a necessity
[21:55] <cjwatson> (and is a good idea anyway!)
[21:56] <cjwatson> the whole business of not supporting direct upgrades from N+1 to N+3/N+4 while expecting to be able to support direct upgrades from N to N+4 was always total madness
[21:56] <cjwatson> we only did it that way in the beginning because we didn't have anything resembling an upgrade autotest setup and so it was too hard to QA
[21:57] <cjwatson> but times have changed and supporting more flexible combinations will make it *easier* to get LTS-to-LTS upgrades working reliably in a timely fashion
[21:58] <bdrung_> cjwatson: thanks. upgrades beyond LTS are not intended, are they?
[21:58] <ScottK> No.
[21:58] <bdmurray> xnox: is there any progress on bug 915626?
[21:59] <cjwatson> I don't think it's necessary to go that far, and it may not be practical due to Debian tending to drop support for upgrades beyond single Debian releases in at least some cases
[21:59] <cjwatson> (lots of maintainers do keep support for longer, but you only need one complex thing not to be supported and it can become a real tangle)
[22:00] <bdrung_> i am asking because it affects if transitional package can be dropped after a LTS
[22:01] <ScottK> Fortunately you've got a while before you need to worry about that.
[22:01] <seb128> I think having the LTS as "forced upgrade point" makes sense
[22:02] <ScottK> Agreed.
[22:05] <cjwatson> Yep.  I think we have fairly widespread agreement on that.
[22:05] <cjwatson> I don't object to developers keeping upgrade support for longer, of course, but it seems a step too far to demand it
[22:06] <cjwatson> Skip-upgrades in Debian are reportedly not awful if you know what you're doing, but come with roadblocks.
[22:07] <geofft> I skip-upgraded my desktop from Natty to Quantal via apt-get a few months ago. I was slightly surprised it worked.
[22:08] <geofft> But I haven't had any trouble with it.
[22:08] <geofft> So I guess that's a testament to good packaging quality in everything!
[22:09] <seb128> well, the issue is not so much quality than "how long to carry packaging tweaks to support upgrades"
[22:09] <seb128> we usually tend to drop delta after a lts, especially if Debian already dropped it and we carry that in an ubuntu specific way
[22:24] <cjwatson> Yeah, lots of those tweaks make upgrades easier / more automatic but their removal doesn't make it impossible
[22:24] <cjwatson> Hence things like geofft's experience
[22:25] <geofft> I think I had to do a bit of dependency-fighting, but it mostly just worked out.
[22:25] <geofft> I wouldn't recommend it to someone not literate in reading other people's packages, though. :)
[23:22] <robert_ancell> Laney, could you have a look at bug 1157475? Basically the same request as the Shotwell FFE
[23:48] <xnox> bdmurray: nope. I gave up on it, and later slangasek said that bindings potentially generate it unfortunately for us when we didn't ask them to do so. A bit of a rabbit hole.
[23:49] <xnox> stgraber: awesome, I'll go through that tomorrow.
[23:51] <slangasek> xnox: "generate it when we didn't ask them to" - the segfault?
[23:52] <xnox> yes.
[23:52] <slangasek> ok
[23:52] <xnox> slangasek: how would you say that sentence?
[23:52] <slangasek> was not sure under what circumstances we would ask a program to generate a segfault ;)
[23:52] <slangasek> xnox: it's a perfectly good sentence ;)
[23:54] <slangasek> roaksoax: fwiw I'm concerned about maas-region-controller.config; I have no idea what the set_question() function is meant to do, but I'm reasonably certain that the second if [] block does not work as intended
[23:55] <slangasek> roaksoax: $RET is only set by db_get or db_metaget; you're not calling either of those here, so "$RET" != false