[00:28] <Bluefoxicy> why oh why is the 32-bit desktop/live DVD 1.5 gigs and the 64-bit 700 megs?
[00:29] <stgraber> Bluefoxicy: where are you looking? I see i386 at 1.5GB and amd64 at 1.6GB here
[00:31] <Bluefoxicy> cdimage.ubuntu.com/releases/precise/release
[00:32] <stgraber> right, same place I'm looking at :)
[00:32] <Bluefoxicy> Where is the 700MB i386 @_@
[00:33] <stgraber> on releases.ubuntu.com
[00:34] <Bluefoxicy> silly me
[02:54] <psusi> this bug report has a script error on line 11 saying splash not found... I noticed that the double quotes around "quiet splash" appear to be slanted... what's up with that? https://launchpadlibrarian.net/105554324/EtcDefaultGrub.txt
[02:54] <psusi> I didn't think there was such a thing, but they appear different than the rest of the quotes in the file, and based on the error message about splash not found, it seems like the shell is treating those funny double quotes like backticks and trying to execute the contents
[02:56] <psusi> is there such a thing as slanty double quotes that the shell interprets like backticks?
[02:56] <lifeless> psusi: they are unicode quotes, not ascii
[02:56] <infinity> psusi: Looks like someone's edited that in a fancy editor or word processor that wanted to use the unicode quotation marks instead of just using the ascii.
[02:56] <lifeless> someone has messed the file up
[02:57] <lifeless> the bug therefor is arguably that there is no vigrub command to detect such issues
[02:57] <StevenK> vigrub is a slippery slope
[03:00] <psusi> weird... yea, looked it up, unicode U+201D, right quotes
[03:01] <psusi> but I didn't know bash had special interpretation for that...
[05:02] <scientes> hmm the ubuntu code of conduct page wont accept a signed debian diversity statement....
[05:06] <lifeless> scientes: why would it ?
[05:41] <pitti> Good morning
[05:41] <ajmitch> morning pitti
[05:41] <pitti> infinity: no, I didn't dump any component-specific ddebs
[05:42] <pitti> infinity: ddeb-retriever doesn't care about Sources.gz, it only looks at Packages.gz; so the main/universe split source packages shouldn't matter
[05:42] <pitti> hey ajmitch, how are you?
[05:44] <ajmitch> pitti: good, how are you today?
[05:44] <pitti> I'm quite well, thanks! we had a nice weekend, and you?
[05:45] <ajmitch> a nice, uneventful weekend where I mostly got over the ubuflu (still) :)
[05:47] <pitti> ajmitch: argh; mine is mostly gone, too
[05:59] <angeloc> pitti: thank you for approving my fix!
[05:59] <pitti> @pilot in
[05:59] <pitti> hey angeloc, thanks for spotting this
[05:59] <pitti> angeloc: uploaded to Debian and Ubuntu now
[06:00] <micahg> hi pitti, happy piloting
[06:00] <pitti> thanks micahg
[06:00] <angeloc> pitti, i'm porting quickly to qt4 and qtquick and i spotted a wrong dependency in the building process!
[06:01] <angeloc> pitti: can I ask you help with bug 993867?
[06:01] <angeloc> pitti, i'm looking for sponshorship
[06:02] <pitti> angeloc: urgh, there are still packages out there which speak esound?
[06:02] <angeloc> pitti, xoscope is really an ancient package! it' uses esound compat to talk to pulseaudio
[06:03] <angeloc> pitti, so in the end it uses pulseaudio
[06:03] <pitti> angeloc: yes, I mean protocol wise
[06:03] <pitti> angeloc: you set up an SRU description, so I'll upload to quantal and precise-proposed
[06:03] <pitti> ok?
[06:04] <angeloc> pitti, yes, i'm investigating rewriting the software for pulseaudio, but the code is quite difficult to understand
[06:04] <pitti> angeloc: BTW, if you want to do package fixes regularly, can you please add corresponding changelog entries? (dch is a nice tool for that)
[06:04] <angeloc> pitti, yes, i can really enjoin the bug will be fixed also in precise
[06:04] <angeloc> pitti, i'm new in sru process, so please be patient!
[06:05] <pitti> angeloc: oh, changelogs are not SRU speciifc
[06:05] <pitti> angeloc: anyway, I'll add it for you
[06:05] <pitti> angeloc: do you know how to forward a fix to Debian?
[06:05] <angeloc> pitti, weel no, i fixed another bug in xoscope and i think that debian will benefit both
[06:06] <angeloc> pitti, i'm intrested in learning the sru process, can I fix the branch myself?
[06:06] <pitti> angeloc: there is nothing to fix for the SRU part
[06:06] <angeloc> pitti, adding a changelog i mean
[06:06] <pitti> angeloc: oh, sure
[06:06] <pitti> angeloc: use "dch", document the change, and then use "debcommit" to commit that change; then push again
[06:07]  * pitti reverts his local changelog and waits for your's
[06:08] <angeloc> pitti, i have to use -i flag to increase version number right?
[06:08] <pitti> angeloc: FYI, https://wiki.ubuntu.com/Debian/Bugs has the documentation how to forward bugs to Debian
[06:08] <pitti> angeloc: ah, that could be; I have configured dch to do that automatically for ages, so I forgot about it
[06:09] <angeloc> pitti, yes i read the documentation, but using debian bug tracking is really a pain
[06:09] <pitti> angeloc: either way, it needs to create a new changelog record, not append to the already existing one
[06:10] <angeloc> pitti, last changelog entry shows debian/patches/99-esd_pa_fixes.patch, this time i have no a patch like this, i'll have to create one?
[06:10] <pitti> angeloc: if you modify the source, yes; you can't modify it directly
[06:11] <pitti> angeloc: since you are working on another change, I propose I'll wait for that with the upload instead of uploading twice?
[06:12] <angeloc> pitti, cannot understand, i branched quantal/xoscope and fixed debian/changelog, which step i have to do now? making a debian patch?
[06:13] <angeloc> pitti, i have only one patch
[06:13] <pitti> angeloc: err, wait; what are we talking about now?
[06:13] <pitti> angeloc: adding the missing changelog entry for your esound-compat addition, or the other fix you said you were working on?
[06:14] <pitti> angeloc: you don't want to add the changelog entry to quantal/xoscope, but to lp:~angeloc/ubuntu/quantal/xoscope/fix-for-993867
[06:14] <angeloc> pitti, there is only a patch for xoscope now (esd-compat), the other patch was accepted in precise at least five moths ago
[06:14] <pitti> angeloc: ah; this has nothing to do with debian/patches/ then
[06:15] <pitti> angeloc: just do dch -i, describe the change, and debcommit/bzr push that to your branch
[06:15] <angeloc> pitti, ok, but for the least patch i made, a patch pilot like you created debian/patches/99-esd_pa_fixes.patch, i have to creat one for this patch right now?
[06:16] <pitti> angeloc: why do you need a patch? You only add the dependency, you don't change any source code
[06:16] <angeloc> pitti, ok, that's right! adding changelog with dhc ...
[06:21] <angeloc> pitti, done
[06:30] <pitti> angeloc: uploaded to quantal and precise-proposed, thanks!
[06:30] <angeloc> pitti, wow!
[06:30] <pitti> angeloc: note that the -proposed upload will hang in a review queue and needs to be accepted by the SRU team first
[06:30] <angeloc> pitti, yes, i know
[06:44] <krinetic> found a bug: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1002152
[07:00] <dholbach> good morning
[07:10]  * micahg thinks he'll wait for the morning to upload gimp in case something breaks
[07:12] <dholbach> micahg, the desktop team will have a couple of hours to fix it if it does :)
[07:12] <micahg> dholbach: I'm sure they have enough work to do :)
[07:13] <micahg> and they don't officially support it anyways
[07:13] <micahg> s/officially/actively/
[07:14] <dholbach> right, I guess it is mostly updates and merges
[07:16] <micahg> in fact, the -desktop branch is no longer the main branch, lp:ubuntu/gimp is
[07:19] <dholbach> geser, do you already have a wiki page with your core dev application up? I'd like to add my endorsement to it :)
[07:23]  * micahg misses doko...
[08:34] <pitti> tseliot: good morning
[08:34] <dupondje> Could somebody review https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/937522 for me? Its been open some time now :)
[08:35] <pitti> tseliot: should nvidia-current and friends depend on nvidia-common? (or soon ubuntu-drivers-common)
[08:36] <pitti> dupondje: can you please forward this to upstream?
[08:36] <pitti> dupondje: I can review it then
[08:37] <dupondje> pitti: its commited upstream already
[08:37] <pitti> oh, nice
[08:38] <dupondje> Tested it some time, made a ppa version of it also to let other people test it :)
[08:38] <pitti> dupondje: sponsoring now, thanks!
[08:39] <dupondje> great!
[08:39] <tseliot> pitti: good morning to you. Yes, it's probably a good idea to make it depend on nvidia-common
[08:40] <pitti> tseliot: I'm asking because presumably the postinsts should set/update the alternatives?
[08:40] <tseliot> pitti: the postinst of the nvidia drivers already do that
[08:41] <pitti> also, the packages should conflict to each other, to prevent that you install multiple versions at the same time and then don't know which one actually gets used?
[08:41] <tseliot> pitti: shouldn't the driver manager tell you that?
[08:42] <tseliot> i.e. jockey or whatever replaces it
[08:42] <pitti> tseliot: yes, but only if you actually use that
[08:42] <dupondje> pitti: SRU it also or not important enough?
[08:42] <vibhav> good morning
[08:42] <pitti> tseliot: if you install it in software-center or via apt, there won't be anything to update them
[08:42] <pitti> dupondje: your call; sounds fine to me for an SRU
[08:42] <tseliot> pitti: the only way to know for sure is to call update-alternatives
[08:43] <pitti> tseliot: is there any chance we could drop the alternatives? they have caused us so much trouble, with packages not working or failing to install, etc.
[08:43] <pitti> we get bug reports to no end
[08:43] <dupondje> pitti: SRU then :) clipboard is a good to have thing :)
[08:44] <tseliot> pitti: no, I don't think so. Diversions were even worse...
[08:44]  * tseliot still has nightmares about diversions...
[08:44] <pitti> dupondje: done
[08:45] <dupondje> thcx
[08:45] <pitti> tseliot: I'd like to start on implementing the spec now, with renaming the package and adding the packagekit/aptdaemon plugins
[08:45] <dupondje> now lets fix the other 100 bugs in Remmina :P
[08:45] <pitti> tseliot: do you keep this in a particular Vcs, or just lp:ubuntu/nvidia-common?
[08:46] <tseliot> pitti: there's a git repository. Let me check if it's updated
[08:47] <infinity> pitti: Weird, then, that I can find ddebs for libc6, but not nscd, despite the build log showing nscd.ddeb being genrated.
[08:47] <pitti> infinity: indeed, neither for any other version.. http://ddebs.ubuntu.com/pool/universe/e/eglibc/
[08:48] <tseliot> pitti: here it is: https://github.com/tseliot/nvidia-common
[08:49] <seb128> infinity, pitti: not sure but could it be that the ddeb retriever doesn't like sources with binary in both main and universe? I think I saw issue with those before
[08:50] <pitti> seb128, infinity: it's not inherently built to ignore those (it doesn't consider Sources.gz), but there might very well be a bug there
[08:51] <pitti> but AFAIR we soon want to switch it to fetching ddebs from launchpad instead of the http servers, so I won't bother debugging this now
[08:51] <seb128> \o/
[08:51] <seb128> (on fetching ddebs from launchpad)
[08:53] <pitti> tseliot: can you rename projects in github, or only create a new one and delete the old?
[08:53] <infinity> pitti: Yeah, remind me on Tuesday (I have Monday off) to get back to testing the current state of ddebs in LP.
[08:53]  * pitti reminds infinity that it is Monday
[08:54] <infinity> Only barely, for me. :P
[08:55] <tseliot> pitti: it seems that I can rename it
[08:56] <tseliot> pitti: shall I rename it as ubuntu-drivers-common?
[08:56] <pitti> tseliot: if you don't mind
[08:56] <tseliot> ok
[08:56] <pitti> tseliot: grazie!
[08:57] <tseliot> pitti: di niente ;)
[08:58] <tseliot> pitti: https://github.com/tseliot/ubuntu-drivers-common
[08:59]  * pitti forks
[08:59] <tseliot> pitti: I'll have to port all of the code to python 3 (it should be trivial to do) and finally upload xkit's python 3 port (since nvidia-common depends on it)
[09:00] <tseliot> pitti: if need these ASAP, just let me know and I'll focus on them
[09:00] <pitti> tseliot: not that urgent; I'll make sure that the new code (jockey replacement) works with 3
[09:01] <tseliot> pitti: ok
[09:12] <pitti> tseliot: hm, AFAICS the "nvidia-common" script is not installed anywhere; is that a bug, or is it just obsolete?
[09:12] <pitti> tseliot: the one which calls nvidia-detector and shows the "obsolete-driver" debconf note
[09:13] <tseliot> pitti: the debconf interface is disabled and, from what I can see, we don't shipt that script any more. Feel free to remove it
[09:13] <pitti> ok
[09:14] <pitti> tseliot: I'll leave it for now with the nvidia -> ubuntu-drivers renaming, I was just wondering whether I was missing something
[09:14] <tseliot> pitti: ah, ok. we can remove it later
[10:15] <tkamppeter> Do we have some libusb expert around here?
[10:34] <cjwatson> tseliot: did I remember to push my python3 branch of x-kit, or were you working on it independently?
[10:35] <tseliot> cjwatson: I ported xkit to python 3 some time ago (and cleaned up the API) but I couldn't upload it
[10:36] <cjwatson> ah, it wasn't even in bzr anywhere visible when I looked
[10:36] <tseliot> cjwatson: I guess it's a good time to fix the packaging and uploading it in quantal. I guess I'll have to provide python2.x libraries for the apps that still depend on it
[10:36] <tseliot> cjwatson: no, sorry, it's in a local branch of mine
[10:36] <cjwatson> my branch is lp:~cjwatson/xorgparser/python3 if that's of any interest; the same code should work in both 2 and 3 so providing libraries for both would be trivial
[10:37] <tseliot> cjwatson: ok, thanks, I'll have a look at it
[10:59] <pitti> tseliot: btw, the renaming is already in https://github.com/martinpitt/ubuntu-drivers-common , in case that's blocking you
[11:03] <tkamppeter> pitti, do you know a libusb expert at Ubuntu?
[11:03] <pitti> tkamppeter: I don't, I would have told you otherwise
[11:05] <tkamppeter> pitti, so all USB expertise needed to make up Ubuntu is in the upstream projects?
[11:06] <pitti> for libusb, apparently so
[11:11] <pitti> geser: hm, your pcsc-lite merge is uninstallable due to libccid not existing; ccid FTBFSed
[11:11] <pitti> geser: did you try this with a local build?
[11:12] <pitti> I opportunistically retried the ccid build now
[11:14] <geser> pitti: I test-build my pcsc-lite merge, but didn't checked the dependencies. ccid should build now, as that the reason I did the pcsc-lite merge
[11:16] <geser> pitti: looks like I've to file a MIR for ccid as pcscd is in main
[11:18] <pitti> ah great, ccid built
[11:20] <pitti> geser: danke
[11:44] <xnox> Laney: updated the tracker for python3 only on cd, please pull /dima =)))) into correct branch ;-)
[11:45] <xnox> is lp:ubuntu/mountall the upstream of the mountall package?
[11:47] <Laney> I saw, will look soon
[11:53] <Laney> xnox: is there no is_bad you can have?
[11:54] <Laney> did I ask this before ... feeling a déjà vu
[11:54] <xnox> Laney: I wish. Most source packages are converted to generate: python2-module and python3-module. And then both is_good .depends python3 & is_bad .depends python2.
[11:55] <Laney> i see
[11:55] <xnox> Laney: I'm not sure if somehow it is possible to 'force' is_good to take presedence over is_bad, if both return true.
[11:56] <Laney> nah, no need
[11:56] <xnox> Laney: it's ~good enough (tm)
[11:56] <tseliot> pitti: ok, thanks, I'll merge your changes
[11:57] <Laney> pushd
[11:57] <tseliot> pitti: actually, can you make a pull request from github, please?
[12:00] <geser> BenC: Hi, I hope you don't mind when I merged libzen. But as I can't test if your libzen.symbols.powerpc file is now obsolete or needs an update, could you take a look at https://launchpadlibrarian.net/105579169/buildlog_ubuntu-quantal-powerpc.libzen_0.4.26-1ubuntu1_FAILEDTOBUILD.txt.gz
[12:09] <pitti> tseliot: sorry, was at lunch
[12:10] <pitti> tseliot: can do; I verified that the package builds, but I haven't tested it with jockey or installing drivers yet, as I don't have a any nvidia/ati machine
[12:10] <tseliot> pitti: fair enough, we don't have to upload it now
[12:13] <pitti> tseliot: https://github.com/tseliot/ubuntu-drivers-common/pull/1
[12:13] <tseliot> thanks
[12:13] <pitti> tseliot: the rest should not be so intrusive, mainly adding files
[12:14] <tseliot> pitti: pulled, thanks
[12:14] <tseliot> ok
[12:15] <tseliot> cjwatson: I'm applying your changes for xkit, especially the ones to the test suite. Thanks again
[12:19] <cjwatson> tseliot: great, thanks
[12:26] <jdstrand> barry: hi! is there some sort of tag to use for things being ported to python3?
[12:49] <vibhav> jtaylor: ping
[12:58] <vibhav> I have created an SRU for eggdrop at https://bugs.launchpad.net/ubuntu/+source/eggdrop/+bug/885329 , can somebody check it?
[13:03] <jamespage> @pilot in
[13:08] <vibhav> Can https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385 be nominated for precise?
[13:09] <pitti> @pilot out
[13:15]  * dholbach hugs pitti and jamespage
[13:15] <vibhav> aww
[13:19] <Laney> jtaylor: weren't you looking at eggdrop? ^
[13:21] <seb128> Laney, vibhav: there is an eggdrop SRU in the precise queue
[13:21] <seb128> http://launchpadlibrarian.net/105631901/eggdrop_1.6.19-1.2ubuntu3.1_source.changes
[13:21] <Laney> is it from jtaylor?
[13:21] <Laney> yeah.
[13:22] <Laney> looks like it's taken care of then
[13:22] <seb128> oneiric has one as well
[13:25] <vibhav> ah fine
[13:26] <vibhav> jamespage: Are you busy?
[13:27] <jamespage> vibhav, I'm available for piloting duties!
[13:27] <jamespage> want me to take a look at that munin bug?
[13:28] <vibhav> yeah
[13:29] <vibhav> I also attached a debdiff for quantal
[13:29] <vibhav> You might want to check it too :)
[13:30] <jamespage> vibhav, ack - I think I spotted another SRU candidate for munin last week - looking at your debdiff now
[13:35] <vibhav> the correct debdiff is at #6
[13:44] <vibhav> jamespage: How is the debdiff?
[13:45] <jamespage> vibhav, looks good - just sweeping in the other change as well
[13:45] <zyga> ivanka: wow, are you back?
[13:46] <vibhav> jamespage: Could you link me to the revised debdiff?
[13:52] <jamespage> vibhav, http://paste.ubuntu.com/999058/
[13:54] <jamespage> vibhav, patch was fine - but was missing from series file...
[14:09] <jbicha> cjwatson: are there useful docs for how to build live CDs from a new packageset?
[14:10] <jbicha> I found this guide which works ok for getting to that point https://docs.google.com/document/d/1RPPF14h1Sw2gQjGTuZjUIlNHnGrafS8ekhFjJM9MT00/edit
[14:12] <cjwatson> jbicha: almost certainly not
[14:12] <cjwatson> jbicha: you could go straight to the live-build documentation though and DIY
[14:12] <vibhav> jamespage: thanks!
[14:12] <cjwatson> live-build's docs are fairly decent, depending on how consistent you want to be with the Ubuntu defaults; for that you need to RTFS in livecd-rootfs (live-build/auto/*)
[14:13] <vibhav> jamespage: jamespage Do you want to to work on an SRU?
[14:13] <vibhav> a*
[14:14] <barry> jdstrand: re: tag for py3 ports... not yet
[14:14] <jamespage> vibhav, ultimately yes - would you have time to pickup detailing the SRU in the bug report?
[14:15] <vibhav> yeah
[14:16] <jbicha> I'd like my build to be as close to Ubuntu default as possible as I'd like to eventually get an official "gnomebuntu" flavor
[14:22] <vibhav> jamespage: I dont know the steps to reproduce
[14:36] <vibhav> jamespage: Any specific regression potential for https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678 ?
[14:36] <jamespage> vibhav, no - not really
[14:36] <jamespage> it broken as it stands ATM
[14:45] <didrocks> bdmurray: hey, can you add popey to the ubuntu bug control team? He filed quite some bugs in the past (too many of them to my taste :p) and we can use some triagin from in on the unity side ;)
[14:46] <ogra_> popey is unity dev now ? wow :)
[14:47] <bdmurray> didrocks: sure, I'll add him now
[14:47] <didrocks> bdmurray: thanks :)
[15:07] <vibhav> jamespage: ping
[15:10] <vibhav> jamespage: done, https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678/comments/8
[15:11] <dholbach> xnox, I just saw that I got a work item here https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-more-agile-sru-process - you mentioned it to me at UDS but we found a different solution afterwards
[15:11] <dholbach> xnox, can I assign it back to you? (I wasn't even at the session)
[15:13] <Laney> is that really the best use of their time?
[15:13] <xnox> dholbach: was the 'different solution' in actual fact the first workitem - as in it should be community led sru-team that is to be revived?
[15:14] <xnox> and hence that work-item got obsoleted due to post-session discussions?
[15:14]  * Laney would like that more :-) (there's plenty of /patch piloting/ that can be done without upload rights)
[15:14] <dholbach> no, I said I'd be happy to share the scripts I use for scheduling piloting sessions, but that I won't have time this cycle to schedule another bunch of piloting slots (and stay on top of the queue, etc etc)
[15:16] <xnox> dholbach: true. there was another person asking for those scripts (apart from/in addition to) me
[15:16] <xnox> was it balloons?
[15:16] <dholbach> I don't know
[15:16]  * vibhav sits in the corner and waits for jamespage 
[15:16] <seb128> dholbach, xnox, infinity: you probably want to drop the [all] in the workitems section, ~all is an old unactivated lauchpad account it seems, probably not what you want
[15:16] <dholbach> in any case I'm happy to send them over to you
[15:17] <jamespage> vibhav, sorry - was just dealing with something else
[15:17] <dholbach> seb128, I wasn't even in that session :)
[15:17] <dholbach> seb128, but it's good to know :)
[15:17] <seb128> ;-)
[15:17] <vibhav> jamespage: So could you check the SRU debdiff?
[15:17] <jamespage> vibhav, in the next 30 mins yes
[15:18] <vibhav> thanks!
[15:19] <xnox> dholbach: ok.
[15:19] <dholbach> thanks xnox
[15:20] <xnox> seb128: and infinity is not in today as far as I remember or something.
[15:20] <dholbach> xnox, sent
[15:20] <seb128> xnox, right, he will read the scrollbars I guess
[15:20] <seb128> or at least look for highlights ;-)
[15:21] <ogra_> (and being pinged by seb128 is always a highlight !)
[15:21]  * xnox *giggles*
[15:21] <zyga> hey, has anyone seen gustavo niemeyer today?
[15:22] <seb128> ogra_, well, infinity said something about never trusting the frenchs again recently so I'm careful ;-)
[15:22] <ogra_> haha
[15:22] <ogra_> zyga, not on freenode (hint)
[15:22] <zyga> ogra_: ah, thanks
[15:26] <Bluefoxicy> that's hilarious.
[15:26] <Bluefoxicy> you can install IcedTea Java WebStart
[15:27] <Bluefoxicy> in Precise
[15:27] <Bluefoxicy> pull up Software Center, punch in Java, install Java WebStart.
[15:27] <Bluefoxicy> it doesn't WORK
[15:27] <Bluefoxicy> ... because it really doesn't care if you don't have a JRE installed
[15:27] <Bluefoxicy> No questions asked, here's javaws, go wild
[15:28]  * Bluefoxicy assumes it 'suggests' or 'recommends' some kind of Java but doesn't depend on it
[15:31] <Bluefoxicy> oh.  That's why this doesn't work.
[15:31] <Bluefoxicy> it installes icedtea-netx-common
[15:31] <Bluefoxicy> but doesn't friggin' install icedtea-netx
[15:32] <Bluefoxicy> so Software Center can't install Webstart at all
[15:32] <jamespage> vibhav, the changes are fine but the changelog is going to need alot more detail
[15:32] <jamespage> quote 'a detailed and user-readable changelog'
[15:33] <vibhav> jamespage: Like?
[15:35] <Laney> Describe the bug your patch fixes in easily readble terms
[15:35] <shbk> hello! I want to use linux   man for getting information about C++ functions. For example I can do  "man printf"  and I get info. For this purpose I installed    libstdc++6-4.4-doc . I try to do "man cout, man std::cout" - but not‌hing.  How can I use man to get info about   "cout, new , etc" ?Thanks
[15:36] <jamespage> vibhav, http://paste.ubuntu.com/999223/
[15:36] <jamespage> I try to cover off - a) what is being fixed, b) how and c) the source
[15:37] <Daviey> jamespage: Can you write my changelogs for me aswell please?
[15:37] <jamespage> this information is obviously in the patch headers as well but it makes it easier for the SRU team to review
[15:38] <jamespage> Daviey: :-)
[15:38] <vibhav> heh
[15:41] <vibhav> jamespage: https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678/comments/9
[15:42] <jamespage> vibhav, OK - leave it with me - I need to review the information in the bug reports as well
[15:45] <xnox> brain damage of the day: bug 1002357
[15:46] <cjwatson> shbk: man will only show things that somebody's written manual pages for; I've never seen manual pages for the basic C++ runtime
[15:50] <Bluefoxicy> Okay, serious question.
[15:50] <shbk> I hoped that someone has written for the C++
[15:50] <Bluefoxicy> Anyone on Precise, punch in 'dmesg | grep Yama' in a terminal
[15:50] <Bluefoxicy> and please explain
[15:51]  * Bluefoxicy is trying to make Wubi boot in VirtualBox with no success, just spotted this along the way
[15:52]  * vibhav hugs jamespage 
[15:53] <cjwatson> shbk: some googling suggests manpages-cpp (not packaged AFAICS) or ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/libstdc++-man.4.4.0.tar.bz2
[15:53] <cjwatson> though the latter at least doesn't have a page for cout
[15:55] <xnox> Bluefoxicy: http://lwn.net/Articles/393012/
[15:59] <Bluefoxicy> xnox:  ah ok.  Was just amusing, and funny.  Yama is japanese for Mountain, and also king of the spirit world.
[16:01] <xnox> Bluefoxicy: je ne parle pas japonais
[16:01] <Bluefoxicy> xnox:  It looked like a joke :p  Yama:  Becoming mindful ... i.e. meditating buddhist god
[16:02] <cjwatson> many names of free software programs started as jokes at some point
[16:02] <Bluefoxicy> wubi == security blanket
[16:03] <cjwatson> I think that one may be coincidence
[16:05] <Bluefoxicy> So anyway has anyone else tried installing icedtea web start through Software Center in precise and found you only get icedtea-netx-common and not icedtea-netx?
[16:05] <Bluefoxicy> or is this just me?
[16:43] <jono> does anyone know if the PySide Qt bindings are in Precise?
[16:44] <tumbleweed> should be
[16:49] <jdstrand> barry: thanks. one other question. assuming I am able to get the source for a package to work with either python2 or python3, would I be able to have a single binary that could be installed with either? eg, ufw on the desktop works with python3, but ufw on the server works with python2
[16:50] <jdstrand> barry: but it is the same binary (obviously installing all the /usr/lib/python*/dist-packages/ufw/* bits for both 2.7 and 3.2)
[16:52] <cjwatson> why shouldn't ufw on the server be made to work with python3?
[16:52] <jdstrand> cjwatson: it very well can. I didn't know if python3 would necessarily be on the server (or minimal, etc)
[16:52] <cjwatson> any given binary has to have one or the other in its #! line
[16:52] <cjwatson> you can preprocess it of course to use a different one, but that'd mean two packages just for the binary
[16:53] <jdstrand> I would like to avoid two packages for the binary
[16:53] <cjwatson> I suspect we're going to end up converting server bits as a result of converting desktop bits
[16:53] <jdstrand> I am currentyly using /usr/bin/python
[16:54] <jdstrand> so in that regard it should all just work. I just wanted to make sure there wasn't some packaging requirement that I must have 2 binaries if I am to support both python2 and python3 (it wasn't clear to me from the blog entries barry did)
[16:55] <cjwatson> I believe our general plan is that most modules ought to support both for a period, but binaries should pick one
[16:55] <cjwatson> er, programs
[16:55] <jdstrand> cjwatson: it might just be an answer to this question: will python3 be on the server cd?
[16:56] <cjwatson> it will be exceedingly difficult, if not downright impossible, to meet the goal of having only python3 on the desktop CD without also having python3 on the server CD
[16:56] <jdstrand> (as upstream, I want to support 2.6 and higher (at least), but as the package for Ubuntu/Debian, I can choose)
[16:56] <cjwatson> you might as well assume it'll be there
[16:57] <jdstrand> ok
[16:57] <jdstrand> if it isn't, we can revisit
[16:57] <jdstrand> cjwatson: thanks
[16:57] <jdstrand> barry: cjwatson fielded my question
[16:58]  * Daviey doesn't expect server's largest consumer of python (openstack) to be py3 compliant this cycle.
[16:58]  * jdstrand remembered something about that
[16:59] <cjwatson> Then you are likely to end up with both, I'm afraid
[16:59] <Daviey> i suspect for this cycle, that makes sense.
[16:59] <cjwatson> There's enough stuff in the core that uses Python that it's not practical for us to permit flavours to choose entirely-python2 vs. entirely-python3
[16:59] <Daviey> agreed
[17:00] <dobey> i suspect we won't be able to make it to 100% py3 this cycle, though maybe close to 80-90%
[17:06] <jamespage> vibhav, just uploaded you munin change to precise-proposed  - also added some extra info to the SRU information (mainly around how to freeze messages to generate the graph error)
[17:06] <vibhav> thanks!
[17:07] <vibhav> good night
[17:08] <jamespage> @pilot out
[17:08] <jamespage> ttfn
[18:01] <bdmurray> any ideas what would add independent to /etc/apt/sources.list? bug 947296
[18:03] <slangasek> no ideas here
[18:04] <stgraber> bdmurray: independent is the name used by software-center for extras.ubuntu.com, not sure if that makes that bug report any clearer though
[18:06] <bdmurray> stgraber: hmm, thanks
[19:37] <dupondje> https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication => Still some endorsments wanted ! :)
[19:51] <Bluefoxicy> http://img818.imageshack.us/img818/2163/screenshotfrom201205211.png is this a bug?
[20:02] <bdmurray> is there any launchpadlib api code for copying ppa builds to ther series?
[20:07] <maxb> Yes, syncSource
[20:08] <Laney> itym copyPackage
[20:09] <maxb> Laney: I like my errors synchronously, thanks :-p
[20:19] <bdmurray> ah, I meant a handy tool using the launchpad api not what do I need to use in the api to do it
[21:54] <melodie_> gn
[22:02] <robert_ancell> @pilot in
[22:53] <xnox> How does udev order rules? If there is both 65-foo.rules and 85-foo.rules with matching actions 1) does only the first one run 2) both are run A) in ascending order B) in descending order
[22:55] <slangasek> xnox: 2A)
[22:55] <slangasek> (TTBOMK)
[22:56] <xnox> slangasek: thank you. I'm done with Bug #1002357 and now thinking about migration paths & what to do with people who overriden alter-ego rules files.
[22:59] <slangasek> xnox: are these installed in /etc/udev/rules.d, or /lib/udev/rules.d?
[23:01] <xnox> slangasek: in the .deb there is /lib/udev/rules.d/[65|85]*.rules in the .udeb there is /[etc|lib]/udev/rules.d/*.rules
[23:01] <slangasek> hmm, interesting
[23:01] <xnox> .udeb should be ok, no migration path
[23:01] <slangasek> right
[23:02] <xnox> but the 65/85 becoming a better 64 might need magic to purge from /etc/udev/rules.d/, but that may end-up in droping user config
[23:02] <slangasek> xnox: so I understand from kees that one of the consequences of this is that we do actually have incremental mode enabled even though Debian doesn't - right?
[23:02] <xnox> true
[23:02] <slangasek> well, unless there's a version of the package that shipped the rules under /etc, I don't think we need to worry about migrations there
[23:03] <xnox> ok. But if users customized 65/85 will their config get dropped or still applied on top of ours?
[23:03] <kees> if a rule exists in /etc it is ignored in /lib
[23:04] <kees> (but have exactly the same filename)
[23:04] <slangasek> correct... but if they're under different filenames, which order are they applied in?
[23:04] <slangasek> are they interleaved by number?
[23:04] <kees> both are merged into lexical order
[23:04]  * slangasek nods
[23:04] <xnox> I was thinking to rename /etc/[65|85
[23:05] <xnox> ] to *.rules.dpkg-disabled
[23:05] <slangasek> I wouldn't, if those files have never been owned by the package
[23:05] <xnox> or something ;-)
[23:05] <slangasek> are you concerned that running both our rule and the user's rule will break things?
[23:05] <xnox> ok.
[23:05] <kees> xnox: there shouldn't be anything in /etc
[23:05] <slangasek> Frankly, I think overriding the system rules by shadowing the file in /etc is a weird thing to do
[23:06] <kees> xnox: what's your plan? you're going to remove debian/mdadm.udev (85-...) and use the shipped 64-... without the "disable incremental" patch?
[23:06] <slangasek> I would expect users to *add* rules under different names, not try to override the stock ones
[23:06] <xnox> Ok, then the reporter of bug 968074 will have to clean up one's /etc
[23:06] <xnox> kees: yes.
[23:06] <kees> xnox: cool
[23:06] <xnox> slangasek: see above bug. Users working around our broken udev rules =/
[23:07] <xnox> kees: also debian switched default superblock format....
[23:07] <kees> xnox: oooh, cool
[23:07] <kees> xnox: to which?
[23:07] <kees> 1.2?
[23:07] <slangasek> xnox: so worst case is that it takes a little longer to run the rules for this device because the same commands are run twice, right?
[23:07]  * xnox needs checking
[23:07] <slangasek> that's not worth risking disabling other kinds of customization for
[23:07] <xnox> slangasek: true.
[23:07] <kees> the 2TB limit on the 0.90 version is reason enough to switch the default, IMO.
[23:08] <xnox> slangasek: the only worry, if users explicitly desiabled the whole rule, to for example *not* automount raids at boot, but now we will...
[23:08] <xnox> because we renamed the rule
[23:08] <slangasek> heh... /me thinks we should probably get some integration tests in place before we change the default superblock format
[23:08] <cjwatson> wow, I thought we'd taken a default change ages ago
[23:09] <slangasek> xnox: automount, or auto-assemble?
[23:09] <kees> xnox: I think that's enough of a corner-case it's not a problem
[23:09]  * xnox needs checking. kees wrote up that we still have old 0.90, but debian switched to newer format, I'm still digging through the package diff. Way to many spurious changes and no udd.
[23:10] <xnox> kees: ok.
[23:11] <xnox> slangasek: good point. I think auto-assemble.
[23:11] <xnox> but will check.
[23:12] <slangasek> xnox: yeah... I guess it's possible users might do that, but I think it's too hard to get the handling right to deal with this automatically
[23:13] <kees> xnox: looks like precise has the new format
[23:13] <xnox> kees: can't wait for all the LTS users to upgrade
[23:13]  * xnox oh, wait...
[23:13] <kees> xnox: I think I checked on this in oneiric last.
[23:13] <kees>        -e, --metadata=
[23:13] <kees>               Declare the style of RAID metadata (superblock) to be used.  The
[23:13] <kees>               default  is 1.2 for --create, and to guess for other operations.
[23:13] <kees> and I verified in on an actual --create
[23:15] <xnox> kees: slangasek: bug #997315
[23:15] <xnox> http://pad.lv/997315
[23:15] <xnox> MDadmExamine.dev.sda5: Error: command ['/sbin/mdadm', '-E', '/dev/sda5'] failed with exit code 1: mdadm: No md superblock detected on /dev/sda5.
[23:15] <kees> ew
[23:18] <slangasek> winning
[23:19] <slangasek> xnox: that looks like something we should target for 12.04.1?
[23:19] <xnox> slangasek: yes, please.
[23:19] <slangasek> done
[23:23] <Bluefoxicy> ha-HA!
[23:23] <Bluefoxicy> I wrote an init script that creates as many zram devices as CPUs, creates a device mapper striped RAID across them, and creates swap on that :D
[23:24] <Bluefoxicy> (it's hideous)
[23:24] <xnox> Bluefoxicy: as long as you did not use [64|65|85]
[23:24] <xnox> -raid.rules
[23:24] <xnox> name for the udev, I'm fine
[23:24] <Bluefoxicy> nah
[23:24] <xnox> good
[23:25] <Bluefoxicy> I need to clean this up.
[23:25] <Bluefoxicy> Multi-thread works like this:
[23:25] <Bluefoxicy>  - Is MULTITHREAD==1?
[23:25] <Bluefoxicy>   Yes:  - Do we have exactly 1 CPU?
[23:25] <Bluefoxicy>   Yes:  MULTITHREAD=0
[23:38] <Bluefoxicy> xnox: http://pastebin.com/RFrTunUP if you're curious :P
[23:39] <Bluefoxicy> I should find the script that sets up zswap in casper and make a patch that does this.
[23:40] <Bluefoxicy> well, not sure.  I'm not sure how Linux swaps or if this is the better way to do it.
[23:41] <Bluefoxicy> in theory, if Linux swaps in individual pages, this is horrible (tbh, it'd be fantastic if I could make CHUNK_SIZE less than PAGE_SIZE)
[23:41] <Bluefoxicy> if it swaps out in bigger chunks (say 4, 8, 16 pages at once), and device mapper writes it all in parallel, this is great.
[23:42] <Bluefoxicy> The other way to do this is to load multiple swap devices with the same priority
[23:43] <Bluefoxicy> in which case linux will auto-balance, though again it becomes a question of how (per-page balancing, per-swap balancing, even use, or just move from one to the next if a swap is in process on the first?)
[23:44] <Bluefoxicy> THAT method would be great if it balanced via even use per-page, i.e. if it swaps 16K across 4 devices it swaps 4k and 4k and 4k and 4k all at once
[23:45] <Bluefoxicy> wot a mess.  The real solution is to multi-thread zswap inherently and use lz4
[23:48] <Bluefoxicy> ahh
[23:48] <Bluefoxicy> it interleaves.  SO I'm dumb and this raid thing is stupid.
[23:52] <xnox> ok.