[00:26] <Adri2000> bug #537015 wait & see :)
[00:26] <ubottu> Launchpad bug 537015 in ubuntu "FFe: Sync blobby 0.8-dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/537015
=== jono_ is now known as jono
[01:43] <astronut> i have information that is a much more elegant solution for a thread on ubuntuforums.org but i don't have an account and don't feel like getting one just to post - would someone mind making a follow up for me? if so, PM me
=== yofel_ is now known as yofel
[03:56] <wzssyqa> hi,my package have a _ns3.so,it seems that is the python binding.and what should i do for it?
[03:56] <wzssyqa> or just install it to /usr/lib and ldconfig?
[03:59] <persia> wzssyqa: Generally we prefer versioned libraries (e.g. libfoo.so.1.2.3) in /usr/lib, with identified SONAMEs.  The easiest way is probably to install in /usr/lib and use dh_makeshlibs in debian/rules.  Adding a symbols file gets bonus points as it makes it easier to track ABI drift.
[04:00] <wzssyqa> Adding a symbols file gets bonus points as it makes it easier to track ABI drift.  i don't understand it
[04:01] <wzssyqa> persia: i used dh_makeshlibs
[04:01] <persia> stefanlsd: You really ought put your guide into the PackagingGuide somehow
[04:01] <persia> https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols talks about adding symbols files.
[04:12] <wzssyqa> persia: your means is that i just need to add dpkg-gensymbols?
[04:13] <persia> No, it's more complicated than that.  Please read that page again.
[04:25] <Some_Person> If a package in lucid added after the feature freeze is missing a build-depends that causes a feature of the package to be disabled, and the same problem existed for the earlier version in karmic and below and I already filed a bug for it, what should I do?
[04:26] <persia> Some_Person: Could you either give a concrete example, or rephrase the question?
[04:27] <Some_Person> supertux was not built against libcurl3. This means that add-on levels are disabled
[04:32] <Some_Person> What should I do?
[04:32] <persia> Hrm.  I don't see any rationale for that.  Please file a bug.
[04:32] <persia> Please feel free to include a debdiff for a new candidate if you like.
[04:33] <persia> I won't promise it won't get blocked for either a) FeatureFreeze or b) technical objections, but I will promise it will be reviewed.
[04:33] <Some_Person> I already filed the bug for the previous version of supertux that was in karmic and below
[04:33] <Some_Person> (it had the same problem)
[04:34] <Some_Person> The only change to the package would be adding 'libcurl3-dev' to build-depends in the control file
[04:35] <persia> I understand.
[04:35] <persia> But 1) it is a feature change, and 2) I want to check with other members of the Games team (who sleep at this hour) if there's a technical objection.
[04:36] <persia> Don't worry about a new bug: the old bug will do fine.
[04:38] <Some_Person> Also, I think know a solution to this bug for supertux, but it would require recompiling it in an odd way: https://bugs.launchpad.net/ubuntu/+source/supertux/+bug/207998
[04:38] <ubottu> Launchpad bug 207998 in supertux "supertux2 crashed with SIGSEGV" [Medium,New]
[04:41] <persia> Some_Person: What's your solution?  I think we just need to make sure we have a valid gltexture after we request it but before we use it.
[04:42] <Some_Person> persia: use -O2 instead of the default -O3 in cmake
[04:43] <Some_Person> doing that also fixes the problem of it not compiling with nvidia-glx installed
[04:45] <persia> How does changing the optimisation help?  That crash comes from using a null pointer.
[04:46] <Some_Person> I'm not sure if it fixes specifically _that_ crash, but it does fix crashing issues, for reasons currently unknown to any of the supertux developers
[04:47]  * persia doesn't like "fixes" that make things go away for unknown reasons on general principles.
[04:48] <RAOF> Mmmm.  Yummy assumptions broken by optimisation.
[04:48] <Some_Person> Like it or not, I think it's the fact that it works that counts
[04:49] <EzraR_> maybe a bug with the comiler?
[04:49] <EzraR_> compiler
=== EzraR_ is now known as EzraR
[04:49] <Some_Person> I implemented this fix in my SVN builds in my PPA, and it allowed the game to work on my other machine which just crashed on startup before
[04:49] <LLStarks> persia, is gparted still awaiting dependency updates?
[04:51] <persia> LLStarks: No idea.
[04:51] <persia> EzraR: More likely sloppy coding
[04:51] <LLStarks> gparted/parted haven't been able to update for a few days.
[04:51] <LLStarks> kept back.
[04:52] <LLStarks> is it motu or main?
[04:52] <persia> LLStarks: What architecture?
[04:52]  * persia was able to update
[04:52] <LLStarks> i386
[04:53] <persia> LLStarks: Hrm.  Odd.  Dunno.  Check with #ubuntu+1
[04:53] <persia> (worked for me)
[04:53] <stefanlsd> persia: hehe. i'll try put it there. wasnt sure it was an ok quality. you've pushed a bunch of people there tho :)
[04:53] <wzssyqa> persia: in general,how the python bingding 's sofile to name?
[04:53] <persia> stefanlsd: I'm not sure it's perfect yet, but it's the only doc on the subject I've seen anywhere.
[04:53] <RAOF> LLStarks: I'm pretty sure that if you allow new packages to be installed updates will succeed.
[04:53] <persia> wzssyqa: I'm the wrong person to ask.
[04:54] <LLStarks> conflicts.
[04:54] <LLStarks> aptitude won't even update them.
[04:54] <RAOF> I presume you've been full-upgrade-ing?
[04:54] <LLStarks> yeah. aptitude interface too.
[04:56] <persia> LLStarks: Really, worked for me and i386 never has arch-skew.  Do check in one of the support channels to get it updated.
[05:09] <persia> Looks like the various libparted lists in NBS have zeroed too.
=== LLStarks is now known as Eric_Massa
[07:47] <dholbach> good morning
=== noodles785 is now known as noodles775
[09:33] <akheron> I accidentally dput a package without the host argument, so I went to upload.ubuntu.com
[09:33] <akheron> it was intended for my own builder machine
[09:33] <Rhonda> akheron: dcmd dcut rm *.changes
[09:34] <akheron> Error: dcut is not supported for this upload queue.
[09:34] <Rhonda> Oh. That's a pity then.
[09:35] <akheron> how does the package get processed? Will it end up in some official queue and rejected there?
[09:37] <RAOF> akheron: Was the package signed by a gpg key that's associated to a launchpad account that has upload privileges to the appropriate component? (main, universe, etc?)
[09:37] <akheron> hmm, no
[09:37] <RAOF> If not, you don't have to worry; it'll get automatically rejected.
[09:37] <akheron> ok
[09:37] <akheron> thanks
[09:38] <akheron> actually, the e-mail address is registered with launchpad but the corresponding gpg key isn't
[09:38] <akheron> so yes, I believe it will be automatically rejected
[09:38] <RAOF> For bonus marks, edit the dput configuration to default to your buildbox.
[09:39] <akheron> yes, I'll do that right away :)
[09:49]  * Rhonda . o O ( Giving ubuntu help in #debian.de seems to work too, I'm not getting beaten for it :) )
=== yofel_ is now known as yofel
=== hannesw_ is now known as hannesw
[10:44] <jayvee> sigh...how long do I have to keep respinning these debdiffs for?
[10:45] <persia> jayvee: For which package do you keep getting stomped?
[10:46] <jayvee> my libvirt one at #528934
[10:46] <persia> jayvee: And people keep uploading libvirt on top of you?
[10:46] <jayvee> yeah
[10:46] <persia> You should call them out on #ubuntu-server : that's just impolite.
[10:46] <jayvee> it is
[10:46] <persia> Plus it indicates that they aren't even trying to close the bugs.
[10:46] <jayvee> I'm very new to debian packaging still, so it takes me a very long time to do.
[10:47] <persia> Something like "Hey <nick> : you uploaded libvirt : did you consider including my patch at bug #mmmmm ?"
[10:48] <jayvee> will do
[12:53] <torkel> siretart`: can you please extend my FAI Dev team membership?
[13:44] <BlackZ> how can I export the private part of my gpg key?
[13:45] <persia> BlackZ: man gpg.  Look at the --export options available.  There's a note on the one you would use that is very much worth reading explaining why you don't want to do this.
=== shadeslayer is now known as shadeslayer_
[13:52] <BlackZ> thanks persia !
[13:53] <persia> BlackZ: Now go make a revocation certificate, and backup (but don't export) your secret key somewhere really safe and unrecoverable by anyone but you :)
[13:55] <Rhonda> persia: I don't see much "explaining why" in there, maybe you are looking at a different man gpg.</nitpick>
[13:56] <persia> Well, ok.  It's the "This  is normally  not  very useful and a security risk." that really caught my eye.  I'll admit to not re-checking closely (and agree with you reading caefully)
[14:07]  * soren wonders why MOTU is the maintainer of the Bluefish project on Launchpad
[14:08] <soren> I've always wondered by it showed up in my list of related projects, but this is clearly why.
[14:10] <persia> Someone did something odd.  Please fix.
[14:11] <soren> Do you want to be set as the maintainer? :)
[14:11] <soren> persia: I don't think I can just unset it.
[14:12] <soren> Nope.
[14:12] <soren> Just tried to disown it. No dice.
[14:12] <persia> Unfortunate.  Probably needs someone to actively claim it.
=== shadesla1er_ is now known as shadeslayer_
[14:50] <ikt> anyone awake who is good with packaging?
[14:51] <Rhonda> Never. But maybe you could just describe your problem and people could answer your more substantial question instead? :)
[14:53] <ikt> electricsheep used to install fine, now it can't because libjpeg-progs has for some reason gone missing from the repos
[14:54] <Rhonda> I fail to see the connection to "packaging". Did you rebuild any of those packages, or did you just try to install them?
[14:54] <persia> bug 535629
[14:55] <ubottu> Launchpad bug 535629 in libjpeg6b "package libjpeg-progs is not built from any source package but several packages in lucid depend on it (dup-of: 537370)" [High,New] https://launchpad.net/bugs/535629
[14:55] <ubottu> Launchpad bug 537370 in libjpeg6b "build libjpeg-progs again" [High,In progress] https://launchpad.net/bugs/537370
[14:55] <persia> Also, that sort of question is best asked in #ubuntu+1
[14:57] <ikt> I haven't had one 'substatial' question answered in ubuntu+1
[14:57] <persia> That you don't get an answer in the support channel doesn't make other channels also support channels.
[14:58]  * persia happened to have that bug up anyway
[14:58] <ikt> ok
[14:59] <ikt> where can I find out how something like this happens?
[15:00] <ikt> I didn't think anyone could answer anyway, let alone ubuntu+1
[15:01] <persia> ikt: #ubuntu+1 is the channel that is supposed to be able to provide that support.  You can track what happens with specific packages on launchpad.
[15:03] <ikt> np
=== mcasadevall is now known as NCommander
[15:46] <siretart`> torkel: done
[15:51] <Laney> sistpoty|work: Hi, do you think syncing cabal-install is alright FFe wise?
[15:51] <Laney> also, pandoc has had a huge update in Debian, what do you think to that?
[15:51] <Laney> otherwise I will have to distro patch it to get it to work again
[15:52] <Laney> http://johnmacfarlane.net/pandoc/changelog.txt — we have 0.46 now
[15:52] <sistpoty|work> Laney: I'm fine with cabal-install
[15:53] <Laney> could you say so on the bug?
[15:53] <sistpoty|work> Laney: I'm also ok with pandoc
[15:53] <Laney> bug 534478
[15:53] <ubottu> Launchpad bug 534478 in haskell-cabal-install "cabal-install 0.6 not installable with ghc 6.12 in lucid" [Undecided,New] https://launchpad.net/bugs/534478
[15:54]  * Laney files one for pandoc
[15:54] <Laney> oh, we have some ranting users on a bug already :)
[15:55] <Laney> sistpoty|work: bug 309528 for pandoc
[15:55] <ubottu> Launchpad bug 309528 in pandoc "Please sync pandoc from debian unstable" [Undecided,Invalid] https://launchpad.net/bugs/309528
[15:56] <sistpoty|work> Laney: I assume you want 1.3-1 for pandoc?
[15:56] <Laney> yes please
[15:57] <Laney> I haven't done build testing yet, but in any event if it doesn't work I'll NMU it in Debian first
[15:58] <sistpoty|work> Laney: ok, debian bug 571402 suggests that it might not build
[15:58] <ubottu> Debian bug 571402 in src:pandoc "pandoc: FTBFS: Nonexistent build-dependency: highlighting-kate-doc" [Serious,Open] http://bugs.debian.org/571402
[15:58] <Laney> yeah I see that one
[15:58] <Laney> someone in the DHG will sponsor the NMU, I'm sure
[15:59] <Laney> oh, maybe it's best to wait for 1.5
[16:00] <Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559978#57
[16:00] <ubottu> Debian bug 559978 in pandoc "FTBFS [hppa]: Template Haskell splice illegal in a stage-1 compiler" [Serious,Open]
[16:01] <Laney> or else I'll 1ubuntu1 and then upload 1.5 later
[16:01]  * Laney tinkers a bit
[16:03] <sistpoty|work> Laney: ok, thanks, noted.
[16:03] <Laney> sistpoty|work: bad news, new build-dep on a package Lucid doesn't have
[16:03] <Laney> haskell-zip-archive
[16:04] <sistpoty|work> Laney: that is already through new in Debian? I wouldn't mind too much to get that in as well, given that you can convince an archive admin to new it.
[16:05] <Laney> i don't think they need convincing if the release team ok it
[16:06] <persia> Well, there's timing skew, and available eyeballs, but they aren't supposed to need convincing with release team approval.
[16:06] <sistpoty|work> Laney: well, I'm usally stating that the FFe is ok if the requester can convince an archive admin, so I guess I'm creating a chicken and egg problem there ;)
[16:07] <sistpoty|work> (I'll just try to ensure that new handling doesn't get to a real problem after FF)
[16:07]  * Laney test builds
[16:08]  * Laney headdesks
[16:08] <Laney> Depends: libghc6-digest-dev which is a virtual package.
[16:10] <Laney> but *that* one builds
[16:16] <Laney> sistpoty|work: what do you think to syncing that one too?
[16:17] <mrburns> question from a noob what does FF and FFe mean?
[16:17] <Laney> !ffe
[16:17] <ubottu> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
[16:17] <Laney> it means that ^
[16:17] <\sh> FF == Feature Freeze , FFe Feature Freeze Exception
[16:18] <mrburns> got it thanks
[16:18] <sistpoty|work> Laney: I guess I don't object too much. At least if we don't end up needing 10 other new packages as well ;)
[16:19] <Laney> no, that's the end of it
[16:21] <Laney> thanks, sistpoty|work!
[16:22] <sistpoty|work> Laney: thanks for working on it!
[16:27] <lfaraone> If package autokey-common, autokey-gtk, and autokey-qt  0.64.4  replaces files in versions of  "autokey" earlier than 0.64.4, and said versions of autokey cannot be removed once versions of autokey-{common, gtk, qt} greater than or equal to 0.64.4 are installed,  should I mark those three packages as "Replaces: autokey (<0.64.4)" or "Breaks: autokey (<0.64.4)", or both?
[16:27] <Laney> cannot be removed? That's Depends isn't it?
[16:28] <persia> lfaraone: Replaces: when you want to take over a file.  Breaks: when you make something not work.
[16:28] <lfaraone> persia: we're taking over a file, and shipping a new version of "autokey" which is a transitional package to -common and -gtk.
[16:29] <persia> When you say "transitional package" do you mean an empty package with relationships alone?  If not, please describe it a different way.
[16:29] <lfaraone> Laney: We want to remove autokey <0.64.4 to replace it with the dummy transitional package autokey 0.64.4, but if -common, -gtk, or -qt is installed, removing the older autokey package will fail.
[16:29] <Laney> I don't think you want to remove it
[16:30] <Laney> you want to provide a transitional package indeed, but that's distinct
[16:30] <lfaraone> persia: the new "autokey" package only contains a /usr/share/doc/autokey folder and dependancies.
[16:31] <lfaraone> Laney: well, to upgrade to the new package, dpkg first removes the older package, which fails.
[16:31] <persia> Don't bother with /usr/share/doc/autokey/* for that package.
[16:31] <lfaraone> persia: I think cdbs installs it automagically.
[16:31] <Laney> how does it fail?
[16:31] <persia> lfaraone: It can be convinced not to do so.
[16:31] <lfaraone> Laney: here's the crash I'm seeing when testing: http://sprunge.us/BYKX and grep for "Préparation du remplacement de autokey 0.54.5-1ubuntu0.2 (en utilisant .../autokey_0.61.4-0~0karmic~preppa1_all.deb) ..."
[16:34] <Laney> why does that happen?
[16:34] <Laney> You could handle it in a prerm of the new autokey
[16:36] <lfaraone> Laney: formally autokey had an init.d script. the new autokey does not, it's contained in autokey-common. which, afaict, isn't unpacked yet.
[16:36] <persia> http://women.debian.org/wiki/English/MaintainerScripts has a good description of how to capture failures on upgrades and deal with them in the new package.
[16:37] <lfaraone> persia: in what stage is the initd script restarted?
[16:37] <persia> But the issue is really stuff in postrm that belongs in prerm : conffiles need to not break stuff if the package isn't installed.
[16:37] <persia> lfaraone: Check your maintainer scripts.
[16:37] <persia> (there is no right answer)
[16:39] <persia> lfaraone: Note that you want to make sure that if the init script can be present when the package is not installed (but also not purged) that it doesn't cause an error.
[16:39] <lfaraone> persia: it looks like it's being done in both the prerm and the postinst.
[16:40] <persia> Those sound like sensible places, as the package will be unpacked at both those times.
[16:40] <persia> Are you shipping a postinst in your new package?
[16:40] <lfaraone> persia: see http://code.google.com/p/autokey/source/browse/branches/autokey-combined/debian/postinst and http://code.google.com/p/autokey/source/browse/branches/autokey-combined/debian/prerm
[16:41] <persia> That doesn't answer my question :)
[16:41] <lfaraone> persia: uh, I guess that's being shipped with all of the packages built by my control file, I think.
[16:41] <Laney> it's not that
[16:41] <lfaraone> is that correct?
[16:41] <Laney> it's this error:
[16:41] <Laney> "ImportError: No module named common"
[16:41] <Laney> why does that module not exist?
[16:41] <persia> Laney: That comes from trying to *run* autokey though.
[16:41] <persia> Laney: It's been removed.
[16:42] <persia> lfaraone: You want to put maintainer scripts in specific packages, not in everything, and *especially* not in a transitional package (except for snippets that may be required for transition)
=== yofel_ is now known as yfoel
=== yfoel is now known as yofel
[16:47] <lfaraone> persia: okay, so I should rename them to autokey-common.{postinst,prerm}, right?
[16:47] <lfaraone> persia: since theoretically the daemon should work without -qt or -gtk installed. (although I haven't tried that)
[16:47] <persia> lfaraone: If that's where you need to run maintainer scripts, yes.
[16:48] <persia> (and yes, you want to test that condition)
[16:48] <lfaraone> persia: firing up my VM now :)
[16:49] <lfaraone> persia: /etc/init.d/autokey right now is a python script, it exits -1 if autokey is not installed.
[16:51] <persia> That's not ideal.
[16:51] <lfaraone> okay, it looks like autokey-common's daemon works without -qt or -gtk installed.
[16:51] <lfaraone> persia: How should it handle autokey not being installed?
[16:51] <persia> I think it ought log an error and exit cleanly, personally.
[16:55] <sistpoty|work> policy 9.3.2 supports this, persia ;)
[16:57] <persia> sistpoty|work: Thanks for the pointer.  I'm always happy when policy matches my preferences :)
[16:57] <sistpoty|work> heh
[17:04]  * sebner waves at sistpoty|work and persia :)
[17:04] <sistpoty|work> huhu sebner
[17:10] <\sh> hey sebner
[17:12] <sebner> \sh: heya :)
[17:12] <sebner> sistpoty|work: I don't want to speculate but there a good chances that I passed the exam this time *hrhrhrhr*
[17:12] <sistpoty|work> excellent, sebner!
[17:13] <sebner> sistpoty|work: well, let's wait with that until I'm really sure ;D
[17:13] <sebner> but thx anyways ^^
[17:13] <sistpoty|work> heh
[17:19] <torkel> siretart`: thanks
[17:21] <getxsick> hi
[18:32] <cemc> hey. does anybody have a working 32bit lucid pbuilder on a 64bit karmic host?
[18:57] <hyperair> how does one close multiple bugs in one changelog item?
[18:57] <hyperair> (LP: #1234, #2345)?
[18:57] <hyperair> does that work?
[18:57] <jpds> Should do.
[18:57] <persia> Check the launchpad-closes-bugs: entry in the genererated .changes file to be sure.
[18:57] <jpds> Check the Launchpad-Closed-Bugs fied in the .changes.
[18:59] <hyperair> ah i see.
[18:59] <hyperair> okay, thanks
[18:59] <hyperair> by the way, what's wrong with launchpad's GNOME bug tracker status tracking?
[19:00] <jpds> There's something wrong with it?
[19:00] <persia> I believe it's just not turned on, but ask in #launchpad
=== Caesar_ is now known as Caesar
=== blueyed_ is now known as blueyed
[20:49] <micahg> are we still using u-u-s?
[20:58] <Adri2000> micahg: afaik yes
[21:00] <hggdh> can valgrind run with the libc6 dbgsyms, instead of the libc6.dbg?
[21:35] <RAOF> hggdh: I don't see any reason why not - unless libc6-dbg is a specially rebuilt package, the -dbg package will have the same contents as the -dbgsym package.
[21:39] <persia> micahg: You can, or you can try ubuntu-sponsors : I haven't checked the sponsors report updates yet.
[21:41] <micahg> persia: I subscribed u-u-s, if no one bites by the weekend, I'll poke someone to upload
[21:42] <persia> micahg: For the next 3 months or so, I expect that we'll still be tracking the old queues, just to make sure we don't lose anything.
[21:42] <persia> And I'm not sure we're tracking the new queues yet.
[21:42] <micahg> persia: so, they have combines?
[21:42] <micahg> *combined?
[21:43] <persia> Are in the process of combining, yes.
[21:43]  * micahg needs to catch up on old -devel posts :)
[21:45] <ScottL> i'm trying to add a plymouth-theme to ubuntustudio-look but i'm having trouble trying to get the theme copied to /lib/plymouth/themes
[21:46] <ScottL> can anyone help with my install file?
[21:46] <persia> Please pastebin it.
[21:48] <ScottL> i copied it from the xubuntu theme and it's pretty short
[21:48] <ScottL> it says /lib
[21:49] <persia> Is your package somewhere accessible?
[21:49] <ScottL> it's in my ppa
[21:50] <ScottL> https://launchpad.net/~slavender/+archive/lucid
[21:53] <ScottL> persia, I've got to go pick up my son, i'll be back in a hour
[21:54] <persia> ScottL: Sure.  Take me a while to download and pick at this.  Let me know when you're back.
[21:57] <directhex> okay, how badly have i filed #537691 ?
[21:58] <persia> bug #537691
[21:58] <ubottu> Launchpad bug 537691 in Ubuntu Lucid "[needs-packaging] banshee-community-extensions - community add-ons for Banshee media player" [Undecided,New] https://launchpad.net/bugs/537691
[21:58]  * persia is sure it's terrible
[21:59] <persia> directhex: Should have license info & link to homepage.
[22:00] <hggdh> RAOF: thank you. I will open a bug, tehn , on valgrind, to depend either on the libc6.dbg, or on the equivalent dbgsyms
[22:00] <ajmitch> directhex: did you promise ponies?
[22:00] <directhex> ajmitch, yes. if motu-release likes ponies.
[22:00] <persia> ajmitch: Aren't promises of ponies only required for freeze exceptions?
[22:01] <ajmitch> persia: wouldn't this come in as a freeze exception now?
[22:01] <directhex> persia, it's pretty far past freeze time
[22:01] <persia> It's not milestoned at 10.04, so I thought it was just a standard needs-packaging.
[22:02] <persia> directhex: If you want it, milestone it.  But also put the license and homepage link
[22:02] <directhex> oh, i AM supposed to milestone it
[22:02] <ajmitch> plus motu-release is defunct now afaik, ubuntu-release are the superstars to beg & grovel before
[22:02] <directhex> ajmitch, wiki needs updating. or is it jcastro who needs updating?
[22:02] <sebner> directhex: you need many cookies for them!
[22:02] <directhex> <jcastro> directhex: motu-release
[22:02] <sebner> directhex: they merged
[22:02] <ajmitch> probably both
[22:02] <sebner> directhex: ubuntu-release is good
[22:03]  * ajmitch wants to try out the music store sometime soon
[22:03]  * RAOF , too.
[22:03] <directhex> i can't unsubscribe motu-release, will ubuntu-release get the sub mail?
[22:04] <persia> directhex: Just subscribe both of them.  It will get sorted out.
[22:07] <jcastro> directhex: ajmitch: consider me updated!
[22:08] <ajmitch> jcastro: excellent, now you can avoid leading poor innocents astray :)
[22:10] <persia> jcastro: Just to make sure you're updated on all fronts: we have one release team, one stable release update team, and one sponsors team, for the entire archive.
[22:11] <jcastro> ok, so are you going to put the old teams in lp inside the new teams or just retire them?
[22:13]  * ajmitch wonders why the amd64 buildd seems to be a bit behind
[22:14] <ajmitch> one 'building private source' & the other stuck on gcc, I guess that'd do it
[22:18] <persia> jcastro: Sorry: depends on the teams.  For the smaller teams, we're trying for quick merge.  For the sponsors it'll probably take until July to finish, so we've done team inclusion in the meantime.
[22:18] <jcastro> ok good to know
=== jono_ is now known as jono
[22:39] <lfaraone> persia: hm. I think I have my control file right, but dpkg gives me errors: http://pastebin.com/KNg5cJRP . Do I not understand the "breaks" field properly?
[22:41] <persia> lfaraone: What's your Control: ?
[22:41] <lfaraone> persia: http://sprunge.us/MdeK
[22:42] <persia> lfaraone: autokey should not break itself.
[22:42] <lfaraone> persia: so, that's the issue?
[22:42] <persia> lfaraone: And you want to use (=< 0.61.4)
[22:43] <persia> Ugh.  You need to specify the entire version that breaks, because you're playing with ~
[22:43] <lfaraone> persia: okay, isn't that inclusive of the version I'm shipping?
[22:44] <lfaraone> persia: hm. does ~ have some special meaning in dpkg? (when I really upload these to the archives, it'll be -1 to debian)
[22:45] <persia> ~ means less than nothing.
[22:45] <persia> -0~ is really hard to work with.
[22:45] <persia> So you're breaking yourself because you're playing with odd versions in a PPA.
[22:46] <persia> So set Breaks (=< ) against the currrent version in the archive, not the version you have.
[22:49] <lfaraone> persia: ah, okay, thanks.
=== jono_ is now known as jono
[23:25] <ScottL> jono, an old picture of you in the latest LXF issue, you had long hair!
[23:25] <ScottL> persia, i'm back
[23:25] <jono> ScottL, I heard about this, what is the picture referring to?
[23:27] <persia> ScottL: So, you've run into two completely differently packages packages, which confused you.  Look at setup.py, and extend that to stuff your stuff in the right place.
[23:27] <ScottL> jono, an article on 10 years of LXF, and it's a single page Hall of Fame
[23:27] <lfaraone> persia: okay. now everything installs, but I'm told that "dpkg: error processing /var/cache/apt/archives/autokey-common_0.61.4-0~0karmic~preppa5_all.deb (--unpack):  trying to overwrite '/etc/init.d/autokey', which is also in package autokey 0:0.54.5-1ubuntu0.2". (dpkg log: http://pastebin.com/PuZ1qFrR , changelog: http://sprunge.us/YjQA, control: http://sprunge.us/dUFL)
[23:28] <ScottL> persia, okay, I thought that copying the xubuntu stuff would do it and since I know nada about python I shied away from the setup.py file, but all that aside I will look at it tonight
[23:28] <persia> lfaraone: Did you add a Replaces field to autokey-common to take over that file?
[23:28] <lfaraone> persia: autokey-common "Replaces: autokey (=<0.61.3-1)"
[23:28] <persia> ScottL: The issue is that the very basis of how the xubuntu package works is so different that you can't do it the way they did it.
[23:29] <jono> ScottL, was I in the hall of fame?
[23:30] <ScottL> jono, yes you were, first pictured...congrat! ;)
[23:30] <jono> ScottL, oh my god
[23:31] <jono> if you don't mind me asking, what did it say?
[23:31] <jono> I can't buy it here :(
[23:32] <ScottL> jono, "Jono Bacon - Our resident KDE fan switched to Gnome and joined Canonical.  But which came first?"
[23:32] <ScottL> jono, i'm in the US as well but I have a subscription
[23:39] <jono> ScottL, wow, cool :)
[23:39] <lfaraone> persia: so yes :)
[23:40] <persia> lfaraone: My silence is indicative of a lack of any ideas :)