[00:28] why oh why is the 32-bit desktop/live DVD 1.5 gigs and the 64-bit 700 megs? [00:29] Bluefoxicy: where are you looking? I see i386 at 1.5GB and amd64 at 1.6GB here [00:31] cdimage.ubuntu.com/releases/precise/release [00:32] right, same place I'm looking at :) [00:32] Where is the 700MB i386 @_@ [00:33] on releases.ubuntu.com [00:34] silly me === johanbr_ is now known as johanbr === dendrobates is now known as dendro-afk [02:54] 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] 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] is there such a thing as slanty double quotes that the shell interprets like backticks? [02:56] psusi: they are unicode quotes, not ascii [02:56] 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] someone has messed the file up [02:57] the bug therefor is arguably that there is no vigrub command to detect such issues [02:57] vigrub is a slippery slope [03:00] weird... yea, looked it up, unicode U+201D, right quotes [03:01] but I didn't know bash had special interpretation for that... === jbicha is now known as Guest1332 [05:02] hmm the ubuntu code of conduct page wont accept a signed debian diversity statement.... [05:06] scientes: why would it ? [05:41] Good morning [05:41] morning pitti [05:41] infinity: no, I didn't dump any component-specific ddebs [05:42] 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] hey ajmitch, how are you? [05:44] pitti: good, how are you today? [05:44] I'm quite well, thanks! we had a nice weekend, and you? [05:45] a nice, uneventful weekend where I mostly got over the ubuflu (still) :) [05:47] ajmitch: argh; mine is mostly gone, too [05:59] pitti: thank you for approving my fix! [05:59] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti [05:59] hey angeloc, thanks for spotting this [05:59] angeloc: uploaded to Debian and Ubuntu now [06:00] hi pitti, happy piloting [06:00] thanks micahg [06:00] pitti, i'm porting quickly to qt4 and qtquick and i spotted a wrong dependency in the building process! [06:01] pitti: can I ask you help with bug 993867? [06:01] Launchpad bug 993867 in xoscope (Ubuntu) "Xoscope package lacks pulseaudio-esound-compat as dependency" [Undecided,New] https://launchpad.net/bugs/993867 [06:01] pitti, i'm looking for sponshorship [06:02] angeloc: urgh, there are still packages out there which speak esound? [06:02] pitti, xoscope is really an ancient package! it' uses esound compat to talk to pulseaudio [06:03] pitti, so in the end it uses pulseaudio [06:03] angeloc: yes, I mean protocol wise [06:03] angeloc: you set up an SRU description, so I'll upload to quantal and precise-proposed [06:03] ok? [06:04] pitti, yes, i'm investigating rewriting the software for pulseaudio, but the code is quite difficult to understand [06:04] 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] pitti, yes, i can really enjoin the bug will be fixed also in precise [06:04] pitti, i'm new in sru process, so please be patient! [06:05] angeloc: oh, changelogs are not SRU speciifc [06:05] angeloc: anyway, I'll add it for you [06:05] angeloc: do you know how to forward a fix to Debian? [06:05] pitti, weel no, i fixed another bug in xoscope and i think that debian will benefit both [06:06] pitti, i'm intrested in learning the sru process, can I fix the branch myself? [06:06] angeloc: there is nothing to fix for the SRU part [06:06] pitti, adding a changelog i mean [06:06] angeloc: oh, sure [06:06] 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] pitti, i have to use -i flag to increase version number right? [06:08] angeloc: FYI, https://wiki.ubuntu.com/Debian/Bugs has the documentation how to forward bugs to Debian [06:08] angeloc: ah, that could be; I have configured dch to do that automatically for ages, so I forgot about it [06:09] pitti, yes i read the documentation, but using debian bug tracking is really a pain [06:09] angeloc: either way, it needs to create a new changelog record, not append to the already existing one [06:10] 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] angeloc: if you modify the source, yes; you can't modify it directly [06:11] angeloc: since you are working on another change, I propose I'll wait for that with the upload instead of uploading twice? [06:12] pitti, cannot understand, i branched quantal/xoscope and fixed debian/changelog, which step i have to do now? making a debian patch? [06:13] pitti, i have only one patch [06:13] angeloc: err, wait; what are we talking about now? [06:13] angeloc: adding the missing changelog entry for your esound-compat addition, or the other fix you said you were working on? [06:14] 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] 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] angeloc: ah; this has nothing to do with debian/patches/ then [06:15] angeloc: just do dch -i, describe the change, and debcommit/bzr push that to your branch [06:15] 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] angeloc: why do you need a patch? You only add the dependency, you don't change any source code [06:16] pitti, ok, that's right! adding changelog with dhc ... [06:21] pitti, done [06:30] angeloc: uploaded to quantal and precise-proposed, thanks! [06:30] pitti, wow! [06:30] angeloc: note that the -proposed upload will hang in a review queue and needs to be accepted by the SRU team first [06:30] pitti, yes, i know [06:44] found a bug: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1002152 [06:44] Launchpad bug 1002152 in lightdm (Ubuntu) "lightdm does not set background with wallpaper change" [Undecided,New] === yofel_ is now known as yofel [07:00] good morning [07:10] * micahg thinks he'll wait for the morning to upload gimp in case something breaks [07:12] micahg, the desktop team will have a couple of hours to fix it if it does :) [07:12] dholbach: I'm sure they have enough work to do :) [07:13] and they don't officially support it anyways [07:13] s/officially/actively/ [07:14] right, I guess it is mostly updates and merges [07:16] in fact, the -desktop branch is no longer the main branch, lp:ubuntu/gimp is [07:19] 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] tseliot: good morning [08:34] Could somebody review https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/937522 for me? Its been open some time now :) [08:34] Launchpad bug 937522 in remmina (Ubuntu) "rdp clipboard sync doesn't work anymore." [Undecided,Confirmed] [08:35] tseliot: should nvidia-current and friends depend on nvidia-common? (or soon ubuntu-drivers-common) [08:36] dupondje: can you please forward this to upstream? [08:36] dupondje: I can review it then [08:37] pitti: its commited upstream already [08:37] oh, nice [08:38] Tested it some time, made a ppa version of it also to let other people test it :) [08:38] dupondje: sponsoring now, thanks! [08:39] great! [08:39] pitti: good morning to you. Yes, it's probably a good idea to make it depend on nvidia-common [08:40] tseliot: I'm asking because presumably the postinsts should set/update the alternatives? [08:40] pitti: the postinst of the nvidia drivers already do that [08:41] 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] pitti: shouldn't the driver manager tell you that? [08:42] i.e. jockey or whatever replaces it [08:42] tseliot: yes, but only if you actually use that [08:42] pitti: SRU it also or not important enough? [08:42] good morning [08:42] tseliot: if you install it in software-center or via apt, there won't be anything to update them [08:42] dupondje: your call; sounds fine to me for an SRU [08:42] pitti: the only way to know for sure is to call update-alternatives [08:43] 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] we get bug reports to no end [08:43] pitti: SRU then :) clipboard is a good to have thing :) [08:44] pitti: no, I don't think so. Diversions were even worse... [08:44] * tseliot still has nightmares about diversions... [08:44] dupondje: done [08:45] thcx [08:45] tseliot: I'd like to start on implementing the spec now, with renaming the package and adding the packagekit/aptdaemon plugins [08:45] now lets fix the other 100 bugs in Remmina :P [08:45] tseliot: do you keep this in a particular Vcs, or just lp:ubuntu/nvidia-common? [08:46] pitti: there's a git repository. Let me check if it's updated [08:47] pitti: Weird, then, that I can find ddebs for libc6, but not nscd, despite the build log showing nscd.ddeb being genrated. [08:47] infinity: indeed, neither for any other version.. http://ddebs.ubuntu.com/pool/universe/e/eglibc/ [08:48] pitti: here it is: https://github.com/tseliot/nvidia-common === gaspa1 is now known as gaspa [08:49] 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] 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] 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] \o/ [08:51] (on fetching ddebs from launchpad) [08:53] tseliot: can you rename projects in github, or only create a new one and delete the old? [08:53] 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] Only barely, for me. :P [08:55] pitti: it seems that I can rename it [08:56] pitti: shall I rename it as ubuntu-drivers-common? [08:56] tseliot: if you don't mind [08:56] ok [08:56] tseliot: grazie! [08:57] pitti: di niente ;) [08:58] pitti: https://github.com/tseliot/ubuntu-drivers-common [08:59] * pitti forks [08:59] 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] pitti: if need these ASAP, just let me know and I'll focus on them [09:00] tseliot: not that urgent; I'll make sure that the new code (jockey replacement) works with 3 [09:01] pitti: ok [09:12] tseliot: hm, AFAICS the "nvidia-common" script is not installed anywhere; is that a bug, or is it just obsolete? [09:12] tseliot: the one which calls nvidia-detector and shows the "obsolete-driver" debconf note [09:13] 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] ok [09:14] tseliot: I'll leave it for now with the nvidia -> ubuntu-drivers renaming, I was just wondering whether I was missing something [09:14] pitti: ah, ok. we can remove it later === mlankhor1t is now known as mlankhorst === tkamppeter__ is now known as tkamppeter [10:15] Do we have some libusb expert around here? [10:34] tseliot: did I remember to push my python3 branch of x-kit, or were you working on it independently? [10:35] cjwatson: I ported xkit to python 3 some time ago (and cleaned up the API) but I couldn't upload it [10:36] ah, it wasn't even in bzr anywhere visible when I looked [10:36] 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] cjwatson: no, sorry, it's in a local branch of mine [10:36] 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] cjwatson: ok, thanks, I'll have a look at it [10:59] tseliot: btw, the renaming is already in https://github.com/martinpitt/ubuntu-drivers-common , in case that's blocking you [11:03] pitti, do you know a libusb expert at Ubuntu? === MacSlow is now known as MacSlow|lunch [11:03] tkamppeter: I don't, I would have told you otherwise [11:05] pitti, so all USB expertise needed to make up Ubuntu is in the upstream projects? === ivanka1 is now known as ivanka [11:06] for libusb, apparently so [11:11] geser: hm, your pcsc-lite merge is uninstallable due to libccid not existing; ccid FTBFSed [11:11] geser: did you try this with a local build? [11:12] I opportunistically retried the ccid build now [11:14] 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] pitti: looks like I've to file a MIR for ccid as pcscd is in main [11:18] ah great, ccid built [11:20] geser: danke [11:44] Laney: updated the tracker for python3 only on cd, please pull /dima =)))) into correct branch ;-) [11:45] is lp:ubuntu/mountall the upstream of the mountall package? [11:47] I saw, will look soon [11:53] xnox: is there no is_bad you can have? [11:54] did I ask this before ... feeling a déjà vu [11:54] 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] i see [11:55] 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] nah, no need [11:56] Laney: it's ~good enough (tm) [11:56] pitti: ok, thanks, I'll merge your changes [11:57] pushd [11:57] pitti: actually, can you make a pull request from github, please? [12:00] 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] tseliot: sorry, was at lunch [12:10] 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] pitti: fair enough, we don't have to upload it now [12:13] tseliot: https://github.com/tseliot/ubuntu-drivers-common/pull/1 [12:13] thanks [12:13] tseliot: the rest should not be so intrusive, mainly adding files [12:14] pitti: pulled, thanks [12:14] ok [12:15] cjwatson: I'm applying your changes for xkit, especially the ones to the test suite. Thanks again === MacSlow|lunch is now known as MacSlow === _salem is now known as salem_ [12:19] tseliot: great, thanks === zyga is now known as zyga-food [12:26] barry: hi! is there some sort of tag to use for things being ported to python3? === dendro-afk is now known as dendrobates === zyga-food is now known as zyga [12:49] jtaylor: ping [12:58] I have created an SRU for eggdrop at https://bugs.launchpad.net/ubuntu/+source/eggdrop/+bug/885329 , can somebody check it? [12:58] Launchpad bug 885329 in eggdrop (Ubuntu Oneiric) "eggdrop crash on i386" [Medium,Triaged] [13:03] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage, pitti [13:08] Can https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385 be nominated for precise? [13:08] Launchpad bug 598385 in munin (Ubuntu) "munin plugin exim_mailqueue has incorrect graph configuration" [Low,Triaged] [13:09] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage [13:15] * dholbach hugs pitti and jamespage [13:15] aww [13:19] jtaylor: weren't you looking at eggdrop? ^ [13:21] Laney, vibhav: there is an eggdrop SRU in the precise queue [13:21] http://launchpadlibrarian.net/105631901/eggdrop_1.6.19-1.2ubuntu3.1_source.changes [13:21] is it from jtaylor? [13:21] yeah. [13:22] looks like it's taken care of then [13:22] oneiric has one as well [13:25] ah fine [13:26] jamespage: Are you busy? [13:27] vibhav, I'm available for piloting duties! [13:27] want me to take a look at that munin bug? [13:28] yeah [13:29] I also attached a debdiff for quantal [13:29] You might want to check it too :) [13:30] vibhav, ack - I think I spotted another SRU candidate for munin last week - looking at your debdiff now [13:35] the correct debdiff is at #6 [13:44] jamespage: How is the debdiff? [13:45] vibhav, looks good - just sweeping in the other change as well [13:45] ivanka: wow, are you back? [13:46] jamespage: Could you link me to the revised debdiff? [13:52] vibhav, http://paste.ubuntu.com/999058/ [13:54] vibhav, patch was fine - but was missing from series file... [14:09] cjwatson: are there useful docs for how to build live CDs from a new packageset? [14:10] I found this guide which works ok for getting to that point https://docs.google.com/document/d/1RPPF14h1Sw2gQjGTuZjUIlNHnGrafS8ekhFjJM9MT00/edit [14:12] jbicha: almost certainly not [14:12] jbicha: you could go straight to the live-build documentation though and DIY [14:12] jamespage: thanks! [14:12] 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] jamespage: jamespage Do you want to to work on an SRU? [14:13] a* [14:14] jdstrand: re: tag for py3 ports... not yet [14:14] vibhav, ultimately yes - would you have time to pickup detailing the SRU in the bug report? [14:15] yeah [14:16] 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] jamespage: I dont know the steps to reproduce [14:36] jamespage: Any specific regression potential for https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678 ? [14:36] Launchpad bug 1000678 in munin (Ubuntu Precise) "[SRU] munin-memory plugin doesn't work on 64-bit 12.04 LTS" [Medium,Triaged] [14:36] vibhav, no - not really [14:36] it broken as it stands ATM [14:45] 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] popey is unity dev now ? wow :) [14:47] didrocks: sure, I'll add him now [14:47] bdmurray: thanks :) [15:07] jamespage: ping [15:10] jamespage: done, https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678/comments/8 [15:10] Launchpad bug 1000678 in munin (Ubuntu Precise) "[SRU] munin-memory plugin doesn't work on 64-bit 12.04 LTS" [Medium,Triaged] [15:11] 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] xnox, can I assign it back to you? (I wasn't even at the session) [15:13] is that really the best use of their time? [15:13] 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] 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] 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] dholbach: true. there was another person asking for those scripts (apart from/in addition to) me [15:16] was it balloons? [15:16] I don't know [15:16] * vibhav sits in the corner and waits for jamespage [15:16] 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] in any case I'm happy to send them over to you [15:17] vibhav, sorry - was just dealing with something else [15:17] seb128, I wasn't even in that session :) [15:17] seb128, but it's good to know :) [15:17] ;-) [15:17] jamespage: So could you check the SRU debdiff? [15:17] vibhav, in the next 30 mins yes [15:18] thanks! [15:19] dholbach: ok. [15:19] thanks xnox [15:20] seb128: and infinity is not in today as far as I remember or something. [15:20] xnox, sent [15:20] xnox, right, he will read the scrollbars I guess [15:20] or at least look for highlights ;-) [15:21] (and being pinged by seb128 is always a highlight !) [15:21] * xnox *giggles* [15:21] hey, has anyone seen gustavo niemeyer today? [15:22] ogra_, well, infinity said something about never trusting the frenchs again recently so I'm careful ;-) [15:22] haha [15:22] zyga, not on freenode (hint) [15:22] ogra_: ah, thanks [15:26] that's hilarious. [15:26] you can install IcedTea Java WebStart [15:27] in Precise [15:27] pull up Software Center, punch in Java, install Java WebStart. [15:27] it doesn't WORK [15:27] ... because it really doesn't care if you don't have a JRE installed [15:27] 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] oh. That's why this doesn't work. [15:31] it installes icedtea-netx-common [15:31] but doesn't friggin' install icedtea-netx [15:32] so Software Center can't install Webstart at all [15:32] vibhav, the changes are fine but the changelog is going to need alot more detail [15:32] quote 'a detailed and user-readable changelog' [15:33] jamespage: Like? [15:35] Describe the bug your patch fixes in easily readble terms [15:35] 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] vibhav, http://paste.ubuntu.com/999223/ [15:36] I try to cover off - a) what is being fixed, b) how and c) the source [15:37] jamespage: Can you write my changelogs for me aswell please? [15:37] this information is obviously in the patch headers as well but it makes it easier for the SRU team to review [15:38] Daviey: :-) [15:38] heh [15:41] jamespage: https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678/comments/9 [15:41] Launchpad bug 1000678 in munin (Ubuntu Precise) "[SRU] munin-memory plugin doesn't work on 64-bit 12.04 LTS" [Medium,Triaged] [15:42] vibhav, OK - leave it with me - I need to review the information in the bug reports as well [15:45] brain damage of the day: bug 1002357 [15:45] Launchpad bug 1002357 in mdadm (Ubuntu) "sort out udev rules madness (3 editions installed into 4 files)" [Undecided,New] https://launchpad.net/bugs/1002357 [15:46] 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] Okay, serious question. [15:50] I hoped that someone has written for the C++ [15:50] Anyone on Precise, punch in 'dmesg | grep Yama' in a terminal [15:50] 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] 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] though the latter at least doesn't have a page for cout [15:55] Bluefoxicy: http://lwn.net/Articles/393012/ [15:59] xnox: ah ok. Was just amusing, and funny. Yama is japanese for Mountain, and also king of the spirit world. [16:01] Bluefoxicy: je ne parle pas japonais [16:01] xnox: It looked like a joke :p Yama: Becoming mindful ... i.e. meditating buddhist god [16:02] many names of free software programs started as jokes at some point [16:02] wubi == security blanket [16:03] I think that one may be coincidence [16:05] 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] or is this just me? === deryck is now known as deryck[lunch] [16:43] does anyone know if the PySide Qt bindings are in Precise? [16:44] should be [16:49] 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] 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] why shouldn't ufw on the server be made to work with python3? [16:52] cjwatson: it very well can. I didn't know if python3 would necessarily be on the server (or minimal, etc) [16:52] any given binary has to have one or the other in its #! line [16:52] you can preprocess it of course to use a different one, but that'd mean two packages just for the binary [16:53] I would like to avoid two packages for the binary [16:53] I suspect we're going to end up converting server bits as a result of converting desktop bits === dendrobates is now known as dendro-afk [16:53] I am currentyly using /usr/bin/python [16:54] 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] I believe our general plan is that most modules ought to support both for a period, but binaries should pick one [16:55] er, programs [16:55] cjwatson: it might just be an answer to this question: will python3 be on the server cd? [16:56] 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] (as upstream, I want to support 2.6 and higher (at least), but as the package for Ubuntu/Debian, I can choose) [16:56] you might as well assume it'll be there [16:57] ok [16:57] if it isn't, we can revisit [16:57] cjwatson: thanks [16:57] 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] Then you are likely to end up with both, I'm afraid [16:59] i suspect for this cycle, that makes sense. [16:59] 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] agreed [17:00] i suspect we won't be able to make it to 100% py3 this cycle, though maybe close to 80-90% [17:06] 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] thanks! [17:07] good night [17:08] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [17:08] ttfn === deryck[lunch] is now known as deryck [18:01] any ideas what would add independent to /etc/apt/sources.list? bug 947296 [18:01] Launchpad bug 947296 in update-manager (Ubuntu) "Update-manager stopped updating" [Undecided,Confirmed] https://launchpad.net/bugs/947296 [18:03] no ideas here [18:04] 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] stgraber: hmm, thanks === jalrnc_ is now known as jalrnc === jalcine is now known as Jacky [19:37] https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication => Still some endorsments wanted ! :) [19:51] http://img818.imageshack.us/img818/2163/screenshotfrom201205211.png is this a bug? [20:02] is there any launchpadlib api code for copying ppa builds to ther series? [20:07] Yes, syncSource [20:08] itym copyPackage [20:09] Laney: I like my errors synchronously, thanks :-p [20:19] ah, I meant a handy tool using the launchpad api not what do I need to use in the api to do it === zsoftich is now known as SoftServe [21:54] gn [22:02] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell === tkamppeter_ is now known as tkamppeter [22:53] 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] xnox: 2A) [22:55] (TTBOMK) [22:56] 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:56] Launchpad bug 1002357 in mdadm (Ubuntu) "sort out udev rules madness (3 editions installed into 4 files)" [Undecided,New] https://launchpad.net/bugs/1002357 [22:59] xnox: are these installed in /etc/udev/rules.d, or /lib/udev/rules.d? [23:01] 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] hmm, interesting [23:01] .udeb should be ok, no migration path [23:01] right [23:02] 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] 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] true [23:02] 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] ok. But if users customized 65/85 will their config get dropped or still applied on top of ours? [23:03] if a rule exists in /etc it is ignored in /lib [23:04] (but have exactly the same filename) [23:04] correct... but if they're under different filenames, which order are they applied in? [23:04] are they interleaved by number? [23:04] both are merged into lexical order [23:04] * slangasek nods [23:04] I was thinking to rename /etc/[65|85 [23:05] ] to *.rules.dpkg-disabled [23:05] I wouldn't, if those files have never been owned by the package [23:05] or something ;-) [23:05] are you concerned that running both our rule and the user's rule will break things? [23:05] ok. [23:05] xnox: there shouldn't be anything in /etc [23:05] Frankly, I think overriding the system rules by shadowing the file in /etc is a weird thing to do [23:06] 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] I would expect users to *add* rules under different names, not try to override the stock ones [23:06]