[02:17] <mandrig> If I were looking for resources on beginning to develop for Ubuntu, where should I look? Thanks!
[02:18] <mspencer_> Hi, I was working on a bug fix (LP #657275) a while ago but haven't had time to test it until now.  Apport has been updated since then so now my fix is in an older version. What do I need to do to get it into the current version of Apport?
[02:18] <sarnold> mandrig: I'd start skimming here: http://developer.ubuntu.com/packaging/html/
[02:19] <mandrig> sarnold: thank you
[02:20] <sarnold> mspencer_: at the least, try it on a new version of apport :)
[02:26] <mspencer_> sarnold: By copying all the changes into the new version of the code?
[02:27] <sarnold> mspencer_: yes, making sure to adjust them if necessary
[02:29] <mspencer_> sarnold: Okay, thanks.
[02:37] <mandrig> Is there a known delay for Launchpad to be able to verify PGP keys? I'm trying to attach my key to my Launchpad account, and LP keeps telling me there's an issue with my key.
[02:39] <TheLordOfTime> mandrig, about 15 - 30 minutes i think.
[02:40] <TheLordOfTime> before LP will recognize it on the PGP keyservers
[02:40] <mandrig> Thank you TheLordOfTime, I figured there was a propogation delay or something :)
[02:40] <TheLordOfTime> yeah, its not usually long though, i've seen it work in 5 minutes before, but i'd give it up to 30 just in case things're being slowish
[05:38] <pitti_> Good morning
[06:39] <Mirv> there looks to be a big spike at errors.ubuntu.com for gnome-control-center & update-manager that wasn't there yesterday
[06:40] <Mirv> for precise, and precise at least just had some gcc update?
[07:45] <infinity> xnox: How do you feel about addressing jdstrand's compiler warning concernes in bug #1077484 so we can finish up the MIR mess for shadow?
[07:45] <infinity> xnox: Comment number 8.
[09:51] <doko> tjaalton, please consider to use llvm-3.2 instead of 3.1 for mesa
[09:54] <tjaalton> doko: in raring? sure
[09:55] <doko> tjaalton, yes, thanks
[09:55] <tjaalton> does debian-experimental have it too?
[09:56] <tjaalton> sid does
[09:56] <tjaalton> that's enough
[10:01] <xnox> tjaalton: for bug 1068404, you invalidated the bug in comment #62. There are a few patches proposed to be merged, but i am not convinced it is or isn't cherrypicks from upstream.
[10:02]  * xnox ponders if 12.04.2 with quantal stack will have the same problem or not.
[10:04] <tjaalton> xnox: I'll check it again. maybe we should revert the change after all
[10:06] <xnox> tjaalton: ack. It's best if you look at what upstream actually did, as comments #102 & #105 indicate that xorg-edgers ppa may or may not be fixed already.
[10:15] <tjaalton> xnox: upstream just commented that it's safe to revert for now, but in future more will get removed. hope fglrx is fixed by then
[10:23] <tjaalton> xnox: assigned the bug to myself, you can remove sponsors from the subscribers
[10:24] <tjaalton> and the review team
[10:25] <tjaalton> heh, 42 proposed members on the review team
[10:26] <xnox> unsubscribed sponsors, i am not in the review team, and we need TB member to set merge proposal for quantal as "work-in-progress"
[10:27] <tjaalton> I'm not going to merge from bzr anyway ;)
[10:27] <xnox> fair enough =)
[10:28] <tjaalton> hum, can't join the sponsors team
[10:59] <tjaalton> doko: unfortunately one of the mesa drivers doesn't build with 3.2 yet. there are patches for llvm & mesa to fix it though
[11:00] <doko> tjaalton, do you have a pointer to the llvm patches?
[11:00] <tjaalton> doko: searching..
[11:03] <tjaalton> doko: http://cgit.freedesktop.org/~tstellar/llvm/ looks like it's a ton of changes..
[11:03] <doko> tjaalton, could you file a debian bug? Sylvestre prefers it having there
[11:04] <tjaalton> doko: sure
[11:04] <doko> yeah for llvm not having release branches ...
[11:05] <tjaalton> what's the bug topic?-)
[11:05] <tjaalton> adding support for r600/si?
[11:05] <doko> fix mesa ftbfs with llvm-3.2
[11:05] <doko> ?
[11:05] <tjaalton> ahh, right
[11:05] <tjaalton> it doesn't even go past configure phase
[11:05] <tjaalton> but anyway
[12:27] <pitti> apw, ev: what's the status of https://code.launchpad.net/~ev/apport/kernel-oops-crash-signature/+merge/129440 ?
[12:27] <ev> oh, andy was mentioning that he's not seeing them show up in production. Adding to my todo list
[12:30] <ev> oh
[12:30] <ev> it seems I lost track of this :)
[12:30] <ev> apw: ^ would you mind providing some review on that
[12:39] <apw> ev, looks good to me
[12:39] <ev> cool, thanks
[12:41] <apw> ev, there are bound to be problems with it, but till we get it sucking on some input we'll never notice, so i say apply it
[12:46] <mitya57> happy new year everybody (once again)
[12:46] <mitya57> is it possible to include new translations in SRUs?
[12:46] <geser> pitti: Hi, do you have an idea why the installation of postgresql-common in pbuilder or PPA fails? "/usr/share/postgresql-common/supported-versions: 46: /usr/share/postgresql-common/supported-versions: DISTRO: parameter not set" (https://launchpadlibrarian.net/127277379/buildlog_ubuntu-raring-i386.postgresql-filedump_9.1.0-1_FAILEDTOBUILD.txt.gz)
[12:46] <pitti> geser: yes I have
[12:47] <pitti> geser: I fixed it in bzr yesterday; missing lsb-release dependency
[12:47] <geser> ah
[12:47] <pitti> geser: (I fixed it without the need for that dependency)
[12:47] <pitti> but if you install that somehow (it's just a recommends), it'll work
[12:48] <geser> I stumbled upon it while reviewing the archive test rebuild results
[13:04] <Laney> Can someone tell why this source package build is failing with a failed patch application? http://paste.ubuntu.com/1495288
[13:04] <Laney> You can see the patch in question applying correctly at the start, but then for some reason dpkg-source tries to apply it again and only one file in it fails ?!?!?!
[13:07] <diwic> Laney, your skills are bigger than mine, but "*** No rule to make target `distclean'." might be a hint?
[13:08] <diwic> Laney, a distclean should have unapplied the patches?
[13:11] <ogra_> dh_clean should, no ?
[13:11] <Laney> don't think so
[13:11] <diwic> hmm, I'm trying here
[13:12] <Laney> why does it pick that one in the middle of the series?
[13:12] <Laney> which happens to be the one I just added
[13:12] <diwic> just apt-get source
[13:13] <diwic> Laney, which one did you add?
[13:13] <Laney> add-pkgconfig-file
[13:13] <diwic> could there be stray .pc directories?
[13:16] <Laney> still happens if I quilt pop -a; rm -r .pc; debuild -S
[13:17] <diwic> maybe it's some kind of bug related to .pc files in the actual patch too?
[13:17] <diwic> or maybe I'm just shooting in the dark
[13:17] <ogra_> i wonder what dh_autoreconf_clean does to Makefile.am ...
[13:18] <cjwatson> I don't think it's picking one in the middle of the series - I think it suppresses output from applications that succeed
[13:18] <geser> patch "import-camerabin" touches Makefile.am too
[13:18] <cjwatson> I would tend to agree with ogra_ that some kind of interaction with dh_autoreconf_clean is likely to be at fault
[13:19] <cjwatson> Make sure you quilt refreshed in a clean state (after dh_autoreconf_clean)
[13:20] <Laney> dh_autoreconf hasn't been run in this tree
[13:20] <cjwatson> Well, although thinking about it dh-autoreconf really shouldn't be touching Makefile.*am*
[13:20] <Laney> so I doubt _clean is doing anything
[13:20] <cjwatson> Only Makefile.in
[13:20] <Laney> there's no fuzz with this patch
[13:20] <cjwatson> So I don't know and need to run :)
[13:21] <Laney> running the erroring command (after changing paths) works
[13:21]  * Laney wibbles
[13:22] <Laney> let me tar up the directory :-)
[13:24] <Laney> oh, ffs
[13:25] <Laney> so the answer was that I had accidently edited Makefile.am outside of the patch and inserted some whitespace
[13:26] <diwic> ok :-)
[13:26] <Laney> which quilt was happy patching as it was consistent within the directory
[13:26] <Laney> but when applied on top of the orig.tar.xz it obviously fails
[13:27] <ogra_> heh
[13:27] <Laney> diffing with an unpacked copy of the archive's source package revealed that
[13:28] <Laney> a "welcome back to work after a long holiday" problem
[14:14] <tkamppeter> pitti, all works and I have also updated the GIT of CUPS.
[14:15] <pitti> tkamppeter: nice!
[14:15] <tkamppeter> pitti, can you upload the cups-filters to Debian, thanks.
[14:15] <pitti> tkamppeter: yup, doing
[14:19] <OdyX> ^ woot
[14:20] <OdyX> tkamppeter: can you make your changelog entries less verbose ? Specifying all affected files for a split makes it unnecessarily verbose.
[14:20] <tkamppeter> pitti, OdyX, the test failure in the Debian package of CUPS seems to be small, it one error message in error_log too much.
[14:21] <OdyX> tkamppeter: ah nice.
[14:21] <OdyX> tkamppeter: does it clean its print queues now ?
[14:23] <pitti> tkamppeter: do we really need a new binary package for a 23 kB binary?
[14:23] <pitti> tkamppeter: the three libavahi-common* depends are ~ 100 kB in total
[14:23] <pitti> (i. e. the extra depends)
[14:24] <pitti> tkamppeter: or is that for more easily uninstalling this feature? (but I thought ordinarily you would configure it off, not uninstall)
[14:25] <OdyX> tkamppeter: also, you forgot to move the manpages
[14:26] <melodie> hello, would someone know what Casper/Ubiquity uses to define the ubiquity-frontend-gtk background please ?
[14:27] <xnox> melodie: the paths to backgrounds are hard-coded in ubiquity-dm, and a custom wallpaper binary is used to "paint" them in ubiquity mode. (The wallpaper picture in the background of ubiquity)
[14:28] <xnox> in live-session mode - is done the same way as in final install.
[14:28] <melodie> xnox, humm... how could I add a custom wallpaper binary in a customized version I am working on ?
[14:28] <melodie> because for now it's plain black and somehow difficult to read. :D
[14:29] <xnox> melodie: raring? wallpaper is broken in raring dailies.
[14:29] <xnox> to replace background drop it here and it will be used: /usr/share/backgrounds/warty-final-ubuntu.png
[14:29] <melodie> no it's Precise
[14:29] <melodie> oh !
[14:30] <xnox> or in ubiquity-dm look for backgrounds paths and you can modify it =)
[14:30] <melodie> I'll have to look what the files installed by ubiquity-dm then : maybe I'll use the easy solution
[14:30] <xnox> (yes default background is always called "warty", meh )
[14:30] <melodie> let met see what this /usr/share/backgrounds/ png file looks like
[14:30] <melodie> I don't mind the name, thanks
[14:31] <tkamppeter> pitti, the separation of the CUPS daemon allows having the CUPS damon for only driverless printing, for example printing to remote CUPS queues. This is a scenario for mobile, like Ubuntu for Android.
[14:31] <tkamppeter> OdyX.
[14:31] <melodie> xnox, that's exiting !
[14:31] <tkamppeter> OdyX. ^^
[14:32] <melodie> xnox, thank you very much !
[14:32] <xnox> np. =)
[14:32] <melodie> here is a pic of what I am doing : http://meets.free.fr/debian/images/BoxBuntu.png
[14:33] <pitti> tkamppeter: ah, so it's to avoid the cups-filters dependency, not the other way around
[14:33] <tkamppeter> pitti, OdyX, one gets a 1MB (cups-damon + libcups2 + cups-browsed) printing stack. I have intendedly left all docs in the "cups" package to save space. The cupsd is started automatically anyway.
[14:34] <pitti> tkamppeter: uploaded; will take a bit though as this has to get through Debian's NWE
[14:34] <pitti> NEW
[14:34] <tkamppeter> pitti, and to leave out CUPS' own heavy stuff like filters, backends, the web interface, documentation, ...
[14:35] <tkamppeter> Odyx ^^
[14:35] <melodie> xnox, I don't find a file under /usr/share/backgrounds for now
[14:35] <melodie> neither in my box nor in a lubunti
[14:35] <melodie> lubuntu
[14:36] <OdyX> pitti: did you upload to Debian ?
[14:36] <melodie> what size is that image supposed to be ?
[14:36] <pitti> OdyX: cups-filters, not cups
[14:36] <OdyX> pitti: ah okay.
[14:36] <OdyX> pitti: I'm currently merging master-wheezy
[14:37] <xnox> melodie: it can be one of these four names: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L383
[14:37] <tkamppeter> OdyX, about the test failure, all error messages in error_log of the test are here: http://pastebin.ubuntu.com/1495462/
[14:38] <tkamppeter> pitti ^^
[14:38] <OdyX> tkamppeter: the one too much is "Filter "urftopdf" not found.
[14:38] <tkamppeter> OdyX, pitti, there is one error message more than expected, but I do not know which one.
[14:39] <OdyX> tkamppeter: … I guess
[14:39] <melodie> xnox, thanks, I look. I am also looking into the python script ubiquity-dm now and I might be interested in the lubuntu-openbox method, because the box I build is with openbox (no dm)
[14:39] <tkamppeter> OdyX, urftopdf was added to cups-filters very recently.
[14:40] <pitti> tkamppeter: right, that's the most plausible one
[14:40] <melodie> xnox, I'll have to pick one that exists, to get the right size of image, to do one specifically for this openbox remix
[14:41] <melodie> I might have a xubuntu iso, I'll try to extract it from there
[14:41] <tkamppeter> pitti, OdyX: /usr/lib/cups/filter/urftopdf exists on the system where I did the build.
[14:41] <ogra_> xnox, heh, funny that only edubuntu has a generic name for it
[14:42] <xnox> ogra_: tbh, we should be querying xfce-config / gsettings what now & use that. Otherwise one has to change default flavour settings & ubiquity to change wallpaper name.
[14:42] <ogra_> well, thats what we did in the past i think
[14:43] <ogra_> yeah, i agree
[14:45] <pitti> tkamppeter: yes, but not in the temp install for the test suite
[14:45] <pitti> tkamppeter: it's using the local files, not the system installed ones
[14:46] <tkamppeter> pitti, and it is using the mime files from the system? Or why does it search for urftopdf?
[14:47] <pitti> tkamppeter: that was my next question -- the corresponding mime file should be installed by cups-filters, not cups
[14:48] <pitti> and I don't see any match for "urftopdf" in cups indeed
[14:48] <tkamppeter> pitti, is it linking in the system's filters (from cups-filters) by a series of hard-coded "ln -s ..." commands, needing to be manually updated whenever cups-filters adds a filter?
[14:49] <pitti> tkamppeter: could be; I don't know enough about how that stuff works to know off the top of my head
[14:50] <tkamppeter> pitti, CUPS does not know about urftopdf, cups-filters delivers urftopdf and the appropriate mime entries, so everything what the CUPS package needs to use it.
[14:51] <tkamppeter> pitti, so this is a bug in CUPS-upstream's test suite? Do I have to register every new filter in cups-filters at CUPS upstream that they hard-code its linking into their test-suite?
[14:51] <OdyX> tkamppeter: ah, you need to check debian/patches/tests-use-cupsfilters.patch
[14:51] <OdyX> tkamppeter: yes. It's patched by us to have it work.
[14:51] <OdyX> so just add a line there
[14:52] <pitti> ooh, and then tests will work again, and we can finally upload to Debian experimental?
[14:52] <pitti> I think I saw several requests from Debian to get 1.6
[15:05] <bdrung> do we have some rules for posting to ubuntu-devel (e.g. re. top posting, plain text)?
[15:06] <xnox> bdrung: we have code of conduct + your mail will be moderated if you are not a developer.
[15:06] <xnox> ubuntu-devel-discuss is an open ml
[15:06] <Laney> he means style guidelines
[15:07] <bdrung> exactly
[15:07] <ogra_> the general ML guidelines apply i think
[15:07] <bdrung> where are these guidelines documented?
[15:08] <melodie> xnox, thanks to you I'll be able to go a little further
[15:10] <mahmoh> infinity: I need to persuade you to accept https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=seabios into lucid-proposed I can verify bug 589063 quickly, otherwise hallyn will have my head :) - please?
[15:10] <xnox> bdrung: they are unspoken rules, but there are a few guides on google.
[15:10] <melodie> I'll have one more question in case someone has an idea : for unknown reason I am unable to get an automatic login in the live cd, and at the end of install when I configure a user, with automatic login as well, I don't get the automatic login in the installed version either. My tests are run in virtualbox and I don't use a desktop manager. Only lightdm as session manager. any idea ?
[15:12] <ogra_> bdrung, http://www.ubuntu.com/support/community/mailing-lists
[15:12] <ogra_> "Write your email underneath the email which you are replying to."
[15:12] <xnox> wow =)
[15:13] <Laney> Evolution (Ubuntu's default email client)
[15:13] <ogra_> haha
[15:13] <ogra_> time for an update it seems
[15:13] <Laney> hur hur
[15:14] <bdrung> ogra_: thanks. that page sums all up.
[15:19] <tkamppeter> pitti, OdyX, I have fixed CUPS on the GIT now, it passes the test suite, but needs cups-filters 1.0.25 or newer to build.
[15:19] <pitti> tkamppeter: awesome! can you please bump the build dep accordingly?
[15:20] <tkamppeter> pitti, I did so already.
[15:23] <OdyX> tkamppeter: you don't need the -3~ for cups-filters (it will fail)
[15:23] <OdyX> tkamppeter: it was needed because I added bc in .24-3 but .25 doesn't have a -3 yet
[15:24] <tkamppeter> OdyX, sorry, I forgot it in one of the two lines. It built for me locally and so I dd not see it.
[15:26] <OdyX> tkamppeter: and did you re-enable the pstops patch ?
[15:26] <tkamppeter> OdyX, no, I did not see that there was a disabled patch.
[15:27] <tkamppeter> OdyX, I have fixed the -3~ now.
[15:27] <OdyX> tkamppeter: good, thanks.
[15:27] <OdyX> tkamppeter: the merge is a headache to manage, but I'll get there eventually by sub-merging the releases one by one
[15:28] <pitti> OMG 226 line changelog
[15:28] <pitti> (in cups debian git trunk)
[15:29] <pitti> override_dh_auto_test:
[15:29] <pitti>         make check
[15:29] <pitti> tkamppeter: ^ do we still need that then?
[15:30] <tkamppeter> pitti, I did not add this. Is "make check" not the defauult call for the self test of an upstream source package?
[15:30] <pitti> that's what I thought
[15:30] <pitti> tkamppeter: presumably it's a leftover from previously disabling the tests with "make check || true"?
[15:32] <tkamppeter> OdyX, pitti, re-activating the pstops patch makes the ipp-2.1.test fail. It should not, if we want to test IPP stuff it should not depend on filter chain priorities.
[15:32] <OdyX> pitti: might be.
[15:32] <OdyX> pitti: yeah, I'd like to have more descriptive changelog entries (and less lists of files there…)
[15:34] <pitti> OdyX, tkamppeter: package builds fine ATM and all tests succeed; nice! (there is a missing symbol in debian/libcupsppdc1.symbols, but we don't build with -c4)
[15:37] <OdyX> pitti: wait, I'll break it by merging the stuff targetted at Wheezy
[15:37] <OdyX> :)
[15:43] <melodie> bye
[15:44] <highvoltage> bdrung: is this perhaps what you looked for? http://www.ubuntu.com/support/community/mailing-lists
[15:45]  * ogra_ hands highvoltage some *strong* coffee
[15:57] <bdrung> highvoltage: yes and i recommend you to take ogra_'s *strong* coffee ;)
[15:57] <ogra_> hehe
[15:57]  * xnox is out of coffee *snif*
[15:58] <highvoltage> thanks ogra_, I just got up and need it :)
[16:00]  * bdrung comes out as non coffee drinker
[16:08] <xnox> bdrung: do you drink red bull then?
[16:08]  * xnox is acting all naive =)
[16:09] <bdrung> xnox: rarely
[16:09] <bdrung> i drink coke rarely, too
[16:09] <bdrung> so most times i am tired :)
[16:11] <tkamppeter> pitti, as cups passes the tests now, will youy upload it to Debian? Or needs the pstops issue to be fixed at first?
[16:13] <pitti> tkamppeter: I don't know about the pstops issue; but I understand that OdyX is still working on cups?
[16:18] <tkamppeter> pitti, if OdyX is still working on CUPS, let him complete.
[16:29] <OdyX> tkamppeter, pitti : I'm just merging the job done for Wheezy into experimental
[16:34] <doko> jodh, online?
[17:16] <infinity> mahmoh: Promise?
[17:17] <mahmoh> infinity: which?
[17:18] <infinity> mahmoh: That you'll verify this seabios this time. :P
[17:18] <ogra_> beer ?
[17:18] <mahmoh> infinity: yes, I'm properly notified now, 100% or a case of beer for all!
[17:18] <mahmoh> (one case for all to share that is :) )
[17:34] <infinity> xnox: Any progress on tidying up cunit?  The archive's in a mildly inconsistent state until we get this sorted. :/
[17:34] <infinity> xnox: (Since I trusted Jamie's review and promoted everything before noticing the extra dep...)
[17:43] <OdyX> tkamppeter: I'm not convinced that the split is worth the effort, but ohwell.
[18:02] <xnox> infinity: yeap. I am about finished with partmal-lvm-auto & clashing vg names. And then I'll do cunit. Should be today. I'll ping you about cunit promotion.
[18:11] <infinity> xnox: Thanks in advance, then. :)
[18:25] <OdyX> tkamppeter: damn. The test suite still fails to purge the control files when built in sbuild.
[18:26] <OdyX> tkamppeter: ah no, even outside of an sbuild now.
[18:26] <OdyX> hrm
[18:36] <OdyX> tkamppeter: might it be a crash/timeout of imageto* in cups-filters ?
[18:36] <OdyX> tkamppeter: all the remaining control files here are when it tries to print testfile.jpf
[18:36] <OdyX> jpg
[18:41] <OdyX> tkamppeter: ah, indeed: "/usr/lib/cups/filter/imagetops 1 user 'title' '' '' testfile.jpg > /tmp/test.ps" fails
[18:55] <melodie_> hi
[18:56] <melodie_> xnox, are you still here ? I have done an iso with a new png image added into /usr/share/backgrounds and I was expecting the background for ubiquity gui installer to change color but it didn't, it still stayd black. Would you have another idea ?
[18:56] <melodie_> I paid attention that the name for the png be the same, and the size in pixels as well
[18:57] <melodie_> warty-final-ubuntu.png
[18:57] <melodie_> and also the rights and permissions
[19:01] <OdyX> tkamppeter: would it be possible that cups-filters needs a 1.6 cups to work correctly ? In that case, it would need a bootstrapping in Debian, no ?
[19:24] <OdyX> tkamppeter, pitti : pushed my merge to master, the build fails here because of the control files purge. It get "better" if I install the packages I just built before re-building, so I stand to my "bootstrap" suspicion, but I can't fix that for now. If you have an idea...
[19:27] <OdyX> tkamppeter, pitti : also, I don't get how /etc/default/cups gets installed in libcups2, that's very probably wrong (or needs a Breaks)
[19:39] <infinity> Laney: Did you mean s/good/base/ in your cheese upload?
[19:42] <infinity> Laney: Oh, I see, it's waiting on a split from NEW.
[19:47] <infinity> hallyn: I thought the whole point of this qemu merge was to get us in sync with Debian?  Why the Ubuntu upload?  Are we still stuck with a delta for some reason?
[20:06] <hallyn> infinity: we have a ubuntu delta because:
[20:06] <hallyn> 1. we have some arm and gridcentric patches which are not yet upstream
[20:06] <hallyn> 2. we need some changes to deal with our old package layouts (to obsolete them)
[20:07] <hallyn> 3. there are some things we can't have in main
[20:07] <hallyn> infinity: the debdiff from debian is actually pretty small though
[20:08] <hallyn> infinity: http://paste.ubuntu.com/1496902/  the debdiff from debian to ubuntu
[20:16] <infinity> hallyn: I'd push for some of these to just be in the Debian package to make merging easier (like the Breaks/Replaces on qemu-common, doesn't hurt to have it in Debian)
[20:16] <infinity> hallyn: Same with the breaks/replaces on qemu-kvm.  (and we could keep theirs as well)
[20:17] <infinity> hallyn: The transitional packages, perhaps they don't want, but even that wouldn't hurt, and lets people more easily test and sidegrade.  But that's not even remotely a supported thing to do, so meh.
[20:18] <hallyn> i can ping Michael Tokarev to see if he's amenable
[20:19] <infinity> hallyn: The bits where we differ in /etc might be nice to try to converge on as well at some point.
[20:19] <hallyn> infinity: yes - i'm not sure whether they actually use what they ahve or not
[20:22] <infinity> hallyn: (other than /etc and debian/control bits, the rest seems sane to have as a delta for now, I concede the point... At least we're getting closer)
[20:22] <hallyn> infinity: i'll start by trying to break the debdiff into meaningful chunks (the bottom bits of which would be pushed to debian) at github.com/hallyn/qemu
[20:22] <hallyn> infinity: esp since this also (almost) gets rid of qemu-linaro
[20:50] <jbicha> hallyn: "things we can't have in main" = spice ? are there reasons for that posted somewhere?
[20:50] <hallyn> jbicha: it's also vde2
[20:51] <hallyn> there is a spice MIR bug which should have the rationale for the nack for main
[20:51] <hallyn> mainly it depends on libs which are duplicates of what is already in main, and not particularly trusted
[20:53] <jbicha> hallyn: I've tried searching but I can't find a spice mir
[20:53] <jbicha> I also am wondering why spice-protocol is in main
[20:53] <melodie_> xnox, if you are still around, this is what I get : http://meets.free.fr/debian/images/ubiquity-frontend-gtk-look.png
[20:54] <hallyn> jbicha: the libraries in question were cegui-mk2 xerces-c2 ois devil allegro4.2 dialog svgalib freeimage
[20:54] <jbicha> oh, nm I guess xserver-xorg-video-qxl pulls it in
[20:54] <melodie_> the blue image around is what I have put into the wallapers directory, but how can I get the ubiquity windows itself to have the right colors ? at least something clear and readable ?
[21:02] <jbicha> hallyn: is that still the case? I'm having trouble finding those libraries in the spice source
[21:03] <hallyn> jbicha: then it might be worth revisiting
[21:03] <jbicha> part of why I'm asking is because a friend has to workaround bug 975165
[21:04] <hallyn> jbicha: i'd be very happy to just have spice in main.  do you want to open a new MIR for it?
[21:05] <jbicha> hallyn: sure I can start the paperwork :)
[21:09] <hallyn> jbicha: awesome, thanks!
[22:10] <melodie_> which version of Ubuntu does this one ubiquity-dm belong to ?
[22:10] <melodie_> http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L564
[22:11] <melodie_> the one for Precise seems not to be the same ? http://pastebin.com/z4JiC5NK
[22:13] <melodie_> I am trying to find out how to get a background with a decent color in the window of the ubiquity gtk frontend, and can only have a black background (a remix I'm trying to do) here is a pic : http://meets.free.fr/debian/images/ubiquity-frontend-gtk-look.png
[22:13] <melodie_> any idea how I could fix it ?
[22:58] <melodie_> good night
[23:30] <vadi2> How would I go about asking for a package that was updated in Debian to be updated in Ubuntu+1?
[23:31] <xnox> vadi2: which package?
[23:31] <vadi2> https://launchpad.net/ubuntu/quantal/+source/mudlet
[23:33] <xnox> vadi2: it's fully up to date, https://launchpad.net/ubuntu/+source/mudlet
[23:33] <xnox> in raring.
[23:33] <xnox> if you want a backport to previous releases, !backports
[23:33] <xnox> !backports
[23:33] <vadi2> Ah. Thank you.