[02:23] <vibhav> cjwatson: I had a look at the gnulibc bug you were talking about. Is it true that the program assumes that gets is detected?
[02:24] <vibhav> s/program/source/
[04:42] <darkxst> cjwatson, hey, can you approve my spidermonkey post on ubuntu-devel?
[05:30] <cheshair> Hi! (hope that's not ot) I can't find how to change my ubuntu single sign-on username. Here https://login.ubuntu.com/ I can only change full name, email or pwd.
[05:30] <cheshair> Any tips?
[05:31] <cheshair> I found this post which sounds similar to my scenario: http://askubuntu.com/questions/162435/changing-user-name-on-https-myapps-developer-ubuntu-com-dev
[05:35] <cheshair> Ah! I found the way! It's reported here: https://answers.launchpad.net/launchpad/+faq/53 (quite tricky to find indeed)
[05:36] <sarnold> cheshair: nice :) I just got there..
[05:36] <cheshair> sarnold: thanks for your interest! i appreciate, did you find it quick?
[05:37] <sarnold> cheshair: no, you found it first, it would have taken me several more minutes at the least
[05:37] <sarnold> (i started getting there via /topic #launchpad and seeing the answers url...)
[05:38] <cheshair> sarnold: oh i see, thanks again! :-)
[05:48] <cjwatson> vibhav: gnulib, not gnulibc - and no, not really, the bug was that gnulib was trying to install a wrapper for gets that warned when you tried to use it, but it was doing so using typeof to detect the original libc type of gets and this broke when gets was absent from libc
[05:49] <cjwatson> vibhav: this is fairly complex and you aren't necessarily expected to understand it, which is why I just pointed to a few packages that I knew had been temporarily distro-patched to fix the problem :)
[05:49] <cjwatson> (as in, typeof is moderately obscure to start with and understanding gnulib requires a fairly clear understanding of autoconf and libc)
[05:51] <cjwatson> darkxst: done
[05:53] <vibhav> cjwatson: Ah, I get it now. Well learning something new never does any harm :)
[05:59] <doko> query cjwatson
[05:59] <doko> cjwatson, heh, still awake, or already?
[06:04] <vibhav> doko: btw, I had a look at kasumi. Would it be better to file a MIR or lower the recommends?
[06:05] <vibhav> (It should be noted that kasumi is simple dictionary utility for anthy)
[06:08] <cjwatson> doko: already :-/
[06:09] <vibhav> cjwatson: Actually, I know what typeof does :D
[06:18] <cjwatson> vibhav: I stand corrected, sorry :)
[06:18] <vibhav> :)
[06:23] <vibhav> doko: Could you have a look at https://code.launchpad.net/~vibhavp/ubuntu/raring/anthy/fix-component-mismatch/+merge/150961 ?
[07:08] <pitti> Good morning
[07:21] <cjwatson> bdmurray,ev: phased update support is now live in LP; you can see the column for it in https://launchpad.net/ubuntu/raring/i386/man-db
[07:21] <cjwatson> (e.g.)
[07:22] <cjwatson> I suggest memorising how to get to those binary package publishing history pages, as it's hard to find them by navigation alone
[07:24] <dholbach> good morning
[08:40] <tomreyn> hi
[08:40] <tomreyn> the canonical-partner repository is pretty slow. where's the proper place to report this?
[08:58] <ev> cjwatson: awesome, thanks!
[09:25] <Laney> tomreyn: #canonical-sysadmin i suppose
[09:33] <tomreyn> thanks Laney
[09:34] <Laney> tomreyn: I believe there were flash and/or java updates though, so it's likely to be due to higher than average traffic
[09:35] <tomreyn> is java in there, too?
[09:35] <tomreyn> there surely were flash updates, which is why i noticed
[09:35] <tomreyn> but that's like 5 or 6 MB
[09:37] <Laney> sorry, not java
[09:37] <Laney> but 5/6 * <lots of users> is surely a lot
[09:47] <tomreyn> maybe 2 mirrors are not enough then
[10:07] <xnox> doko: boost1.53 is being prepared in svn but it apperantly has some packaging restructuring in progress and hence is not uploaded yet.
[10:08] <xnox> i guess you'd want me to drive that to an upload ;-)
[10:08] <doko> well, if 1.53 will be the next debian default, yes, that would be good
[10:39] <doko> seb128, does gnome-calculator need a MIR?
[10:39] <seb128> doko, no, it's a rename of gcalctool
[10:51] <seb128> ev, hey, is filtering on a source/binary known to be broken (e.u.c)?
[10:52] <seb128> ev, I'm trying to see telepathy-gabble bugs but it seems to never finish "Loading..."
[10:53] <ev> seb128: think I've spotted the bug. Fixing.
[10:54] <seb128> ev, thanks
[11:06] <Guest89798> http://www.ubuntu.com/testing is very outdated
[12:11] <czajkowski> aloha
[12:15] <doko> diwic, which alsa-tools version is this?
[12:16] <diwic> doko, hmm, 1.0.25-2ubuntu1
[12:18] <diwic> doko, I tried packaging 1.0.26.1, that's when I discovered it and found it present in current version as well
[12:22] <czajkowski> Laney: anyone else I should poke re my partial upgrade ?
[12:22] <czajkowski> http://pastebin.ubuntu.com/5573162/
[12:22] <Laney> I'm not sure what the intended behaviour is
[12:23] <Laney> jbicha: is the Breaks strictly necessary?
[12:28] <jbicha> Laney: we can't run two different cogl libraries at the same time so we don't want the old library to be present at all...
[12:29] <Laney> doesn't britney ensure this?
[12:29] <jbicha> I basically copied what Debian did the last time we had to do the cogl transition
[12:34] <jbicha> so I believe Debian needs the breaks, I have no idea whether Ubuntu upgrades can work without it
[12:34] <Laney> I can see how it would be a problem if you're running unstable (or raring-proposed)
[12:35] <Laney> i.e. if the transition is in progress
[12:38] <xnox> Laney: http://paste.ubuntu.com/5573220/
[12:38] <Laney> haha, classy
[12:39] <Laney> why keep them?
[12:39] <xnox> Laney: such that they match the attic/ folder in the branch.
[12:39] <xnox> why are those kept?
[12:39] <Laney> because they might be useful in the future
[12:39] <Laney> for the next transition of that library, for example
[12:40] <Laney> or as examples for some future transition
[12:40] <xnox> same. if transition finished 3 days ago, but I am confused why something is borked, one can look at it.
[12:40] <Laney> can't say i've done that
[12:40] <Laney> but whatevs
[12:40] <xnox> =)
[12:40] <seb128_> Laney, what's the issue exactly there? (sorry I disconnected), is the partial upgrade because the old soname needs to be removed?
[12:40] <mlankhorst> tkamppeter_: mind if I close https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1029865 as WONTFIX since from your description it seems to be a hardware issue?
[12:40] <Laney> seb128: right, because there's a Breaks from clutter-something to libcogl<oldsoname>
[12:40] <xnox> czajkowski: we shouldn't have partial upgrades in raring =(
[12:41] <Laney> feels like u-m should allow this, but I don't know how to capture the situation
[12:41] <Laney> and I do think we could remove the Breaks but there wouldn't be anything to stop things like this coming from Debian
[12:43] <czajkowski> xnox: hence me joining here to find out whuy :)
[12:44] <xnox> thanks ;-)
[12:45] <xnox> Laney: you can -delete them, I'm not fussed.
[12:46] <Laney> xnox: I think that should be done in the 'go' script
[12:46] <Laney> to remove them before they're rsynced to public
[12:47]  * Laney JFDI
[12:48] <mpt> ev, foreach uuid, {foreach percentage bucket, {calculate the absolute value of the difference, if you put the uuid in that bucket, between its resulting percentage and its target percentage}; total those absolute values; put the uuid in the bucket that results in the lowest total, using the earliest if there's a tie}.
[12:49] <Laney> xnox: OK it's in place
[12:49] <Laney> we can expose the attic later if it's wanted
[12:50] <Laney> jbicha: I'll upload to remove the Breaks now and we can decide whether u-m should be able to handle this situation at our leisure later
[12:53] <mpt> ev, a simpler version that would probably work just as well: foreach uuid, {foreach percentage bucket, {calculate the absolute value of the difference, if you put the uuid in that bucket, between its resulting percentage and its target percentage}; put the uuid in the bucket that has the lowest absolute difference, using the earliest if there's a tie}.
[13:01] <Laney> czajkowski: jbicha: OK, uploaded - please see if the partial upgrade goes away when that's rolled out in a couple of hours
[13:01] <Laney> seb128: ↑ fyi
[13:03] <mpt> Laney, perhaps "Breaks" in update-manager is (or would best be) covered by bug 1038113?
[13:03] <seb128> Laney, how did you fix it?
[13:03] <Laney> I just dropped the breaks
[13:03] <Laney> I don't think we need it
[13:03] <seb128> Laney, it seems like that breaking on an old package that needs to be removed should be a normal/supported upgrade case
[13:03] <mpt> oh, maybe not, that's fixed in Raring already apparently
[13:03] <Laney> mpt: that was fixed and seems to me to be about a rather more specific case (complete replacement as expressed by the Provides)
[13:03] <Laney> seb128: It was intended to stop users doing partial upgrades in the middle of the transition
[13:04] <seb128> Laney, right, but it seems like at the end of the transition it should be ok
[13:04] <seb128> not sure why we need to drop it
[13:04] <seb128> shouldn't update-manager just do the right thing
[13:04] <Laney> because u-m refuses to remove packages like that
[13:04] <seb128> e.g remove the old package
[13:05] <seb128> which means we pile old cruft...
[13:05] <Laney> I don't know if it has any autoremoval support
[13:05] <seb128> ok
[13:05] <seb128> Laney, anyway, thanks for fixing it
[13:05] <seb128> it seems like it's going to bite us again in the futur though
[13:05] <Laney> and I do think it behaves a bit differently wrt removals when doing a release upgrade (there must be other packages being forced out in that case, surely)
[13:05] <seb128> sometimes we do require removal from the old soname because there is a file conflict or something
[13:07] <Laney> yeah
[13:07] <Laney> and sometimes we'll just plain want to get rid of packages for some reason
[13:07] <Laney> mpt: do you know how update-manager handles this?
[13:08] <Laney> i.e. what is the specification that determines when you get a partial upgrade?
[13:14] <Laney> perhaps it's just unreasonable; after all, you do sometimes use dist-upgrade instead of upgrade (apt-get upgrade also didn't handle this case)
[13:17] <seb128> Laney, fwded you a recent email which is discussing killing the partial upgrade button
[13:17] <Laney> cool, ty
[13:17] <seb128> yw
[13:29] <ev> the background is for each uuid representing a core file coming in, we need to assign it to a specific bucket such that the total number of uuids processed into a bucket over time matches the percentage assigned to that bucket
[13:30] <ev> oh, the first part of what I wrote didn't send
[13:30] <ev> [13:27:11] <ev>	 mpt: we don't know the set of uuids ahead of time. The solution I've come up with is to drop the deterministic requirement and just use random.randint(1,100) which each bucket mapping to a portion of that range
[13:30] <ev> [13:27:42] <ev>	 we then pass the bucket information along with the uuid so that it doesn't need to be run again using the uuid as input, thus dropping the deterministic requirement
[13:31] <Laney> xnox: http://people.canonical.com/~ubuntu-archive/transitions/ much cleaner now :-)
[13:31] <xnox> Laney: all media files are gone, no css /js
[13:32] <Laney> oh yeah :P
[13:32] <Laney> already putting that back
[13:32] <Laney> *too* clean ;)
[13:32] <mpt> ev, you don't need to know the set of uuids ahead of time.
[13:32] <xnox> Laney: is it croned to wipe media files? =)
[13:33] <Laney> blame xnox
[13:34] <xnox> Laney: i had a careful -max-depth 1
[13:34] <Laney> symlink
[13:34] <Laney> adding a -type f
[13:34] <xnox> *sigh*
[13:35] <mpt> Laney, not really. If it turns out to require UI, please assign a bug to me, and I'll extend either <https://wiki.ubuntu.com/SoftwareUpdates#uninstallable> or <https://wiki.ubuntu.com/SoftwarePackageOperations> to cover it.
[13:35] <Laney> xnox: that's better, yes?
[13:36] <Laney> hopefully it will all work after a cron run
[13:37] <ev> mpt: oh, but it requires knowing how many uuids are in each bucket?
[13:37] <Laney> mpt: I would think that, if anything, we'll extend update-manager to understand that some types of removals are OK when upgrading (so no new UI)
[13:38] <Laney> automatically installed libraries only, no other relationships broken or something like that
[13:38] <mpt> ev, how many you've put in each bucket so far, sure.
[13:38] <mpt> Laney, sounds good.
[13:38] <ev> mpt: yeah, that's not ideal. Requires persistent storage for those totals.
[13:39] <ev> I'd much rather use something that gets close to accurate but doesn't require knowledge of any step before
[13:43] <mpt> ev: Forgetful, deterministic, and accurate, pick two. You can demonstrate this with the simplest useful example: two buckets which you want 50% full each. A forgetful and deterministic algorithm would incorrectly either put every uuid into the first bucket, or every uuid into the second.
[13:47] <ev> mpt: forgetful and accurate
[13:48] <mpt> So, use random numbers :-)
[13:48] <ev> mpt: "The solution I've come up with is to drop the deterministic requirement and just use random.randint(1,100) which each bucket mapping to a portion of that range" :)
[13:48] <mpt> yep
[13:49] <ev> but you're absolutely right about first defining the constraints, and thanks for the pointers
[13:55] <sladen> ev: mpt: whenever I see you both discussing topics on here it is incredibly reassuring
[13:56] <sladen> mpt: ev: continuing kudos to you
[13:56] <mpt> sladen, not as reassuring as it might appear, because we aren't sitting next to each other at the moment. I haven't seen ev in days. :-)
[13:56] <ev> sladen: thanks :)
[13:56] <ev> mpt: yeah, I really must get back into the office
[13:56] <ev> but this whole working until midnight thing is addictive
[13:59] <sladen> miaow!  though it's a fair point, I didn't find Bluefin to be as inspiring an office as Millbank and I can see reasons for avoiding it ;-)
[14:00] <ev> it at least has better coffee than I (suddenly) do at home
[14:01] <ev> I think my transition to the UK can be considered complete when I now prefer Monmouth to Dunkin Donuts
[14:02] <seb128> pitti, can you mark https://code.launchpad.net/~johnv/ubuntu/precise/libappindicator/bug-1122596/+merge/148027 as merged?
[14:02] <pitti> seb128: done
[14:02] <seb128> pitti, danke
[14:02] <brendand> can debian/rules work from a different directory than root?
[14:03] <brendand> i'm trying to get around a limitation of launchpad recipes
[14:04] <seb128> pitti, I noticed that your reviewed the l-s MR, did you look at https://launchpadlibrarian.net/132004936/accountsservice_lp-1130690.diff as well and didn't like or were you just letting that for someone else
[14:04] <pitti> seb128: I didn't get to that one
[14:04] <seb128> pitti, I don't like that stack of scripts but at this point that small addition is not going to make a difference
[14:04] <pitti> seb128: yeah, same here; it has become a terrible mess
[14:05] <seb128> pitti, ok, I'm going to upload it then, I just wanted to check with you first to not step on your toes
[14:05] <seb128> pitti, danke ;-)
[14:05] <pitti> merci
[14:08] <mpt> jodh, do I understand correctly that the Upstart user session will replace update-notifier completely? Or would it just be launching update-notifier periodically?
[14:08] <mpt> Oh, I should have read the work items: "[seb128] replace update-notifier with upstart jobs: BLOCKED"
[14:08] <seb128> mpt, define "update-notifier" :p
[14:09] <mpt> seb128, the bane of ev's existence
[14:09] <brendand> pitti - any idea ^?
[14:09] <seb128> mpt, https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-reduced-power-ram has
[14:09] <seb128>  [brian-murray] change update-notifier to be running on demand, from an upstart job, does the action it has been called for and exit: BLOCKED
[14:09] <mpt> seb128, because it includes various bits of Apport too
[14:10] <seb128> mpt, right, update-notifier evolved to be collection of different things over time
[14:10] <mpt> And, unimportantly, but my focus right this minute, the cause of bug 399591
[14:10] <seb128> mpt, we plan to separate those in "logical units"
[14:11] <doko> xnox, I don't intend to drop guile-1.8, just demote it
[14:11] <mpt> seb128, would the update part of it just be merged with update-manager, or would it stay separate?
[14:13] <seb128> mpt, that's a good question, update-manager doesn't have a nonUI part atm afaik, but we could teach it to do "silent" updates and only display the ui if there are updates then
[14:13] <jodh> mpt/seb128: I thought that the upstart-time-bridge would mean update-notifier would not need to run constantly, but we probably won't have that bridge in the first iteration.
[14:14] <seb128> mpt, no concrete plan atm though
[14:14] <seb128> jodh, right
[14:17] <mlankhorst> hm seems I was still on a rc1 kernel :P
[14:17] <ev> mpt, seb128: :D
[14:22] <ev> seb128: RT 59730 should fix that problem
[14:24] <zyga> dusty42: hi
[14:24] <seb128> ev, thanks a lot for the quick fix!
[14:25] <zyga> dusty42: let's talk here about the problem
[14:25] <ev> seb128: sorry it took as long as it did - got pulled aside for other things
[14:25] <ev> trying to get webops on it now
[14:25] <zyga> (for context if anyone wants to help) - dusty42 is looking at a situation where a user is ssh-ing from macosx and inherits some of the environment from osx, that in turn causes issues with setlocale()
[14:26] <zyga> we're not sure if what osx is doing is correct
[14:26] <dusty42> OS X is doing it the wrong way for sure
[14:26] <zyga> just that it causes actual problems that gives the impression that "ubuntu is broken
[14:26] <zyga> dusty42: so you said that LC_CTYPE from osx is set to "UTF-8"
[14:26] <dusty42> OS sets environment variable LC_CTYPE=UTF-8
[14:27] <dusty42> when you ssh to remote host, ssh client sets LC_CTYPE=UTF-8 on remote system as well
[14:27] <zyga> I mentioned that we can either fix this in one specific case (in the app that is affected now)
[14:27] <zyga> or look at fixing it somewhere globally in ubuntu
[14:27] <xnox> doko: why not? fedora supposedly has everything on 2.0
[14:28] <zyga> if that's possible to fix reliably
[14:28] <zyga> dusty42: for now I'd see if we can work around it at the app level but as I said earlier it'd be good to bring this topic up in the ubuntu-devel mailing list
[14:28] <zyga> as it probably affects everything
[14:29] <zyga> and mac developers sshing to ubuntu servers would get the bad impression that things don't work in certain cases
[14:29] <zyga> dusty42: what does putty/windows does if you have a means to check that?
[14:31] <dusty42> This snippet demonstrates how locale module in Python behaves on different LC_CTYPE env variables: http://pastie.org/6354504
[14:32] <dusty42> zyga: yes, I'll check that for sure
[14:32] <timrc> infinity, Hi... so I back-ported a piece of lb_binary_rootfs from 3.0.1-1 to enable ext3 and ext4 rootfs's and I noticed a peculiar line "Chroot chroot "ln -s /proc/mounts/mtab /etc/mtab" (line 128)... this caused us to hit a bug in precise but was silent in quantal... /proc/mounts/mtab... is that... valid? (I had to change back to /proc/mounts to get it working)
[14:33] <timrc> infinity, wondering if you've encountered this at all
[14:33] <zyga> dusty42: cool, I suspect it is safe to just blindly change 'UTF-8' to 'C.UTF-8' since the magic C.UTF-8 locale was added to glibc
[14:36] <dusty42> zyga: yes, that's right
[14:37] <dusty42> zyga: however, where should this env variable be corrected?
[14:37] <zyga> dusty42: I would encourage you to document this, which osx version, what kind of settings (defaults matter) etc
[14:37] <zyga> dusty42: so if we do for just-the-app fix then we can simply change how we call setlocale
[14:37] <zyga> dusty42: if we want to do some bigger changes we'd have to ask someone else
[14:38] <zyga> pitti: ^^ do you know if it would be sane/good to fix broken env that comes from osx uses sshing into ubuntu?
[14:39] <zyga> pitti: like doing some tests in the early environment files that (hopefully) all the shells source, or even straight in the ssh package
[14:39] <pitti> zyga: I wouldn't quite know where, though
[14:39] <pitti> in general I have always found it rather questionable to forward locale env through ssh as well
[14:39] <pitti> it causes at least as much unintended damage as it does good
[14:40] <zyga> yeah, especially since there is no agreed-upon meaning for any of the values
[14:40] <zyga> I suspect that LC_TYPE=UTF-8 is valid somewhere but it just breaks us
[14:40] <dusty42> pitti: in case with OS X, the defaults are broken (well, at least with regard to Ubuntu settings)
[14:41] <zyga> pitti: alternatively
[14:41] <zyga> pitti: we could do it at libc level
[14:41] <zyga> pitti: where it would be an alias of C.UTF-8
[14:41] <dusty42> zyga: this sounds like the nicest workaround, actually
[14:41] <pitti> well, the names of locales are defined by the local localedef conventions and thus by the distro/OS
[14:42] <zyga> but I don't know if that's sensible actually -- can LC_CTYPE carry language definition?
[14:42] <pitti> that's one major reason why they don't belong forwarded
[14:42] <pitti> (the other is that in many cases the locale doesn't even exist on the remote machine)
[14:42] <zyga> it sure makes sense in LC_MESSAGES but for LC_CTYPE?
[14:42] <zyga> pitti: yeah, that's another valid problem
[14:42] <zyga> pitti: we track that separately
[14:42] <pitti> it's much better to use the remote computer's .bashrc or .pam_environment or whatever IMHO
[14:42] <pitti> no, it doesn't make sense for any LC_*
[14:43] <zyga> pitti: so do you think that what osx does is correct? sending us LC_CTYPE=UTF-8?
[14:43] <pitti> IMHO we should drop SendEnv from /etc/ssh/ssh_config, but I guess cjwatson feels otherwise
[14:44] <zyga> pitti: do you think we should move this to the mailing list to get feedback from more people?
[14:44] <pitti> zyga: well, UTF-8 is not a locale, but if OSX defines a locale with that name (presumably based on en_US), it's valid within an OSX context
[14:44] <zyga> pitti: the topic is certainly interesting but perhaps invisible to us, since we don't use windows/osx typically
[14:45] <pitti> oh, there is perhaps a workaround, see bug 313317
[14:45] <pitti> err, debian bug 313317
[14:46] <pitti> (which I actually consider a good thing)
[14:46] <pitti> debian bug 391964 and debian bug 558171 are also related
[14:46] <pitti> debian bug 573316 is probably the closes thing
[14:46] <zyga> pitti: yeah, that does sound right a lot
[14:46] <pitti> zyga: ^ in case you want to refer to some bugs in your mail
[14:47] <zyga> dusty42: ^^ would you mind looking at those as possible general solutions to this problem?
[14:47] <zyga> pitti: thanks a lot
[14:48] <pitti> well, these are not solutions, they are bugs which happen because of the locale forwarding
[14:48] <dusty42> Sure
[14:48] <pitti> I have more, like people create postgresql clusters with wrong encodings, and get tons of perl errors due to wrong locales
[14:49] <doko> xnox, well, in this case maybe consider moving the headers into a location where guile-1.8-dev had them
[14:49] <pitti> zyga, dusty42: so it seems cjwatson went off IRC for the first time in years, so bad time to discuss this :/
[14:50] <zyga> :D
[14:50] <zyga> pitti: I came across the postgresql bug myself, IIRC our cloud images were affected by tyhat
[14:50] <zyga> that
[14:51] <zyga> pitti: sorry, I misunderstood then, I'ms till reading the bugs you've referenced
[14:51] <dusty42> It's actually not that hard to handle this at app level
[14:52] <pitti> dusty42: so either fix it on the client ssh side by dropping SendEnv, or on the server side by adding a .pam_environment file with the correct locale for the remote system
[14:52] <zyga> dusty42: true but then each app has to do it
[14:52] <zyga> pitti: note that we cannot fix the client, this is osx that's causing the problem (and putty)
[14:52] <dusty42> zyga: of course, and this aint' cool at all
[14:52] <pitti> nah, fixing a broken environment really shouldn't be done by-app
[14:52] <zyga> pitti: although putty is broken in different way
[14:53] <zyga> IIRC putty uses some silly old encoding by default but does not actually specifies it as such in any of the environment variables it sends
[14:53] <Kano> hi, is there a lightdm channel or is it here?
[14:53] <zyga> like sending ISO8859-2 over the wire (and interpreting that locally for display) and not sending anything at all as environment
[14:54] <zyga> this causes issues with backspace and how it is interpreted
[14:55] <dusty42> pitti: so, as I understand, those bugs should be closed because it's the problem on the client system, not Ubuntu itself, correct?
[14:55] <pitti> dusty42: no, Debian/Ubuntu's ssh also defaults to forwarding these environment vars
[14:57] <zyga> dusty42: also note that most users don't understand that and just see broken ubuntu
[14:57] <dusty42> pitti: fixing the LC_CTYPE globally via /etc/.profile is a bad idea, right? E.g. detect if it's "UTF-8" and change to "C.UTF-8"?
[14:57] <zyga> dusty42: so if we can get a workaround that just makes things work right when we see broken input, that's good
[14:59] <dusty42> maybe not /etc/.profile, somewhere else (not yet sure where)
[15:01] <brendand> zyga, you're needed :)
[15:03] <hallyn> plars: hey, are you by any chance expert at building crosstools on recent ubuntu ?
[15:03] <zyga> :)
[15:03]  * zyga -> meeting
[15:04] <plars> hallyn: nope, sorry :(
[15:04] <hallyn> i've wasted like a day now trying to get it to compile, always ends up failing somewhere.  (used linaro releases 2012.10 and 2012.12 before, now using upstream )
[15:04] <hallyn> ok - thanks
[15:07] <zyga> plars: hey, long time no see, how are you  doing?
[15:17] <mitya57> Mirv: can you please apply https://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtsvg-opensource-src/revision/22 to Debian git?
[15:18] <mitya57> I've been doing some icon themes testing in Debian, and without that change SVG themes don't work
[15:28] <mitya57> Mirv: and while we are at it, please also apply http://paste.ubuntu.com/5573584/
[15:36] <mitya57> rickspencer3: Friday 27th Feb???
[15:38] <rickspencer3> hi mitya57
[15:38] <rickspencer3> did I put a weird typo in my email?
[15:38] <rickspencer3> *sigh*
[15:39] <rickspencer3> maybe I mean tomorrow :)
[15:40] <mitya57> hopefully everyone will understand that
[15:40] <Laney> rickspencer3: Friday 27th Feb? ;-)
[15:41] <rickspencer3> Laney,  I know I know
[15:41] <Laney> :P
[15:41] <rickspencer3> I spent *days* working on that email
[15:41] <rickspencer3> and I missed that one thing
[15:41] <rickspencer3> I am such a bad proof reader
[15:41] <Laney> yeah, the letters stop going in
[15:41] <Laney> you mean tomorrow, I guess?
[15:42] <jpds> Laney: Clearly, yesterday.
[15:42] <Laney> jpds: Ah, OK.
[15:42]  * Laney speeds up to 88mph
[15:42] <rickspencer3> thanks Laney
[15:42] <rickspencer3> :)
[15:42] <ogra_> only 88 ?
[15:43] <ogra_> ah, you're in an autobahn-less country ... /me forgot :P
[15:43] <Laney> rickspencer3: At least I just exposed that I didn't read the few lines immediately prior to my saying it ...
[15:43] <Laney> ogra_ hasn't seen back to the future?
[15:43] <rickspencer3> clearly
[15:43] <ogra_> oh, i missed the referral
[15:43] <ogra_> :P
[15:44] <plars> zyga: sorry, was in a meeting. I'm doing well, lots going on as always :)
[15:44] <zyga> plars: :-)
[15:45] <CalvinKlein> Laney, ^ that's for you
[15:46] <Laney> :D
[15:47] <Laney> stgraber: Hey ho
[15:47] <Laney> so, trying out user session jobs ... what's the compiz one for?
[15:47] <Laney> That should be started by gnome-session if needed shouldn't it?
[15:47] <doko> Sweetshark, online?
[15:48] <Laney> If I remove it I can start other gnome sessions (trying shell) under upstart
[15:50] <stgraber> Laney: right, compiz, nautilus, gnome-settings-daemon and pulseaudio are all example jobs to show what we could to if the plan was to phase out some parts of gnome-session
[15:50] <Sweetshark> doko: yes and in call
[15:51] <Laney> stgraber: ah
[15:51] <stgraber> Laney: I don't think we should push those to the archive as they're indeed not needed in the current state of things
[15:51] <Laney> but since we still call gnome-session then they can get in the way sometimes
[15:52] <xnox> Laney: but e.g. it would be nice to at least have gtk-window-decorators as an upstart job, cause it crashes a lot and we can respawn it. Similar with compiz. I'm not sure about gnome-session's respawing capabilities.
[15:52] <stgraber> Laney: compiz and nautilus might, gnome-settings-daemon and pulseaudio won't
[15:52] <Laney> right
[15:52] <stgraber> Laney: as gnome-settings-daemon and pulseaudio are overriden by /usr/share/upstart/xdg/autostart/
[15:53] <xnox> Laney: if you can point me which piece of gnome-session starts compiz i'd like to know, cause I failed to find the right place to override.
[15:53] <Laney> xnox: AFAIK the .session file for unity tells it to start
[15:53] <Laney> gnome-session searches for a matching .desktop file
[15:53] <xnox> Laney: we nifty prepend /usr/share/upstart/xdg to XDG_CONFIG_DIRS to shadow a few autostart/*.desktop files in favor of upstart jobs.
[15:54] <Laney> right
[15:54] <xnox> And I'd like to shadow compiz for example, in a similar fashion if possible.
[15:54] <Laney> so we'd want some kind of interfacing with .session files maybe
[15:54] <Laney> or something
[15:54] <xnox> cause imho having upstart manage the window manager would be awesome.
[15:54] <Laney> to only start compiz in a session which wants it
[15:54] <xnox> or we do it by default where ubuntu.session has upstart in it instead of compiz.
[15:54] <xnox> (wait that won't work)
[15:57] <Laney> see Required* in /usr/share/gnome-session/sessions/*.session and gnome-session(1)
[15:57] <stgraber> as long as we're in a world that mixes upstart and gnome-session, we're going to have to live with some hardcoded values in the jobs. It should however be possible to do something along the lines of "start on starting gnome-session DESKTOP_SESSION=ubuntu
[15:57] <tkamppeter> mlankhorst, you can close the bug, it is in fact some hardware problem.
[15:57] <stgraber> "
[15:58] <Laney> does that work?
[15:58] <Laney> could you have some thing which reads the .session files and emits some events based on what they'd cause to be started?
[15:58] <Laney> s/files/file to be loaded/
[15:58] <bochecha> hi, somebody opened a bug report against my project, that it doesn't install in the right place on Ubuntu 12.04
[15:59] <bochecha> looking closer, it turns out that the autotools stuff runs this code, to find where to install the Python module: http://paste.fedoraproject.org/3987/
[15:59] <bochecha> and as you can see in the paste, the returned folder is wrong (it should be python3.2, not python3)
[15:59] <bochecha> any idea on how to fix this properly?
[15:59] <stgraber> Laney: we may need an extra "export DESKTOP_SESSION" in gnome-session.conf, but yes, it's easy enough to get DESKTOP_SESSION to be exported to other jobs so they can start depending on that
[16:00] <Laney> I didn't know you could have "start on <some environment variable>" - that's useful for now indeed
[16:01] <didrocks> barry: doko: maybe you would have any idea on bochecha's question? ^
[16:01] <barry> bochecha: hi.  let me look
[16:02] <bochecha> barry, hi, thanks :)
[16:02] <stgraber> Laney: writing a parser for gnome-session should be possible too but I guess this really depends on the plans for the desktop, because it may be quite a bit of work to get something that's flexible enough and I don't think we want to invest that kind of time if there are chances we'd move away from gnome-session
[16:02] <stgraber> (not that I really know anything about your plans, hence why I ask ;))
[16:02] <Laney> right, I don't know that that's planned
[16:03] <Laney> or how much work it would be to nick parts of it out of gnome-session itself
[16:04] <barry> bochecha: well, actually, the path in line #2 looks right.  dist-packages is correct for debian/ubuntu (instead of site-packages), and because of pep 3147/3149 file tagging, we can install all python3 modules in the same location without conflict
[16:04] <bochecha> barry, but then, the module can't be imported in python3
[16:05] <barry> bochecha: line #1 does look a little weird in that sysconfig is imported but not used ;)
[16:05] <xnox> bochecha: hm why not? all python3.X look in python3/ location.
[16:05] <barry> bochecha: hmm, do you know why it can't be imported?  have you tried using -v?  can it not be imported because it can't be found, or because of some other problem on import?
[16:06] <bochecha> barry, actually, it can be imported, you're right that /usr/lib/python3/dist-packages is in sys.path
[16:06] <bochecha> I incorrectly  tried to reproduce the bug
[16:06] <bochecha> the reporter had used /usr/local as his prefix
[16:07] <bochecha> and /usr/local/lib/python3/dist-packages is not in sys.path
[16:07] <bochecha> barry, only /usr/local/lib/python3.2/dist-packages is
[16:07] <barry> bochecha: ah, yes, that's true
[16:08] <barry> bochecha: i guess if they're doing a source install, it has to go to /usr/local and not /usr
[16:08] <doko> correct, because we can't guarantee what the user installs there, and if it's compatible for different python versions
[16:08] <bochecha> barry, yes, that's the default with autotools anyway when you don't specify --prefix
[16:08] <bochecha> but then... what can I do?
[16:08] <barry> bochecha: agreed :)
[16:09] <bochecha> is my only choice to tell people « if you install on Ubuntu 12.04, use --prefix=/usr » ?
[16:10] <barry> bochecha: are you "distutils-based"?  setup.py and setuptools or distribute?
[16:10] <bochecha> pure autotools
[16:11] <bochecha> the command I pasted is what the configure script ends up running to find where to install modules
[16:13] <vibhav> doko: Thanks for sponsoring my merge :)
[16:14] <xxiao> i have a headless ubuntu 12.10, it pauses for a few minutes during boot, bootlogd showed Starting load fallback graphics devices                               [fail]
[16:14] <barry> bochecha: sorry, i was trying to see if we had any specific recommendation in our wikis, but it doesn't look like it
[16:14] <bochecha> :-/
[16:14] <xxiao> this is from udev-allback-graphics.conf, how can I disable this safely
[16:15] <barry> bochecha: give me just a few minutes...
[16:17] <bochecha> barry, of course :)
[16:18] <bochecha> barry, by the way, the code is at https://github.com/bochecha/pycangjie if that helps
[16:18]  * bochecha realizes he probably should have started with this...
[16:19] <barry> bochecha: ;)  let me try something with your trunk to make sure i don't recommend something that doesn't work
[16:20] <bochecha> barry, I don't want to bother you too much, there's a bunch of stuff you'd have to install beforehand
[16:20] <bochecha> like a more recent version of Cython
[16:20] <bochecha> or libcangjie
[16:21] <barry> bochecha: ah, okay.  try --prefix=/usr/local and if that doesn't work, probably hard coding installation into /usr/local/lib/pythonX.Y/dist-packages will be the most expedient thing
[16:24] <xxiao> is there a verbose mode of upstart that I can see more info at startup, even timestamps?
[16:25] <bochecha> barry, specifying --prefix=/usr/local gives the same result as not specifying it: /usr/local/lib/python3/dist-packages
[16:26] <barry> bochecha: i guess the code is in configure.ac?
[16:26] <bochecha> barry, yes
[16:27] <bochecha> barry, https://github.com/bochecha/pycangjie/blob/master/configure.ac#L24
[16:28] <bochecha> but the automatically generated configure contains this: http://paste.ubuntu.com/5567643/
[16:29] <bochecha> the code which ends up being executed is what I had pasted earlier: $PYTHON -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='$am_py_prefix'))"
[16:31] <xnox> barry: I half wish pkgconfig files for python would specify the default locations.
[16:31] <xnox> barry: cause above would fail to cross-compile.
[16:33] <barry> xnox: agreed.  this really should be easier and better documented
[16:34] <barry> (for non-distutils stuff)
[16:36] <barry> bochecha: well, this won't make you happy, but probably the generic thing to do is scan sys.path for the first /usr/local path and use that :/
[16:36] <barry> sysconfig won't help you because there are no /usr/local paths there
[16:37] <doko> jodh, stgraber:  I still see https://launchpad.net/~canonical-foundations/+archive/upstart-daily/+build/4333370 hanging. I thought that was fixed in the ppa?
[16:37] <bochecha> barry, hmmm, but that's all automatically generated by the autotools, I'm not sure I want to interfere with what they do :-/
[16:38] <stgraber> doko: I don't see enough context in that part of the log to know if it's the same bug
[16:38] <jodh> doko: that 'tail' doesn't show what test failed.
[16:39] <stgraber> doko: and it worked on all other architectures, so it's not the same bug
[16:39] <stgraber> oh, and the previous daily worked on armhf too, so it may just be some kind of race
[16:40] <barry> bochecha: you may not have a choice but to override this.  i suspect that really autotools needs to learn about this.  maybe doko has some opinion about that
[16:41] <bochecha> barry, what I don't understand is that on 12.04, sys.path contains /usr/local/lib/python3.2/dist-packages
[16:41] <bochecha> but then, what's the point of containing that folder if it's not where stuff gets installed?
[16:41] <barry> bochecha: the problem is that autotools doesn't know about that installation location.  i'm fairly sure that a setup.py based install would dtrt
[16:42] <bochecha> well, autotools is only returning what that python code I pasted above returns
[16:42] <bochecha> on Fedora, that Python code returns the right thing
[16:43] <bochecha> and when run with --prefix=/usr, that Python code also returns the right thing on Ubuntu 12.04
[16:44] <bochecha> so to me, it looks like Ubuntu is doing something fishy with its Python paths
[16:44] <bochecha> or rather, with the path in /usr/local that ends up in sys.path
[16:45] <pitti> mdeslaur: so it actually is planned to put USNs into the previous monthly snapshot?
[16:46] <pitti> mdeslaur: I wonder, wouldn't these people just upgrade to the latest daily packages anyway the first time update-notifier pops up?
[16:46] <pitti> mdeslaur: i. e. as soon as we fix stuff in the devel release together with stables, wouldn't that already fix it for everyone?
[16:46] <pitti> mdeslaur: otherwise we would actually need a new series each month
[16:47] <Daviey> pitti: I wonder if there is a way a new series could be avoided.
[16:47] <pitti> mdeslaur: ah, maybe I'll reply to your mail instead, to keep discussion at one place
[16:47] <bochecha> barry, what is the reason for sys.path containing /usr/lib/python3/dist-packages but /usr/local/lib/python3.2/dist-packages ?
[16:48] <mdeslaur> pitti: I don't know the exact details of how the monthly snapshots will be handled with regards to pockets and such, but for security updates that are urgent, such as the sudo CVE that just came out, I'll be pushing that in both places
[16:48] <mdeslaur> pitti: ah, yes, we can discuss on the list
[16:48] <zyga> pitti: exciting times ahead :-)
[16:49] <pitti> mdeslaur: posted
[16:50] <barry> bochecha: doko said earlier: <doko> correct, because we can't guarantee what the user installs there, and
[16:50] <barry>        if it's compatible for different python versions
[16:50] <pitti> Daviey: yeah, IMHO new series each month would be just mad
[16:50] <bochecha> barry, but for stuff in /usr/lib/... you can?
[16:50] <pitti> Daviey: I understood the monthly things as blessed snapshots, not full releasese
[16:50] <barry> bochecha: yes, because apt controls /usr/lib :)
[16:51] <bochecha> sure, but are packages actually tested to work with other Python 3 versions?
[16:51] <bochecha> or is it « compatible with all Python 3 versions installed in /usr, and no version other than the one provided by apt should ever be installed in /usr » ?
[16:52] <barry> bochecha: if they are packaged correctly, and they have a test suite, then they will be tested against all supported python3 versions for the distro-version. (autopkgtests can also be added to tests for simple stuff like importability).
[16:52] <barry> bochecha: correct
[16:52] <bochecha> honestly, that's annoying
[16:53] <barry> bochecha: "that's" == ?
[16:53] <bochecha> about just as annoying as the result of --prefix=/usr/local on Fedora (there is nothing in /usr/local in the default sys.path, so modules must be installed in /usr :P)
[16:53] <bochecha> barry, the situation with installing Python modules in /usr/local in Ubuntu
[16:53] <bochecha> (but then again, it's annoying on Fedora too, for different reasons)
[16:53] <barry> bochecha: i'd amend that to be "non-setuptools based modules" and i agree
[16:54] <bochecha> :)
[16:54] <barry> bochecha: at the very least, we should have clear documentation about best practices here, which we don't, and that also sucks
[16:55] <bochecha> barry, I'll try to figure out a not-too-dirty way to test for the distro, and if it's Ubuntu and prefix=/usr/local then use py3versions to find the right path
[16:55] <barry> bochecha: unfortunately, right now i don't have any time to push that forward.  if you have time and inclination, a discussion on the debian-python mailing list would be fantastic, and it's always possible i'm missing something obvious
[16:55] <barry> bochecha: fwiw, ubuntu inherits all this behavior from debian, so pushing this upstream will give the best results
[16:56] <bochecha> barry, well, I'm just a FOSS developer, and a Fedora user/contributor, so you'll understand that improving the Debian/Ubuntu Python stack is not necessarily my highest priority ;)
[16:56] <barry> bochecha: i do ;)
[16:56] <bochecha> I'm just very interested in having my stuff install and run cleanly on Ubuntu
[16:57] <bochecha> because it turns out most people who are likely to use my software are running Ubuntu
[16:57] <barry> bochecha: tell toshio, dave malcolm, or nick coghlan to bug me at pycon :)
[16:57] <bochecha> heh :)
[16:57] <bochecha> anyway, thanks a lot for all the pointers, the issue is now much clearer in my mind
[16:58] <jbicha> hmm, I wonder how I magically became unsubscribed to ubuntu-devel, I've been missing all the excitement
[16:58] <bochecha> I'll try to fin a way to fix it tomorrow though, it's 1am here
[16:58] <barry> bochecha: another low bandwidth thing you could do is to file a bug here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=python3-defaults or https://bugs.launchpad.net/ubuntu/+source/python3-defaults and while they may not be the ultimate best place to fix them, at least the issue doesn't fall off the radar by being in irc
[16:58] <barry> bochecha: sure, sorry i don't have better news
[16:59] <bochecha> no problem, I'm much better off than before coming in here: now I understand what the problem is :)
[16:59] <bochecha> anyway, going to bed now
[16:59] <bochecha> thanks again barry
[16:59] <barry> bochecha: cheers
[17:09] <tedg> Does anyone know if someone has tried to use the abi-compliance-checker to create something like a symbols file, but with more coverage?
[17:11] <sladen>  /join #ubuntu-community
[17:17] <tedg> slangasek, ^ this seems like something you'd know :-)
[17:18] <slangasek> tedg: I don't know anything about the abi-compliance-checker package in particular.  What do you mean by "like a symbols file"?
[17:19] <tedg> slangasek, It can do a dump.  So and then compare.  So I could do an acc dump, and see if the ABI has changed since that dump.  Basically the way a symbols file is checked for new/removed symbols.
[17:19] <slangasek> tedg: a long, long time ago I was familiar with icheck, which had a similar kind of "cache the current api" interface
[17:19]  * slangasek nods
[17:19] <slangasek> tedg: so icheck may be a better starting point?
[17:20] <xnox> tedg: I did.
[17:20] <xnox> tedg: and it did catch abi breakage in my package.
[17:20]  * tedg is looking at icheck
[17:20] <tedg> xnox, Used icheck or acc?
[17:20] <xnox> acc
[17:20] <tedg> xnox, Did you do it as part of the package build?
[17:21] <xnox> tedg: yes, but I ended up storing the processed /old/ reports in the source package.
[17:21] <xnox> tedg: i have a workitem to implement this genericly for "core desktopy / graphical libraries" as needed by steam. But no such list emerged so far.
[17:22] <xnox> tedg: what would you like to track abi off?
[17:22] <tedg> xnox, Everything!  :-)
[17:22] <tedg> xnox, Specifically we were looking at the Unity-ish libraries we maintain.
[17:22] <xnox> and in the cloud?!
[17:22] <seb128> tedg, did you come to that topic on your own or as part of some team thinking? just asking because it's something that tvoss discussed a bit with lool and slangasek recently, they took an action item to look at it
[17:22] <seb128> tedg, in any case if you are just looking at the same problem by coincidence, maybe talk to lool ;-)
[17:22] <tedg> xnox, But for some more general solution, than us just doing it for fun.
[17:23] <Laney> have you seen http://upstream-tracker.org/ ?
[17:23] <xnox> tedg: there is some code to run it as a service against many opensource libraries as in upstream-tracker,
[17:23] <tedg> seb128, We'd talked about it before.  I didn't realize anyone else had started looking into it more than chat.
[17:23] <xnox> but that obviously lacks ubuntu-applied patches.
[17:23] <tedg> Sure, and I'd like to fail a build if it changes unknowingly.  Daily quality and all that.
[17:24] <tedg> So a webservice doesn't really work there.
[17:24] <xnox> i was thinking to have it run in jenkins / adt test
[17:24] <seb128> tedg, we had an hangout where we discussed that either, lool/slangasek have an action item to investigate, talk to them ;-)
[17:24] <xnox> but I'm not sure where / how to store previous result for comparison with just built one.
[17:24] <tedg> xnox, Why not in the debian/ directory just like the symbols file?
[17:25] <xnox> something like ship it in-the package and then before britney migrates stuff grab one from -release and one from -proposed and fail if abi is broken and package is not renamed.
[17:25] <tedg> seb128, Will do, but thinking they might have already seen your ping ;-)
[17:25] <seb128> tedg, yeah, it was sort of the point
[17:25] <seb128> tedg, just making sure that you guys talk and don't do twice the same investigation work ;-)
[17:26] <xnox> tedg: generate the first one, commit and have hooks to check at build time. Ok, sounds like a good enough start.
[17:26] <xnox> tedg: I can write a dh_helper to do that.
[17:26] <tedg> xnox, That'd be awesome!
[17:27] <tedg> I'll use it :-)
[17:27] <xnox> ack.
[17:27] <slangasek> tedg, xnox: I think the api manifest should be generated at source package prep time and shipped in the source package
[17:27] <slangasek> then checked at package build time
[17:29] <xnox> slangasek: no. because current manifest will always match current built. one wants to compare the first shipped version of the package (n) with current api/abi no make sure this new (n+3) version is compatible.
[17:31] <slangasek> xnox: by "at source package prep time" I don't mean "each time you build the source package"
[17:31] <slangasek> just like .symbols
[17:32] <xnox> i see what you mean. yes.
[17:33] <xnox> after adding config file, one would not get a comparison but just initial manifest on first build.
[17:33] <xnox> if it's stored in the source package subsequent builds will do comparison.
[17:33]  * slangasek nods
[17:35] <xnox> pitti: new gtk doesn't know what a green color is? =) http://paste.ubuntu.com/5573983/
[17:35]  * xnox investigates.
[17:56] <lool> tedg, seb128: Yup; essentially this comes from tvoss proposing that we adhere to API and ABI stability policies and we need tools to enforce that; slangasek brought up icheck and we need to investigate how to leverage which tools where
[17:56] <lool> other things that came up for the ABI were e.g. use of symbol versioning
[17:57] <slangasek> lool: right... the question is, why is tedg worrying about it if we have the action item :)
[17:58]  * tedg didn't know slangasek and lool had the action item :-)
[17:58] <lool> I think tedg has a microphone in my home somewhere
[17:59] <ev> any ubuntu-devel@lists.u.c moderators around? Keybuk's post is apparently stuck in the queue.
[17:59]  * tedg would ask lool to please speak softer, you're hurting my ears!
[17:59] <slangasek> I was going to point to cjwatson, but his network apparently ate itself 6 hours ago
[18:13] <xnox> slangasek: yeah, he did mention restructuring his network ;-)
[18:14] <slangasek> yah, he'd mentioned to me he was going to be doing that... guess it's not going so well :-P
[18:14] <xnox> stgraber: u-d@lists.u.c can you moderate Keybuk's message?
[18:14] <stgraber> xnox: I don't think I have moderation access for u-d
[18:14] <micahg> one was already let through
[18:19]  * Laney is happy to volunteer to mod if manpower is needed
[18:19] <chrisccoulson> slangasek, xnox, he did post on twitter a short while ago https://twitter.com/colmmacuait/status/307185273924616192
[18:20] <slangasek> :-)
[18:21] <xnox> ev: I like how to ride the wave to advertise phased updates & errors work ;-)
[18:21] <ev> xnox: it was more to reassure people
[18:21] <ogra_> Laney, i guess manpower is needed ... ast cjwatsons place :)
[18:21] <ogra_> *at
[18:22] <Laney> ain't sysadminry fun?
[18:22] <ev> if we didn't have a way to keep tabs on the development over the two years or so, a way to measure ourselves against the previous LTS, it'd be a much harder sell
[19:03] <davmor2> is there a known issue with the battery meter saying crazy stuff, like 12.47 to charge when it has been on charge most of the day?
[19:07] <slangasek> davmor2: yes; this known issue is that you can never reliably know how long a charge will take, and also that batteries are mixed in how good of information they give
[19:07] <slangasek> however, it's possible this is not the same issue you're seeing
[19:09] <davmor2> slangasek: well it's been on charge for 5 hours-ish and says 86% full for a laptop that I got in January, the time down is all over the place and then the time to charge is the same.  However a couple of days or so ago it seemed a lot more accurate
[19:10] <slangasek> davmor2: yep - unfortunately I can't say from that whether it's a software bug, a battery physical failure, or a battery firmware failure
[19:11]  * ogra_ guesses for a SW bug .... it started for me on the nexus7 with the switch to raring
[19:11] <slangasek> ah, well then
[19:11] <ogra_> my chromebook had it too until i switched to a differet desktop
[19:11] <davmor2> ogra_: thanks
[19:11] <slangasek> bug report to gnome-power-manager, maybe?
[19:11] <ogra_> so i would blame upower here
[19:11] <ogra_> g-p-m only has some UI bits left, upower is the new stuff
[19:12] <ogra_> check if "upower -d" also gets you odd values
[19:12] <davmor2> slangasek: so u-b upower  any info that would be useful to you guys ?
[19:12] <davmor2> ogra_: will do one second
[19:13] <slangasek> davmor2: ubuntu-bug should do it
[19:13] <ogra_> yeah
[19:14] <davmor2> ogra_: yeap upower currently says 2 hours to total charge for the last 14% of the battery :)
[19:15] <ogra_> :)
[19:20] <davmor2> ogra_: bug #1136227
[19:22] <bdmurray> Daviey: you might be interested in https://errors.ubuntu.com/?user=ubuntu-server
[19:25] <Daviey> bdmurray: I bet my left arm those are all ubuntu desktop installs :)
[19:27] <bdmurray> Daviey: the point isn't those crashes but that you can see crashes associated with packages to which the ubuntu-server team is subscribed
[19:27] <slangasek> Daviey: hmm, does that mean you don't care about frequent crasher bugs in packages you maintain if the data comes from people installing them on the desktop?
[19:27]  * slangasek loads the page -ooh, pretty graph
[19:27] <Daviey> slangasek: it more likely means people will put words in my mouth.
[19:27] <slangasek> oh, the top crashers are all in samba
[19:28] <slangasek> yeah, run away ;)
[19:31] <slangasek> bdmurray: drive-by bug report: the table of packages on this crash page doesn't seem to know that precise-security and precise-updates versions are part of Ubuntu 12.04?  https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fsbin%2Fsmbd%3A6%3Adump_core%3Asmb_panic%3Aset_unix_security_ctx%3Aset_sec_ctx%3Achange_to_user_internal
[19:31] <bdmurray> arges: there are 2 uploads of iptables by you to the precise-proposed queue
[19:31] <arges> bdmurray: hi
[19:32] <bdmurray> slangasek: that'll get sorted out when we have the new bucketversion column famly
[19:32] <slangasek> bdmurray: ok
[19:32] <arges> bdmurray: yes. these fix two differnt bugs
[19:33] <bdmurray> arges: right but neither includes fixes from the other
[19:34] <arges> bdmurray: ok how should i approach this? I can't upload myself, should I submit a debdiff with both fixes applied?
[19:36] <bdmurray> arges: yes, let me know and I'll upload it for you.  in the mean time I'm going to reject the existing ones
[19:37] <arges> bdmurray: ok one debdiff comin right up. thanks
[19:49]  * mpt wonders if there is a count of how many SRUs 12.10 has had so far
[19:50] <slangasek> you could tally from the mails on quantal-changes for everything that post-dates the release
[19:50] <slangasek> IIRC, that would give you the count of successfully completed SRUs, but not those that failed out or are in progress (or stalled)
[19:51] <mpt> ...hundreds :-)
[19:51] <mpt> ok
[19:51]  * slangasek nods
[19:52] <arges> bdmurray: http://people.canonical.com/~arges/iptables/ , I have the debdiff, dsc files in this directory. I have verified that this package fixes the two bugs on my amd64 machine.
[20:07] <bdmurray> arges: uploaded
[20:08] <arges> bdmurray: thanks
[20:11] <barry> would a pythonista care to review this m-p?  i'm most interested in reviewing my thinking behind the change (since it's just a one line change) and offer insights into how to reproduce/test it: https://code.launchpad.net/~barry/aptdaemon/lp1120322/+merge/151083
[20:13] <lifeless> barry: looking
[20:13] <barry> lifeless: thanks.  there might be a little more context in the linked bug discussion
[20:14] <lifeless> there are 7 pending branches
[20:14] <lifeless> might want to look at cleaning that up as you go ;0
[20:15] <barry> heh, yeah
[20:17] <lifeless> what version of python are the reporters running
[20:18] <lifeless> 2.7's difflib physically cannot yield lines other than ---/+++/@@ without including the @@
[20:18] <barry> lifeless: 3.2 and 3.3 i think
[20:18] <lifeless> difflib.py line 1211
[20:19] <lifeless> ah, I see the issue
[20:19] <lifeless> your analysis is wrong
[20:19] <lifeless> the action might be correct.
[20:22] <barry> lifeless: hmm, i guess REGEX_RANGE check could fail, causing the @@ match to never get to the line_number assignment
[20:22] <lifeless> right
[20:22] <lifeless> I'm just explaining the situation that will happen in
[20:22] <barry> lifeless: excellent, that will help produce a test case :)
[20:24] <lifeless> barry: https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/1120322/comments/8
[20:25] <barry> lifeless: nice catch, thanks.  makes sense and should be testable.
[20:26] <lifeless> barry: thats why they pay me the big bucks
[20:26] <barry> :)
[20:26] <lifeless> barry: its special cases like this that make many specs horrendous to implement
[20:27] <barry> lifeless: python -c "import this" | grep special
[20:29] <lifeless> yeah
[21:07] <hallyn> slangasek: do you think shipping a symlink from /usr/bin/kvm-spice -> /usr/bin/kvm in qemu-system-x86 for all users is no big deal?  (it feels heavyhanded to me as the only people who need it are people who had qemu-kvm-spice installed before)
[21:07] <hallyn> but it *is* just one symlink...
[21:10] <lifeless> hallyn: update-alternatives
[21:10] <lifeless> hallyn: perhaps ?
[21:12] <hallyn> lifeless: i'm not worried about people who type it by hand - only people who have a libvirt VM defined with /usr/bin/kvm-spice as the hardcoded path to the emulator
[21:12] <hallyn> do alternatives help with that?
[21:12] <slangasek> hallyn: sorry, are you asking me if it's ok to provide the symlink?
[21:12] <hallyn> oh, i guess so?  they'll put a  symlink into place?
[21:12] <hallyn> slangasek: yeah.
[21:12] <lifeless> hallyn: yeah, alternatives provide symlinks to binaries when multiple packages might supply the binary
[21:12] <hallyn> slangasek: given that kvm-spice was provided by a universe package, and kvm by main
[21:13] <hallyn> lifeless: there aren't multiple packages though
[21:13] <lifeless> ah
[21:13] <lifeless> possibly not useful here then
[21:13] <slangasek> hallyn: if you do, you should also add Conflicts/Replaces/Provides to the package metadata against the old qemu-spice package, whatever it was called?
[21:13] <slangasek> (qemu-kvm-spice)
[21:13] <hallyn> slangasek: that's already there
[21:14] <slangasek> hallyn: and taken as a whole, I think that's a good idea
[21:14] <hallyn> to force qemu-kvm-spice off the system
[21:14] <slangasek> hallyn: ah, not according to my apt-cache :)
[21:14] <hallyn> slangasek: oh, it's on qemu-kvm
[21:14] <hallyn> not on qemu-system-x86
[21:15] <slangasek> hallyn: ok, in that case I'd put the symlink in qemu-kvm
[21:15] <hallyn> slangasek: ok will do, thanks.
[21:20] <smoser> anyone know...
[21:21] <smoser> when i do: losetup --show --find /tmp/my.img
[21:21] <smoser> something sets up /dev/loop0p1
[21:21] <smoser> what is that? because sometimes it seems not to work for me.
[21:26] <cody-somerville> smoser: kpartx can do that
[21:26] <smoser> it can do that.
[21:26] <smoser> but sometimes something magically *does* do that.
[21:27] <czajkowski> cjwatson: welcome back
[21:27] <czajkowski> Laney: think it's safe for me to do an update now ?
[21:27] <Laney> try it
[21:27] <czajkowski> if it breaks I'll come find you ;)
[21:29] <Laney> it would have worked anyway; my upload was just to try and stop you getting a partial upgrade
[21:30] <soren> smoser: And you're sure it's not kpartx?
[21:30] <smoser> soren, well, i'm not sure at the moment...
[21:30] <smoser> but 'apt-get install kpartx' doesn't just make it star tworking
[21:30] <cody-somerville> smoser: I think it happens if max_part is set on loop  kernel module
[21:30] <soren> smoser: It was a udev rule that's supposed to do exactly that.
[21:30] <soren> *has
[21:31] <smoser> soren, yeah, i think that udev is not recognizing the rule on install
[21:31] <czajkowski> Laney: http://pastebin.ubuntu.com/5574632/
[21:32] <Laney> czajkowski: do you get a partial upgrade?
[21:32] <smoser> soren, well, i somewhat verified its not kpartx.
[21:32] <smoser> apt-get --purge remove kpartx
[21:32] <Laney> i don't know what's going on with ibus-table there
[21:32] <smoser> and i'm still getting the devices
[21:32] <cody-somerville> smoser: do modprobe -r loop && modprove loop max_part=63
[21:33] <cody-somerville> smoser: and then see if it sets up the /dev/loopNpN after setting up loop device again on disk image
[21:33] <czajkowski> Laney: nope all good now
[21:33] <smoser> cody-somerville, but what would have changed that in these 2 settings?
[21:33] <smoser> i'll try though
[21:34] <smoser> cody-somerville,
[21:34] <smoser> FATAL: Module loop is builtin.
[21:34] <Laney> czajkowski: cool beans
[21:34] <Laney> thanks for reporting
[21:34] <czajkowski> np
[21:35] <cody-somerville> smoser: ok, you can set the option then by passing option using the kernel command line then: loop.max_part=63
[21:36] <smoser> cody-somerville, i've not done that on either system. same kernel.
[21:36] <smoser> (they're both raring instances...)
[21:39] <cody-somerville> does 'cat /sys/module/loop/parameters/max_part' spit something different out between the two of them?
[21:39] <smoser> soren, '0' on both
[21:40] <cody-somerville> but one will automatically create /dev/loopNpN files for the same disk image when you loop mount it and the other doesn't?
[21:44] <soren> smoser: max_part needs to be > 0 at init time for it to matter here.
[21:45] <soren> I think, however, that doing a blockdev --rereadpt /dev/loop/X will cause the /dev/loopXpY devices to be created.
[21:46] <smoser> soren, what would make 'max_part' > 0 ? (which is not the case on either of my systems)
[21:46] <soren> So something might be doing that (or issuing the corresponding ioctl's by some other means) separately.
[21:46] <soren> smoser: kernel cmdline parameter.
[21:46] <soren> Since it's a builtin module, it has to be set that early.
[21:47] <soren> This is based on reading the driver code. I could be reading it wrong, but it looks fairly straight forward.
[21:47] <smoser> http://paste.ubuntu.com/5574669/
[21:47] <smoser> well,
[21:47] <smoser> $ cat /sys/module/loop/parameters/max_part
[21:47] <smoser> 0
[21:47] <smoser> on both systems
[21:47] <soren> Gotcha.
[21:48] <soren> Can you trigger their creation by issuing a "blockdev --rereadpt /dev/loopX"?
[21:49] <smoser> $ sudo blockdev --rereadpt /dev/loop0
[21:49] <smoser> BLKRRPART: Invalid argument
[21:49] <smoser> on both
[21:49] <smoser> i'm not sure how i got the one system actiing this way.
[21:50] <soren> Interesting.
[21:50] <smoser> actually..
[21:50] <smoser> i think i know what it is
[21:51] <smoser> its related to partx --update
[21:52] <smoser> yeah, it is.
[21:52] <smoser> because i can actually drop the 'sfdisk' in that pastebin
[21:52] <smoser> and i still get /dev/loop0p1 on one system
[21:52] <smoser> and if i change it to not use '--find'
[21:52] <smoser> and specify losetup //dev/loop3
[21:52] <smoser> then it does not get /dev/loop3p1  created
[21:54] <smoser> yep.
[21:54] <smoser> so on the working system..
[21:54] <smoser> "working"
[21:54] <smoser> i did:
[21:55] <smoser> i ran that pastebin. then in the subshell did:
[21:55] <smoser> partx --delete 1 /dev/loop0
[21:55] <smoser> and i no longer get it magically created.
[21:55] <smoser> it seems that if you partx --update, then the kernel somehow remembers.
[21:55] <smoser> (incorrectly)
[22:07] <mpt> achiang, oh snap
[22:07] <mpt> We posted the same thing :-)
[22:07] <achiang> mpt: my biggest accomplishment for the day! :)
[22:08] <mpt> heh
[22:11] <achiang> it's kinda late in london, no?
[22:24] <xnox> mpt: achiang: I thought monthly _iso_ is meant as a checkpoint to do extensive hw verification and installer testing.
[22:24]  * xnox is not expecting actually user visible "monthly upgrades"
[22:25] <slangasek> xnox: the proposal on the table includes monthly upgrades
[22:26] <xnox> slangasek: yeah, I noticed =)))) i'm still pondering on how it will affect me, my packages, my machine(s) and people I provide support for.
[22:27]  * xnox remembers setting most of windows software to auto-update using beta channels if available. Nobody noticed anything broken.
[22:32] <xnox> e.g. openSUSE has a rolling factory release, some/most things go directly there, but other groups of strongly connected components are overlays on top of factory, e.g. GNOME:Factory and KDE:Factory. Once api/abi transitions and shaken out, those packages are promoted into Factory.
[22:32] <xnox> many people enable the overlays they care about.
[22:33] <xnox> the major difference that their overlays can completly include dependency overlays such that one simply needs to enable GNOME:Factory to get latest gnome packages which are actually spit into further 2 overlays behind that one.
[23:34] <xnox> quantal... in more ways than in knew it's going to be.