[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 <IP_ADDRESS>, 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<EMAIL_ADDRESS>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<EMAIL_ADDRESS>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.


[00:07] <directhex> hm. this isn't technically correct, but does the job ( i hope)
[00:32] <fta> kiko, I'm done with songbird 1.0.0 but apparently, there's an issue with the ppa builders so cprov killed my builds. I have no way to investigate as locally, it's all fine.
[00:49] <ScottK> If a package has a substantially larger popcon than the sum of the popcon of all it's rdepends, would that be a reason to think people are using it with something unpackaged?
[00:50] <ScottK> I came up dry using Google.
[00:53] <Hobbsee> ScottK: or popcon is on crack.  But yes, i'd sya that's probably a reasonable assumption
[00:54] <Hobbsee> popcon doesn't do partial reporting, afaik, so i presume that's the only solution
[00:54] <ajmitch> ScottK: that's not such a problem though, is it?
[00:55] <ajmitch> if you need to change something about the package (say the ABI), it it breaks 3rd party stuff, how were you to know?
[00:55] <ScottK> ajmitch: It's not a problem, but something accounting for ~200 popcon in Debian that's not packaged might be worth packaging.
[00:55] <ajmitch> trying to identify what that thing is will be fun
[00:55] <ScottK> I'd like to know what it is.
[00:55] <ScottK> Yeah.
[00:57] <ScottK> If someone is bored, the package in question is python-dns.
[00:57] <ScottK> Not something you're likely to install directly.
[00:58] <ajmitch> so it's either something unpackaged, or people are installing it directly to actually use the module in something they've written
[00:58] <kiko> fta, hmm, I'll ping cprov to figure out what's up
[01:00] <ajmitch> ScottK: funnily enough, I'm one of the latter
[01:01] <Hobbsee> ScottK: blog about it, and ask?
[01:02] <ScottK> ajmitch: You installed it directly?
[01:02] <ajmitch> it appears so
[01:02] <ScottK> Hobbsee: That might work.
[01:02] <ScottK> Odd.
[01:02] <Hobbsee> ScottK: planet's always good for those sorts of things
[01:02] <ScottK> Yeah.
[01:02]  * ajmitch does have python-formencode installed, by the look of things
[01:03] <ajmitch> but I think I did actually look at using python-dns directly
[01:04] <ScottK> python-formencode is it's largest (by popcon) rdepend.
[01:04] <ajmitch> not surprising
[01:04] <ajmitch> since python-turbogears & python-pylons use it
[01:04] <ScottK> Ah.  Makes sense.
[01:10] <st33med> Has anybody made the closed source version of Virtual Box available on multiverse?
[01:14] <stdin> can the binary be distributed freely?
[01:14] <st33med> Yep
[01:15] <st33med> http://www.virtualbox.org/wiki/Linux_Downloads
[01:15] <st33med> Wait
[01:15] <DarkKnight> hey i m a newbie...and wanted to be on the MOTU team....i read the wiki page...but there are certain things that i didnt understand
[01:15] <st33med> Does accepting a license count as free?
[01:16] <st33med> Say em DarkKnight, might be a while for someone to reply
[01:17] <DarkKnight> ya i just wished to be one of the developers in ubuntu...
[01:17] <DarkKnight> so wen i referred the wiki page....
[01:17] <ajmitch> st33med: http://www.virtualbox.org/wiki/Licensing_FAQ has a fairly clear no on redistribution of binaries
[01:17] <DarkKnight> it said that i had to file a bug or something
[01:17] <stdin> yep FAQ 7 says no
[01:17] <st33med> Ah
[01:17] <DarkKnight> to which i did
[01:18] <Hobbsee> st33med: note all of virtualbox-ose, virtualbox-ose-dbg, virtualbox-ose-source, virtualbox-ose-guest-source, virtualbox-ose-guest-utils
[01:18] <st33med> Yah
[01:18] <Hobbsee> and perhaps a couple of others
[01:18] <Hobbsee> (which are in universe)
[01:18] <st33med> OSE doesn't have USB support, which kinda sucks
[01:19] <stdin> one could, theoretically, do what is done with flash
[01:19] <stdin> ie, create a package which downloads it from their website
[01:19] <DarkKnight> so can anyone tell me where i can getgood info about compiling  packages
[01:19] <stdin> but that'd require running dpkg inside a dpkg run, so it's bad
[01:20] <stdin> !packaging
[01:20] <stdin> and..
[01:20] <stdin> !compiling
[01:20] <Hobbsee> stdin: or one could just use the repositories from virtualbox.org, which also work reasonably well ;)
[01:21] <stdin> yeah, much easier. which is probably why no one has ever tried to create such a package
[01:23] <Hobbsee> stdin: well, the OSE versions are already there, so...
[01:26] <st33med> And anyone who has heard of it most likely visited the website too
[01:26] <st33med> So yah.
[01:35] <nellery> is there any way to run debuild without getting the DebianMaintainerField error?
[04:13]  * ScottK-laptop starts to wonder if this thing is actually on?
[04:30] <leonel> scottK ping
[04:36] <ScottK> leonel: pong
[04:36] <leonel> scottK for the  jpeg  the code has changed
[04:37] <leonel> scottK in  special.c  the patch applies fine
[04:37] <leonel> but there are   structs  changes  for example  maxreclevel  in   0.92.1  is in cl_limits  and  in 0.94  has been moved to  cl_engine
[04:38] <ScottK> leonel: Right.  So does that mean the patch needs to be adapted?
[04:38] <leonel> I think so
[04:38] <leonel> and  in the svn from clamav
[04:39] <leonel> the  changelog for the 1266 clamav bug
[04:39] <leonel> does not shows the changes  in  others.h or  in clamav.h  for that change
[04:40] <leonel> so I guess I'll first find an exploit for the code  test it  and if  is vulnerable  try to adapt the code
[04:40] <leonel> as you asked previously that if 0.92.1 is vulnerable
[04:42] <ScottK-laptop> leonel: My guess is that unless you find some kind of recursion limit in special.c it's vulnerable, but that sounds good.
[04:43] <leonel> ScottK-laptop: if(ctx->recursion > ctx->engine->maxreclevel)
[04:43] <leonel>   	            return CL_EMAXREC;
[04:44] <leonel>  those and another reference is there
[04:44] <leonel> but the maxreclevel is on another  struct
[04:44] <leonel> in 0.92.1
[04:46] <leonel> got to go  I'll continue  tomorrow  morning
[04:47] <ScottK> OK.
[04:47] <ScottK> leonel: Thanks for working on this.  I know it's not simple.
[04:48] <leonel> scottK   this must get fixed .. see you tomorrow
[04:48] <aib> i'm interested in packaging our software and having it included in ubuntu. is this possible? our software is called Emergent and we have been running our own ubuntu repository for years. http://grey.colorado.edu/emergent
[04:49] <ScottK-laptop> aib: If it's got an appropriate license the answer is generally yes.
[04:49] <aib> GPL
[04:49] <aib> where do I start?
[04:52] <ScottK-laptop> aib: You have experience with Debian packaging then?
[04:52] <aib> extensive
[04:53] <ScottK-laptop> OK.  Ubuntu essentially follows Debian policy with some minor variations.
[04:53] <ScottK-laptop> Initial revision for a package not in Debian would be -0ubuntu1.
[04:54] <ScottK-laptop> Upload target would be jaunty instead of unstable
[04:54] <jdong> "copyright" 599L, 19060C written
[04:54] <jdong> whee :)
[04:54] <aib> ok, supposing i follow the debian new maintainers guide with the ubuntu modifications, what do i then do with my package?
[04:54] <aib> is there a doc describing this? i haven't found one yet
[04:55] <ScottK-laptop> !revu | aib
[04:55] <ScottK-laptop> aib: We also have some special rules about Maintainer.  See https://wiki.ubuntu.com/DebianMaintainerField
[04:56] <ScottK-laptop> And finally:
[04:56] <kees> ah, crap, leonel went offline
[04:56] <ScottK-laptop> !packagingguide
[04:56] <kees> I have the PoC for the JPEG crash -- added it to the clamav test
[04:56] <ScottK-laptop> kees: He'll be back in the morning.
[04:56] <ScottK-laptop> Cool.
[04:57] <ScottK-laptop> kees: Debian needs to patch Etch, can I offer it to them?
[04:57] <aib> ScottK-laptop, thank you very much
[04:58] <ScottK-laptop> kees: Or you could just join #debian-clamav on OFTC and offer it yourself ...
[04:58] <kees> ScottK-laptop: yeah, totally, it's in the upstream bug report: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1266
[04:58] <ScottK-laptop> kees:
[04:58] <ScottK-laptop> OK.
[04:58] <ScottK-laptop> Recursion is fun.
[04:58] <ScottK-laptop> aib: You're welcome.  Thank you for showing up and wanting to contribute to Ubuntu.
[04:59] <ScottK-laptop> kees: sgran is almost certainly asleep right now, but he does read the scrollback.
[05:00] <kees> ScottK-laptop: looks like hardy isn't vulnerable to it
[05:00] <kees> (intrepid was, prior to the patch)
[05:00] <ScottK-laptop> kees: That's what leonel was trying to figure out when he ran out of steam.
[05:01] <ScottK-laptop> kees: Is it not vulnerable or not vulnerable if MaxRecursionLimit (or something similar) is set to a sane value.
[05:02] <kees> ScottK-laptop: oh, good point.
[05:02] <kees> ScottK-laptop: well, I guess I should say "stock install of" ...
[05:02] <aib> i recently ported our software from autotools to cmake as KDE did - has anyone packaged cmake-based software? does their debian generator create standard compliant packages?
[05:02] <ScottK-laptop> aib: All the KDE4 packages in Intrepid and Jaunty are cmake.
[05:03] <aib> as in, `make deb' packages? that would be wonderful but i really doubt it:)
[05:03] <ScottK-laptop> No, not that simple.
[05:04] <ScottK-laptop> Most of the Kubuntu devs are in Europe, so this is not the best time of day, but you can discuss cmake stuff here or in #kubuntu-devel.
[05:30] <ScottK-laptop> Good night all.
[05:31] <ScottK-laptop> aib: You can ask questions here as you have them.  Generally someone here can/will answer.
[05:32] <Hobbsee> night ScottK-laptop
[05:52] <Hobbsee> james_w: wow, that went quickly!
[06:26] <dholbach> good morning
[06:26] <fabrice_sp> morning dholbach
[06:27] <dholbach> hi fabrice_sp
[06:28] <fabrice_sp> dholbach: how are you doing this morning ! :-)
[06:28] <fabrice_sp> ?
[06:29] <dholbach> fabrice_sp: I'm slowly waking up, but I'm good - also very excited about meeting people at UDS
[06:29] <dholbach> fabrice_sp: how are you?
[06:30] <fabrice_sp> fine also, thanks! Preparing for going to work :-)
[06:30] <fabrice_sp> UDS will be huge! :-)
[06:30] <dholbach> yeah
[06:30] <dholbach> fabrice_sp: have a great day!
[06:31] <fabrice_sp> also for you :-)
[06:54] <slytherin> is there any set timeline for a package to get cleared from NEW queue?
[06:55] <Hobbsee> slytherin: not as such
[06:55] <Hobbsee> slytherin: people do have archive days
[06:55] <Hobbsee> but UDS will throw that out, and there are a lot in the queue (and it's not necessarily FIFO)
[06:56] <Hobbsee> which package, and do you need it for something else?
[06:56] <geser> good morning
[06:56] <slytherin> Hobbsee: libhibernate3-java, and I need it to clear at least 3 more DEPWAIT.
[06:57] <slytherin> geser: good morning.
[06:57] <geser> Hi slytherin
[06:57] <iulian> G'morning.
[06:58] <Hobbsee> slytherin: k
[06:59] <slytherin> geser: Just FYI ... if we need to move the jboss related packages to universe, they will all need to be moved together.
[07:01] <Hobbsee> slytherin: what do you need given back?
[07:04] <slytherin> Hobbsee: I will do it myself thanks. :-)
[07:04] <Hobbsee> slytherin: you can?  OK.
[07:06] <Hobbsee> 20 left.  obviously it's getting helped along reasonably quickly
[07:26] <didrocks> morning & Danke Schöne dholbach :)
[07:26] <dholbach> didrocks: :)
[08:51] <slytherin> Hobbsee: I didn't need to give back any packages. they were automatically rebuilt.
[10:03] <eMerzh> someone has time to review http://revu.ubuntuwire.com/details.py?package=sqliteman ? thaaaaanks a lot :)
[10:49] <monomanta> hello... can we haz ScummVM version bump in repositories PLZ?
[10:57] <monomanta> https://bugs.launchpad.net/ubuntu/+source/scummvm/+bug/291591
[10:58] <directhex> coo, scummvm
[11:03] <monomanta> coo?
[11:24] <bmm> I'm online for comments on http://revu.ubuntuwire.com/details.py?package=metalink thanks in advance!
[12:50] <slytherin> Hobbsee: ping
[13:14] <slytherin> geser: Do you mind if I go ahead today with libjogl-java merge? We will sync with Debian once the package in experimental is moved to unstable.
[13:15] <ScottK> slytherin: Why not sync from Experimental?
[13:15] <slytherin> ScottK: Because it is in experimental. :-) And I don't know the reasons.
[13:16] <ScottK> slytherin: OK.  Sounds reasonable.
[13:17] <directhex> moonlight 1.0~beta1 packages ready ^_^
[13:24] <slytherin> ScottK: Current merge will help us move package to universe (license change). Where as if we do a sync from experimental it may solve FTBFS on Sparc. But considering that Sparc is not officially supported architecture I don't think sync is urgent.
[13:29]  * apachelogger waits for JontheEchidna to say "hi" :P
[13:30] <JontheEchidna> aib: Hello there, I heard you needed some assistance with a package using cmake?
[13:30] <ScottK> JontheEchidna: He's also two hours west of us, so I'm guessing still sleeping.
[13:30] <JontheEchidna> makes sense
[14:21] <geser> slytherin: no, I don't mind, go ahead (I'm currently too busy to do it myself)
[14:22] <slytherin> geser: Ok.
[14:23] <slytherin> geser: By the way, now there are only 3 packages (2 in NEW, 1 in DEPWAIT) that need to be available to check if jboss from Debian builds or not.
[14:28] <geser> does the one in DEPWAIT wait on one of those in NEW?
[14:31] <slytherin> geser: yes it does.
[14:32] <slytherin> geser: the package in DEPWAIT is - libhibernate-entitymanager-java, depends on libhibernate-annotations-java which is in NEW
[14:39] <handschuh> isnt libhibernate-annotations-java supposed to be libhibernate-commons-annotations-java ?
[14:48] <slytherin> handschuh: those are two different packages. rmadison is your friend. :-)
[14:51] <handschuh> slytherin: ok .. thanks quite confusing .. the package is somehow bad, I think
[15:04] <slytherin> handschuh: I am not concerned about shape of package at this point. Only getting them built. :-)
[15:31] <lod__> hello, I have a Q.; I'm maintaining custom kernel with IMQ patch for QoS, and using the guide at wiki.ubuntu.com for building custom kernel, but can't find where to change revision numbers for builded kernel, I've looked at debian/rules but can't find it..
[15:32] <dholbach> lod__: try #ubuntu-kernel
[15:34] <lod__> 10x
[15:52] <invaleed> Hallo
[15:55] <allquixotic> Hello MOTUs: I am looking to do an SRU for Intrepid, and have followed the process up to the point where I am requesting the release team to evaluate the report: https://bugs.launchpad.net/ubuntu/+source/libshout/+bug/304843
[16:00] <jdong> allquixotic: that's a main package; you want to subscribe the 'ubuntu-sru' team
[16:00] <jdong> and #ubuntu-devel would be the correct channel to poke if poking were deemed to be necessary
[16:01] <allquixotic> How would I go about subscribing the ubuntu-sru team?
[16:01] <allquixotic> "subscribe someone else"?
[16:01] <allquixotic> nevermind, I've done it.
[16:05] <jdong> cool.
[16:13] <jdong> would someone like to speculate why Phoronix benchmarked ext4 using 4 synthetic FS tools and 12 CPU-bound tasks, such as 3D game FPSes?
[16:13] <jdong> I'm not sure Michael understands that ext4 doesn't run on video cards...
[16:16] <directhex> jdong, michael, bless his little cotton socks, doesn't really get benchmarking
[16:16] <directhex> and i say this despite his test suite being a very clever framework (written in php (!))
[16:16] <jdong> directhex: I think one thing that it DOES show is the variance in his tests
[16:16] <directhex> yes
[16:17] <jdong> directhex: for some reason his gnupg test showed more than 5% difference in performance between the 4 filesystems.
[16:17] <jdong> judging from that I'd consider anything less than a 20% difference in his tests to be statistically insignificant
[16:17] <directhex> jdong, but even when doing a 3d card, he benchmarks ancient games which are ~100% cpu bound on a modern card
[16:18] <jdong> directhex: he also failed to identify even the most basic behavioral characteristics of the 4 filesystems he teste
[16:18] <jdong> d
[16:18] <jdong> i.e. he failed to notice XFS takes 20-200x longer than ext3 and reiserfs respectively to rm -rf a kernel source tree.
[16:18] <directhex> let's not make this a bitching session - but i feel phoronix's benchmarking criteria have always been a little strange
[16:18] <jdong> or that XFS deletes a single 1TB file 20x faster than ext3...
[16:19] <directhex> jdong, running mythtv means you just knows these things instinctively ;)
[16:19] <jdong> directhex: maybe phoronix should run a mythbuntu vs ubuntu 7-zip benchmark.
[16:19] <directhex> jdong, you mock, but.....
[16:20]  * jdong wonders how on earth LZMA compression differed by 4-8 seconds doing a single-file using the 4 different FSes...
[16:21] <jdong> bless his soul for taking all this time to benchmark stuff; I'm not trying to rag on him or discredit his work....
[16:21] <jdong> just this clearly demonstrates more than ever that his results need to be taken with scrutiny.
[16:22] <jorgenpt> jdong: 4-8 seconds to a total of .. what?
[16:22] <jdong> 320 seconds or so
[16:22] <jorgenpt> jdong: Representing that as a percentage is much more telling. :-)
[16:22] <jdong> about 1-2% variation
[16:23] <jdong> http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks&num=7
[16:23] <jdong> more frightening is the last benchmark there
[16:23] <jdong> GNUPG of a 2GB file
[16:24] <jdong> ext3 and ext4 difered by 11 seconds (more than 10%)
[16:24] <jdong> I don't know what settings he used, but on my system GPG for a 2GB file is somewhat CPU-bound...
[16:24] <directhex> jdong, thing is, benchmarking is BORING. it's not as if a little game of quake4 whilst the bench runs matters, right? that's what multi-core is FOR!
[16:25] <rjune> LOL
[16:25] <jdong> ffmpeg also showed a 7% variation for MPEG2 encoding between ext3 and ext4
[16:25] <jdong> I also find that extremely hard to believe
[16:25] <directhex> right, that's my coffee finished. to the motorway!
[16:25] <jdong> ffmpeg's mpeg2 encoder at times is slower than its MPEG4-ASP encoder
[16:41] <RainCT> Is there a PPA or something to try ext4 on Intrepid?
[16:43] <jdong> RainCT: I've got a HOWTO.
[16:44] <RainCT> jdong: cool, URL?
[16:44] <jdong> digging :)
[16:44] <jdong> RainCT: http://ubuntuforums.org/showthread.php?t=973701
[16:45] <jdong> RainCT: FWIW I've been intensively running two systems with ext4dev on stock Intrepid kernels and have not experienced any disk issues YET
[16:45] <jdong> I think it's a *better* idea to grab the ext4 2.6.27 patchset from tytso's kernel.org directory
[16:46] <jdong> but even without it, I'm noticing dramatically better concurrent IO performance, fragmentation behavior, and REALLY IMPROVED small-file-deletion performance using ext4 compared to ext3
[16:46] <hyperair> i wonder how much difference it'd make if you're using ext3 vs ext4 on top of dm-crypt
[16:46] <psusi> jdong: you know I found out recently while working on the defrag package that fsck considers just about any file over 44k to be non-contiguous in it's little report, since any file over that size will have an indirect block which normally would follow the 11th data block
[16:47] <jdong> psusi: not surprised; I measure fragmentation by cold-read throughput
[16:47] <RainCT> jdong: "a better idea" as in it will be faster or as in your computer may not explode? :P
[16:47] <jdong> RainCT: it will be faster and one or two unmount-time potential oopses are fixed.
[16:47] <jdong> RainCT: there is a notable patch that reduces fragmentation in extent allocation behavior
[16:48] <RainCT> alright
[16:48] <jdong> IIRC, for a 4GB fedora torrent limited to 200KB/s download speed, the readback on ext3 went at 8MB/s while on ext4 it went at 25MB/s
[16:48] <jdong> disk is capable of 40MB/s sequential sustained
[16:48] <jdong> on XFS it was shockingly close to that 40MB/s number, upper 30's IIRC
[16:48] <jdong> no preallocation of any type was used
[16:49] <psusi> wow, I was going to say neither ext3 nor 4 look good there then
[16:50] <jdong> psusi: well ext4 is looking *BETTER* and this is without the aforementioned ext4 extent patch
[16:50] <psusi> yea, but even 25 sounds not good
[16:51] <RainCT> jdong: I guess the "turn on not backwards-compatible stuff" point is optional?
[16:52] <psusi> well, not turning on the new features would kind of defeat the point wouldn't it?
[16:52] <RainCT> Well, I think I'll wait. I have / and /boot together, and don't want to mess with the /home partition :P
[16:53] <RainCT> jdong: btw, nice forum sig :P
[16:57]  * invaleed is away (Please give me hug)
[17:28] <eMerzh> Any volonteers to review my package at http://revu.ubuntuwire.com/details.py?package=sqliteman ?  it was previously advocated by DktrKranz ...
[17:58] <hefe_bia> jdong: On the ext4 topic: Is the info on volid vs. blkid from http://ext4.wiki.kernel.org/index.php/Ext4_Howto still valid or valid at all? Is this a problem in real usage?
[17:59] <bddebian> Heya gang
[18:02] <slytherin> somebody please help. What host do I need to use with dput to upload to Ubuntu archives?
[18:04] <Laney> slytherin: upload.ubuntu.com
[18:04] <Laney> afaik
[18:05] <jmarsden|work> dput -H lists the hosts...
[18:05] <Laney> slytherin: https://wiki.ubuntu.com/MOTU/New
[18:07] <ScottK> slytherin: In the default Ubuntu config for dput you shouldn't need to list a host.
[18:07] <slytherin> Laney: Thanks for link.
[18:08] <slytherin> ScottK: got that after reading that wiki page. :-)
[18:09] <ScottK> slytherin: Personally I change that to make sure I have to do dput ubuntu to get to the official archive (I once accidentally uploaded a package intended for a PPA to the archive - and it was in Main and it was during a freeze).
[18:10] <slytherin> ScottK: thanks for advice. I will be careful.
[18:11] <Laney> well at least it was during a freeze
[18:15] <iulian> Hiya bddebian.
[18:15] <bddebian> Hello iulian
[18:22] <ScottK> Laney: No,  It was a 'soft freeze'.  One of the 'please don't upload' ones.
[18:26] <Laney> Oh, that's bad then
[18:27] <ScottK> Yes.  So I'm very careful now.
[18:27] <jdong> ScottK: I do the same
[18:27] <ScottK> By default my dput uploads to a non-existent repo called 'bob'
[18:27] <jdong> my default dput target is invalid
[18:28] <ScottK> If you just unset the target it defaults to Debian ftp-master.
[18:28]  * ScottK uploaded there by mistake too.
[18:28]  * ScottK had to hunt down a DD to do dcut for him.
[18:28] <ScottK> Thus I upload to bob.
[19:01] <bmm> Request for comments: http://revu.ubuntuwire.com/details.py?package=metalink
[19:21] <Aquina> hy
[19:21] <Aquina> Can you please update the Cherokee webserver to its latest version 0.11.x in synaptic?
[19:22] <Aquina> I'm running Xubuntu 8.04. HH and the software availale is of version 0.5.x
[19:41] <handschuh> slytherin: ping
[19:46] <ScottK> !backports | Aquina
[20:16] <Milyardo> <3 ubottu
[20:50] <directhex> hm
[20:50]  * directhex summons a vote
[20:51] <laga> ka-ching
[20:52] <directhex> moon apparently requires cairo 1.8. not a debian problem, but i was hoping for syncability
[20:52] <directhex> do i target experimental (which has it) or make the package build its own static cairo?
[20:52] <directhex> or something else?
[20:53] <pochu> directhex: are you sure you are on the right channel? :)
[20:53] <directhex> pochu, sure. the syncability question matters!
[20:53] <directhex> pochu, or if not, what solution? OOo-style synamic control building?
[20:55] <pochu> directhex: ok, if you can upload to experimental and keep it syncable, I'd go for that
[20:55] <pochu> it won't hit testing anyway ;)
[21:00]  * directhex gives his sponsor the word
[21:05] <RAOF> directhex: Yeah.  Sync from experimental!
[21:38] <Laney> Can anyone spot a problem with this: pbuilder-sid create --othermirror "deb ftp://ftp.uk.debian.org/debian experimental main contrib non-free" - I get "E: Malformed line 1 in source list /etc/apt/sources.list (URI)"
[21:42] <mok0> Laney: looks sane to me. Perhaps it's another line
[21:42] <Laney> Maybe I'll use pbuilder directly
[21:42]  * Laney smites it
[21:42] <RAOF> You've aware that you can just do a pbuilder-experimental create, right?
[21:43] <mok0> Laney: use cowbuilder!
[21:43] <Laney> RAOF: I was not.
[21:43] <RAOF> Experimental is a supported dist for pbuilder-dist; it pulls in sid + experimental.
[21:44] <mok0> cowbuilder is much faster than pbuilder
[21:44] <Laney> RAOF: I'm using pbuilder-dist.new. Let's see if it likes that
[21:45]  * mok0 feels ignored
[21:45] <Laney> mok0: Sorry, I'm not ignoring you. It's just that RAOF is giving me answers that don't require me to learn a new tool :P
[21:45] <mok0> :-) It's more-or-less the same
[21:46] <Laney> is there a cowbuilder-dist?
[21:46] <Laney> "Warning: Unknown distribution «experimental»."
[21:46] <Laney> but it still seems to be doing ok
[21:46] <mok0> Laney: except cowbuilder doesn't need to unpack the tar archive first
[21:46] <Laney> Oh, yeah that takes a couple of seconds
[21:46] <mok0> Laney: it uses a create-on-write filesystem
[21:47] <RAOF> Can you make cowdancer build on a tmpfs?
[21:47] <Laney> mok0: Does it implement pbuilder's interface, roughly?
[21:47] <mok0> RAOF: I haven't tried
[21:47] <Laney> Oh, that's the point of cowbuilder. I see.
[21:47] <mok0> Laney: yes, it's almost the same, except for one option
[21:48] <mok0> Laney: you need to specify --base-dir instead of --base-tgz
[21:48] <RAOF> Because that's the biggest pbuilder optimisation I've seen.  As long as I don't try to build something that saps too much memory ;).
[21:48] <Laney> I should get around to fixing my schroots to use a local apt cache.
[21:49]  * RAOF used squid for that.
[21:50] <RAOF> Cool.  So, xserver-xorg-video-nouveau builds (and works) with unmodified Jaunty libdrm.
[21:50] <mok0> http://wiki.debian.org/cowbuilder
[21:50] <mok0> https://wiki.ubuntu.com/CowdancerHowto
[21:51] <RAOF> Time to update experimental's nouveau snapshot, polish the dkms nouveau-kernel package, and get some review.
[21:51] <ajmitch> RAOF: great, is it useful?
[21:52] <Laney> mok0: Maybe you could port pbuilder-dist{.new} in ubuntu-dev-tools to cowbuilder? ;)
[21:52] <Laney> {,.new}*
[21:52] <RAOF> ajmitch: Depends on what you want.  If you want 3d, no.  If you want fast, featureful 2d, yes.
[21:52] <ajmitch> RAOF: of course I need 3D :)
[21:52] <mok0> Laney: It wouldn't be a huge project... I've just made my own little script
[21:53] <Laney> I imagine it would mostly be s/pbuilder/cowbuilder/
[21:53] <mok0> Laney: yeah
[21:53] <RAOF> ajmitch: Nouveau's 3d got merged into the main mesa repository, so it's getting a little more love; you could try that :)
[21:54] <Laney> RAOF: pbuilder-experimental works. Win!
[21:54] <mok0> \O//
[21:56] <mok0> Have any of you tried adopting an orphaned Debian package?
[21:56] <ajmitch> RAOF: so in 12 months I can play WoW? :)
[21:58] <RAOF> Concievably ;)
[21:59] <ajmitch> I expect there'll still be a lot of work to do
[21:59] <RAOF> In 12 months time?  Probably.
[21:59] <RAOF> Gah.  New mesa won't build because we don't enable dri2 in X.
[22:00] <RAOF> Or maybe because we have an obsolete dri2-proto.  Who knows.
[22:01] <quadrispro> hi RainCT
[22:25] <mok0> heh, I did it...
[22:28]  * ScottK-laptop wonders if he should ask ...
[22:32]  * handschuh nods
[22:33] <Laney> Gah
[22:33] <Laney> http://pastebin.ubuntu.com/80042/ <- when doing pbuilder-experimental create
[22:33]  * Laney headdesks
[22:34] <Laney> directhex: How do you testbuild mono stuff? :(
[22:43] <RAOF> Laney: Hm.  Mine Just Worked(tm).  I don't suppose sid+experimental is broken atm?
[22:43] <Laney> I guess so
[22:57] <directhex> Laney, test things in experimental? i had to tweak my pbuilder to pin experimental to the same as sid
[23:13] <Hobbsee> slytherin: contentless pong?
[23:13] <Hobbsee> slytherin: and cool