=== tkamppeter_ is now known as tkamppeter
[03:41] <djustice|fff> dgen pkg.. x64 is busted, --force-arch an i38b deb and it's good.. -.- wth..
[05:29] <pitti> Good morning
[05:30] <stgraber> good morning pitti
[05:30] <ajmitch> morning pitti
=== _LibertyZero is now known as LibertyZero
=== yofel_ is now known as yofel
=== doko__ is now known as doko
[07:50] <didrocks> good morning
[08:54] <dholbach> good morning
=== tkamppeter_ is now known as tkamppeter
[10:10] <doko> apw, rtg: could one of you merge kexec-tools?
[10:11] <apw> doko i don't think i have ever done that, is there some docs on how one does
[10:11] <doko> jhunt: could you take over the libnih and sysvinit merges?
[10:11] <apw> (its likely about time i did know how)
[10:13] <doko> apw: ahh, no, seems to be a lool thing (arm)
[10:13] <apw> doko, ahh ok
[10:16] <persia> apw, You may as well try if you want to learn.  Basically grab the debian and Ubuntu sources.  Look at the diff between Ubuntu and the Debian upon which it is based.  Discard that which is unneeded, and rebase the rest on the new Debian.
[10:17] <persia> (if you are slow, or get it wrong, lots of folk (probably especially lool) would be happy to help)
[10:17] <apw> persia, yep
[10:22] <cjwatson> apw: https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[10:23] <apw> cjwatson, ahh thats what i am looking for thanks
[10:24] <Laney> http://people.canonical.com/~dholbach/packaging-guide/html/udd-merging.html ;-)
[10:29] <pitti> kees, jdstrand: releasing hardy linux to -security/-updates
[10:56] <jhunt> doko: looking at it now...
[10:58] <doko> cjwatson: openssl again builds for i486/i585/i686. merge error?
=== cking_ is now known as cking
[11:06] <cjwatson> doko: where are you seeing that?  no sign of it in https://launchpadlibrarian.net/70883771/buildlog_ubuntu-oneiric-i386.openssl_1.0.0d-2ubuntu1_BUILDING.txt.gz
[11:10] <pitti> tkamppeter: hey Till, how are you?
[11:11] <pitti> tkamppeter: has there been a decision of https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-system-config-printer-vs-gnome-3-control-center ? can you please add some work items and clean up the whiteboard, to turn it into a real blueprint? thanks!
[11:11] <doko> cjwatson: ouch, wrong chroot :-/ one more coffee ...
[11:11] <cjwatson> heh
[11:14] <apw> cjwatson, kexec-tools in debian recently added a udeb, we seem to have not pulled that in in previous merges, do we want that do you think?
[11:14] <cjwatson> feel free to include it
[11:14] <cjwatson> in general if Debian has something there should be an explicit reason not to have it
[11:14] <cjwatson> and there isn't, in this case
[11:14] <cjwatson> (not saying our installer will actually use it though)
[11:15] <apw> cjwatson, ack
[11:40] <cjwatson> doko: llvm-2.8 seems to build successfully on current amd64; mind if I do a no-change upload of it to finish the ocaml transition?
[11:41] <cjwatson> doko: (I'm not in ~pkg-llvm, though, so can't commit to its branch)
[11:42] <doko> cjwatson: sure; I hope, we can drop it later this cycle as well
[11:43] <cjwatson> right, no objection to that, just want it off my list for now :)
[11:46] <cjwatson> oh, lp:~pkg-llvm/+junk/llvm-2.8-ubuntu is out of date anyway, so meh
[11:46] <doko> my bad
[12:15] <cjwatson> freeflying: can libofetion be synced, or does it need a merge?  openfetion needs a newer version of it to build
=== MacSlow is now known as MacSlow|lunch
[12:28] <ElementCracker> :D
[12:33] <apw> cjwatson, we have some ubuntu specific patches on kexec-tools, but they are not named specially, is there value in prefixing them with ubuntu- for clarity?
[12:34] <cjwatson> apw: practice varies
[12:34] <cjwatson> some people like to do that; I don't consider it critical
=== smb` is now known as smb
[13:02] <tkamppeter> pitti, OK. My plans this week are putting up bug reports on the appropriate packages to make up work items, so that the two Blueprints get implemented.
[13:02] <pitti> tkamppeter: ah, good; please link the bug reports to the specs, then they automatically become tracked as work items
[13:05] <tkamppeter> pitti, this was my intention.
[13:05] <tkamppeter> pitti, for new packages to be added, like colord, I have to link a "Needs packaging" bug?
[13:06] <tkamppeter> pitti, colord is not really a printing package, but something more general, who should package and maintain this?
[13:11] <ScottK> pitti: Who is "fboucault" to whom you gave a work item in the CD space spec to split off Qt modules?  It'd be nice if there was some coordination with the Kubuntu team on this.
[13:11] <pitti> ScottK: I just reordered it, it was already there
[13:11] <ScottK> OK.
[13:11] <pitti> ScottK: Florian has worked on unity-2d and some Qt packaging improvements
[13:12] <pitti> of course this should be coordinated with Debian as well ideally
[13:12] <ScottK> Yes.
[13:13] <ScottK> Doesn't seem to be on any channels I'm in for IRC (Kaleo)
[13:14] <pitti> (pinged him)
[13:15] <kaleo> hi
[13:15] <pitti> ScottK: please meet kaleo (Florian), who works on unity-2d
[13:16] <ScottK> Thanks.
[13:16] <pitti> kaleo: please meet ScottK, one of the Kubuntu masters (in this context)
[13:16] <kaleo> :)
[13:16] <kaleo> hi ScottK!
[13:16] <ScottK> kaleo: I see you have a work item to split out some Qt modules to save space on the Ubuntu CD.
[13:16] <ScottK> When you are ready to work on this, I'd like to invite you to join us in #kubuntu-devel to coordinate the change.
[13:16] <kaleo> ScottK: I think my work item was to list the Qt modules required by Unity 2D
[13:17] <ScottK> You are, of course, welcome anytime, but I want to make sure that things are coordinated.
[13:17] <kaleo> ScottK: I just joined
[13:17] <ScottK> Great.
[13:18] <seb128> didrocks, ^
[13:18] <seb128> didrocks, (not sure if you work on that or not, just highlighting in case)
[13:19] <ScottK> The work item in question is " [fboucault] Split off some more Qt modules which we don't need (> 1 MB):"
[13:19] <didrocks> yeah, I was supposed to coordinate that with the kubuntu team in case, didn't know kaleo had a WI
[13:19] <didrocks> seb128: thanks for the hilight :)
[13:19] <seb128> seems like the wi should be for didrocks
[13:20] <didrocks> kaleo: reassign me this one
[13:20] <kaleo> didrocks: I need to find it first :)
[13:20] <kaleo> (I'm pretty new to using blueprints)
[13:20] <pitti> or split it into "[florian] figure out needed modules" and "[didrocks] split pacakge"?
[13:20] <ScottK> https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-cdspace
[13:20] <didrocks> and anyway, as I already discussed for comaintainance with ScottK, I'll do that with the kubuntu team, once I'll have the list of needed module
[13:20] <ScottK> OK.  Great.
[13:21] <kaleo> ScottK: thanks
[13:21] <kaleo> pitti: good idea, let me do that
[13:22] <pitti> kaleo: FYI http://people.canonical.com/~platform/workitems/oneiric/canonical-desktop-team.html#fboucault
[13:22] <pitti> kaleo: has links to the blueprints, etc.
[13:22] <kaleo> pitti: superb, thanks
[13:22] <kaleo> didrocks: I split the WI
[13:22] <kaleo> didrocks: I mean, I just did the split
[13:23] <didrocks> kaleo: excellent, thanks :)
[13:23] <kaleo> didrocks: I shall send you an e-mail with the list of modules
[13:24] <didrocks> kaleo: perfect!
[13:29] <kaleo> didrocks: done!
[13:37] <pitti> kaleo: congrats, you are the first to finish all his oneiric WIs on the desktop team page :)
[13:43] <apw> is there a google calendar for the ubuntu release schedule for oneiric ?  doesn't seem to be in any of the ones already have
[13:44] <apw> (i suspect i used to be the Ubunt Release calender ... which stopped at 11.04)
[13:45] <apw> skaet, the Ubuntu Release calender does not have anything for Oneiric in it, is that an oversite or is the info no longer there)
[13:46] <freeflying> cjwatson: libofetion can be synced, and in terms of the FTBFS of openfetion, will do a upload soon to fix the build dependency
[13:48] <cjwatson> freeflying: OK, can you file a sync request bug please?
[13:48] <cjwatson> freeflying: why does openfetion need an upload?  I thought it was just that it needed the newer version of libofetion.
[13:49] <freeflying> cjwatson: because of the name change of libnotify
[13:50] <cjwatson> ah
[13:50] <kaleo> pitti: thanks, I will be glad to get a tiny item next cycle :)
=== MacSlow|lunch is now known as MacSlow
[14:01] <apw> persia, i wonder if you would have a min to review the kexec-tools merge i've been playing with: https://code.launchpad.net/~apw/ubuntu/oneiric/kexec-tools/merge
[14:01] <apw> (or indeed anyone who is interested)
=== bregma is now known as bregma|holiday
[14:02] <persia> apw, I'd be happy to take a look.  I can't accept the merge.
[14:02] <apw> np, more worried about the mechanics at this stage
[14:03] <persia> Speaking personally, when doing packaigng with bzr, I like to have one commit per debian/changelog entry, for ease of comprehension.  This doesn't affect anything: just expression of personal preference (and happens to work really nicely with debcommit)
[14:05] <apw> persia, mostly this was a scripted package-merge so there is only one change in that sense
=== johanbr_ is now known as johanbr
[14:31] <persia> apw, Looks properly formatted and documented to me.  The patches seem to apply/unapply cleanly (I'm not sure if you had to rebase, but if you did, nice work).
[14:31] <apw> persia, thanks :)
=== dendrobates is now known as dendro-afk
[14:55] <cjwatson> ogra_,NCommander: FYI, https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-live-build
[14:59] <skaet> apw,  Updating the ubuntu release calendar for Oneiric is on the to do list for this week.
[15:03] <apw> skaet, ok cool, just wondering as it appears that a1 is already "next week"
[15:04]  * skaet nods
[15:06] <apw> lool, you about?  wonder if you could review a kexec-tools merge i have done, seems you are nominal owner: https://code.launchpad.net/~apw/ubuntu/oneiric/kexec-tools/merge
[15:14] <jaromil> re all
[15:16] <jaromil> i'm trying to add our software (apt.dyne.org WIP) to software-center. have so far read the code and the little docu available and couldn't manage to have anything else to appear on the left panel below Canonical Partners
[15:17] <jaromil> anyone willing to reply a few questions? i'd like to avoid taking drastical decisions, like overwriting software-center code or fork it
[15:17] <jaromil> maybe i'm doing something wrong, yet adding a .list and .eula into app-install/channels doesn't suffices
[15:18] <persia> jaromil, app-install-data-partner is a handy reference package for your goal.  Don't forget to include .desktop files (and associated assets).
[15:19] <jaromil> saw that. ah! .desktop etc. is also needed to activate the display of channel?
[15:20] <persia> I'm not an expert (I last played with a channel for karmic), but the desktop files are used to display the software choices.
[15:20] <jaromil> thanks for the tip! i will complete the package with .desktop files for software and see how it goes. cheers!
[15:20] <lool> apw: Merge looks good on the packaging side, there are some gratuitous changes in the diff which I think result from cleaning the package and then committing the cleaned tree
[15:20] <apw> lool, yes indeed, is clean the wrong state ?
[15:20] <jaromil> i'm not sure about the channel, well it sounds worth trying
[15:20] <lool> apw: I'm speaking of the delta on generated files like ./kexec-tools.spec, ./include/config.h or ./configure
[15:21] <apw> lool, yeah, unsure what to do with those, i almost feel they shouldn't have been there before
[15:21] <lool> apw: This is a bug in the upstream and/or Debian build scripts, but it would be best if you would revert to the state before cleanup so that this doesn't show up in the Debian -> Ubuntu diff
[15:21] <lool> apw: You might want to mention the removal of ./debian/README.debian in the merge changelog entry
[15:21] <persia> lool, Those are being generated by the clean: rule.  Yes, that's not ideal, but it's happening in Debian as well.
[15:22] <apw> lool, will do and get back to you
[15:22] <lool> persia: I understand, it's best if it's not committed to the UDD branch though as it makes the debdiff between Debian and Ubuntu harder to read
[15:22] <lool> apw: Do you want me to upload this, or can you upload yourself?
[15:22] <persia> Ah.  That makes sense, sure.
[15:22] <apw> lool, i believe i can upload it, but i'll clean up the bits you mention first
[15:23] <apw> lool, and get you to give it the once over
[15:23] <lool> apw: Okay
[15:25] <lool> mvo: Oy
[15:25] <mvo> lool: Yo
[15:25] <lool> mvo: do you think https://launchpadlibrarian.net/69856446/apt_0.7.25.3ubuntu7_0.7.25.3ubuntu9.3linaro2.diff.gz is applicable to lucid?
[15:25]  * mvo looks
[15:26] <lool> mvo: Sorry, that debdiff isn't too readable; https://launchpadlibrarian.net/69855638/apt_0.7.25.3ubuntu9.3linaro2.debdiff is more readable
[15:27] <mvo> lool: yeah, that should be SRUable, we just need to create a proper testcase for the SRU description, thanks for extracting this
[15:27] <lool> mvo: Basically I need this change for the linaro-image-tools testsuite to pass under lucid which is still a release we target (via our PPA); I can keep this APT debdiff in our PPA, but it requires updating from time to time
[15:27] <lool> mvo: Could you comment on https://bugs.launchpad.net/linaro-image-tools/+bug/709895 stating the above?
[15:27] <ubottu> Ubuntu bug 709895 in apt (Ubuntu Lucid) "Testsuite fails under lucid" [Medium,Triaged]
[15:28] <lool> mvo: Is it ok if I use the linaro-image-tools testsuite as a test case for whether this works or not?
[15:28] <lool> mvo: The symptom in our testsuite is that packages from a local repo don't get picked up because they are unsigned; with the fix, they get picked up again
=== Quintasan_ is now known as Quintasan
[15:30] <mvo> lool: ok, pointing to this is probably ok, do you want to do the SRU upload or should i?
[15:33] <lool> mvo: I don't mind if you do it, you introduce less risk  :-)
[15:34] <lool> mvo: But I'm happy to do it if it's too time consuming for you
[15:38] <apw> lool, when you were comparing against debian, how were you doing that, via the bzr tags or some other way.  as adding the files back in identicly actually shows up as a remove and add of identicle contents
=== abhinav_ is now known as abhinav-
[15:41] <lool> apw: just using "diff" and then | filterdiff -x '*/.bzr/*'
[15:41] <lool> a bit brutal  :-)
[15:42] <lool> you can also use bzr diff --old ../debian-branch
[15:44] <apw> lool, the filterdiff makes most sense to me for this, cool thakns
[15:46] <apw> lool do you have an offiicial branch for this that i should be merging into, or do we just rely on the importer
[15:46] <lool> apw: I just used the UDD branch, so yeah, importer
[15:47] <lool> apw: nowadays, best practice would be to put the UDD branch URL in Vcs-Bzr, but at the time of the last merge, I wasn't aware of that
[15:47] <persia> Isn't there some advantage to merging into the UDD branch rather than using the importer, or is that only true for most atomic commits?
[15:47] <lool> feel free to add it or not
[15:47] <persia> s/most/more/
[15:47] <lool> apw: Ah you were asking whether you should commit and upload, or just upload; I'd recommend commit and upload
[15:48] <jaromil> update re: software-center - i've been including desktop files for software as in app-install-data-partner, plus .list and .eula in app-install/channels - YET i can't find a way to show an additional software channel in the left bar, below Canonical Partner
=== jdstrand_ is now known as jdstrand
[15:48] <jaromil> in software-center/backend/channels.py below line 400 it seems that there is a if...then chain
[15:48] <jaromil> which includes only specific cases, yet i'm not fluent in py so i might be wrong
[15:48] <apw> lool so push it over the importers branch lp:ubuntu/kexec-tools and then upload
[15:49] <jaromil> i'll be grateful for any further pointer on this issue, again i'd really prefer leave the software-center code unmodified
[15:49] <lool> apw: yup
[15:50] <lool> apw: "bzr mark-uploaded" will tag it with version from debian/changelog, then bzr push (to push the tag), then upload the .changes you get with "bzr bd -S"
=== dendro-afk is now known as dendrobates
[16:14] <hallyn> lool: hey - the binutils fix to let seabios build, did that get SRU'd for lucid?
[16:29] <lool> hallyn: I don't think so, doko would tell you whether it's on his list
[16:29] <lool> hallyn: but is lucid affected?
[16:29] <lool> That seemed like a 2.21.x regression to me
[16:33] <hallyn> lool: yes, i get the exact same failure building any seabios on lucid
[16:34] <lool> doko: ^
[16:35] <hallyn> (and maverick too, of course)
[16:35] <lool> hallyn: it did get built under lucid though; odd
[16:35] <doko> hmm, don't plan to do so
[16:35] <lool> but then binutils might have been updated afterwards
[16:35] <hallyn> hm
[16:36] <SpamapS> pitti: would love to continue my SRU training some time this week if you have some time.
[16:36] <lool> hallyn: which failure do you get?  the one about the regs or the one about the backward reloc?
[16:36] <hallyn> backward reloc
[16:36] <lool> definitely binutils then
[16:36] <hallyn> i can go aheda and push to lucid-proposed and see what happens
[16:36] <hallyn> had only tried local builds (with freshly updated lucid)
[16:36] <lool> hallyn: you could try in a lucid PPA instead of lucid-proposed
[16:37] <hallyn> allr ight
[16:42] <apw> cjwatson, is there a simple way to tell bzr bd -S that you need the orig included, akin to -sa ?
[16:42] <cjwatson> bzr bd -S -- -sa
[16:43] <apw> cjwatson, ta muchly
[16:44] <cjwatson> apw: also, bug 499684
[16:44] <ubottu> Launchpad bug 499684 in bzr-builddeb "Interface to dpkg-buildpackage inconsistent and not well documented" [High,Triaged] https://launchpad.net/bugs/499684
[16:46] <pitti> SpamapS: did you get my mail about the steps for proposed kernels?
[16:46] <pitti> I need to run out for a bit, bbl
[16:49] <SpamapS> pitti: no I see nothing about that. Have been having mail client issues though, so I may have accidentally deleted it.
[16:52] <jaromil> re-launching, last try: anyone knowledgeable about software-center has little time to spare on it? or any pointers on better com channels to look in?
=== deryck is now known as deryck[lunch]
=== MacSlow is now known as MacSlow|break
[17:32] <pitti> SpamapS: bounced it to you again; Subject: Re: [kernel-SRU] Bottleneck to copying kernels to -proposed
[17:39] <hallyn> lool: (fwiw, still waiting to build, i'll let you know when i have a result :)
[17:39] <SpamapS> pitti: ok I found it I had it archived
[17:42] <SpamapS> pitti: so we should take a step back. I don't even know how to move things from -proposed to -updates yet. We stopped at sru-accept
[17:43] <pitti> SpamapS: ah, I thought I asked you to try sru-release
[17:43] <pitti> as I wasn't sure how much privilege you need to do the call
[17:54] <kees> pitti: hardy> thanks!
[17:54]  * sebner waves at tseliot 
=== deryck[lunch] is now known as deryck
[17:55] <tseliot> hi sebner :)
[17:55] <sebner> tseliot: :) , do you remember what we talked about my touchpad problem at UDS (sry, didn't have time last week)
[17:56] <tseliot> sebner: kind of... but I still think cnd might know the answer
[17:57] <sebner> tseliot: then I'll talk to him! Thanks a lot! :)
[17:57] <tseliot> np
[17:59] <NCommander> cjwatson: thans
[18:11] <sebner> persia: if you haven't read the mail yet I might want to add some lines :)
[18:12] <persia> Heh, sure, go ahead.
[18:13] <sebner> persia: :), you know, always when you've done something you notice that you forgot something ^^
[18:14] <persia> If we were perfect, life would be boring
[18:14] <sebner> persia: but nice and calm ;D
[18:20] <mneptok> sebner: "Music is the space *between* the notes." - Debussy (emphasis mine)
[18:22] <sebner> mneptok: I think I've heard something like that already :)
[19:13] <hyperair> any archive admins here?
[19:13] <hyperair> might i know why banshee and banshee-community-extensions were rejected from -proposed?
[19:17] <persia> hyperair, For that, you don't need an archive-admin, you need to look at the affected bug.
[19:18] <hyperair> eh whoops
[19:18] <persia> It was rejected by someone on the SRU team.  In practice, most of these are archive-admins, but wearing a different hat.
[19:20] <hyperair> oh okay
[19:49] <Laney> hrm hrm
=== MacSlow|break is now known as MacSlow
[19:51] <Laney> I think there should be a general policy for upstream micro releases rather than requiring projects to go through the exception process
[19:52] <maco> Laney: do you mean per-upload exception process? or do you mean like how we have a standing exception for kde's microreleases?
[19:52] <persia> Laney: Some projects have aa different definition of "micro".
[19:52] <Laney> persia: Right, hence guidelines
[19:52] <Laney> maco: I mean upstreams should be able to do micro releases with the exception that they will be accepted as SRUs
[19:53] <persia> Is the process that onerous?  I thought it was just "Document that upstream is sane.  Tell the tech board."
[19:53] <persia> And most members of the SRU teams don't care about version numbers, as long as it solves known bugs, doesn't introduce features, is supportable, etc.
[19:55] <Laney> I would like to encourage more projects to support our stable releases, and placing process hurdles in their way isn't a way to do that IMHO
[19:56]  * maxb wonders if there is a sensible channel to ask questions about the use and debugging of sbuild?
[19:56] <Laney> If the TB could distill their assessment criteria into a policy that'd be a win
[19:57] <Laney> anyway I think I raised this at UDS and someone got an action item to improve the docs, so we'll see what comes out of that :-)
[19:58] <cjwatson> Laney: that's part of what we were trying to do with https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html
[19:58] <cjwatson> though, OK, that was new upstream versions rather than microversions
[19:59] <persia> maxb: This one works, although if you're not targeting Ubuntu, #ubuntu-packaging is preferred (as some folk object to helping people with PPAs or derivatives)
[19:59] <cjwatson> I agree we should do better for microversions too
[20:03] <Take> Good evening
[20:04] <Take> I'm having a hard time with preseed installation
[20:04] <Take> I'd need a way to keep one of the existing partitions on the hard drive
[20:04] <Take> With fully automated installation
[20:07] <maxb> Hmm - well, I'm not targeting anything specific right now, just trying to get a general-purpose sbuild setup in place for future use. It actually works right now if I run sbuild as root, but as my normal user, I get a "Failed to change directory: Permission denied" error from dpkg-source -x
[20:08] <micahg> maxb: are you in the sbuild groupo?
[20:08] <micahg> *group
[20:08] <maxb> I am
[20:09] <micahg> did you reboot or run sg sbuild after install?
[20:09] <maxb> Yes (id confirms that my current login session has me in the group)
[20:10] <maxb> Hm
[20:10] <maxb> Ah. I wonder if I'm actually in the sbuild group *inside* the chroot
[20:24] <maxb> Hm. This error appears to be generated by schroot itself as it tries to chdir to the appropriate directory within the chroot
[20:36] <soren> is there an easy way to get apt to output all of its configured sources? I'm trying to help someone debug a problem, and it's kind of awkward to explain that he has to collect the various sources.list.d files, but only the ones named *.list or whatnot.
[20:37] <micahg> soren: apt-cache policy
[20:38] <soren> micahg: Good point. I guess I could decipher that.
[21:51] <hallyn> Daviey: hey, around?
[21:55] <hallyn> lool: confusing - seabios built fine in my ppa for lucid, so i went ahead and pushed to lucid-proposed.  Good news, i guess, except for not liking inexplicably inconsistent results.
[21:59] <Daviey> hallyn, o/
[22:00] <hallyn> Daviey: hey, you have a local eucalyptus cluster right?
[22:00] <hallyn> Daviey: were you looking at all into whether it uses 'phy' for libvirt .xmls?
[22:24] <Daviey> hallyn, I haven't looked as yet
[22:24] <Daviey> TBH, i was going to grep the source :)
[22:28] <hallyn> Daviey: great, all the better, wasn't sure if you had the source available :)
[22:29] <hallyn> Daviey: thanks
[22:31] <Daviey> hallyn, not today, mind
[22:34] <hallyn> Daviey: k
[22:34] <hallyn> Daviey: if you get bored tonight, and wanted to look over https://bugs.launchpad.net/ubuntu/+bug/787220
[22:34] <ubottu> Ubuntu bug 787220 in Ubuntu "[needs-packaging] celt051" [Undecided,New]
[22:35] <hallyn> i could see discussion over that one going badly
[22:36]  * hallyn wonders whether to ask robbiew to take a look
[22:43] <persia> hallyn, Is it that hard to port spice?  new oldlibs are acceptable, but usually cause pain later.
[22:46] <Daviey> hallyn, oh joy
[22:46] <Daviey> hallyn, What is the concern?
[22:48] <hallyn> persia: what do you mean by port spice?
[22:48] <hallyn> persia: oh sorry, i thought you siad port celt
[22:49] <hallyn> persia: i'ts not htat hard, i think ppa:serge-hallyn/spice in fact is still the one using celt0.7.1
[22:49] <hallyn> persia: but people pointed out it then won't play nice with redhat
[22:49] <persia> hallyn, Won't play nice in terms of binary compatibility, or won't play nice in terms of interoperability?
[22:49] <hallyn> for some additional churn we could try and negotiate that to make it work, but the spice people claim they will never update to a newer celt until a 1.0.0 comes out
[22:49] <hallyn> interoperability
[22:50] <hallyn> well, and of course we'd still need celt051 to talk to a spice server
[22:50] <persia> Oh, that's sufficient justification.  Please make that clear in the bug report.
[22:50] <micahg> ugh, IIRC, there's a Debian bug on this
[22:50] <persia> And package it in section "oldlibs" so that nobody else decides it's a nifty idea to start using it for a new project.
[22:50] <zul> hallyn: oh joy
[22:50] <persia> Debian Bug 603699 ?
[22:50] <ubottu> Debian bug 603699 in wnpp "ITP: celt051 -- The CELT codec v0.5.1" [Wishlist,Open] http://bugs.debian.org/603699
[22:51] <micahg> persia: yeah, I think that's it
[22:52] <hallyn> persia: ok, thanks, will do
=== dendrobates is now known as dendro-afk