[01:33] <ScottL_> I'm trying to backport Ardour 2.8.4 to Hardy and I'm getting this in my pbuilder during build:
[01:33] <ScottL_> libcurl4-gnutls-dev: Conflicts: libcurl-dev which is a virtual package.
[01:34] <ScottL_> but libcurl4-gnutls-dev provides libcurl-dev per http://packages.ubuntu.com/hardy/libcurl-dev
[01:34] <ScottL_> any suggestions?
[01:35] <ScottL_> oh, and libcurl-dev is a virtual package I should mention
[01:46] <persia> ScottL: One way to investigate that sort of issue would be to login to a hardy chroot, and try installing each of the build-deps manually to see what packages are actually getting installed (due to virtuals and Provides, these aren't always the packages that one requests).
[01:47] <persia> The goal would be to find out which two packages are actually conflicting (as virtual packages don't really exist, so there's something else present).
[01:47] <persia> Once there, you can either modify the build-depends, or port the code, or otherwise try to reach some conclusion.
[01:52] <ScottL_> persia: geser suggested the same and I did that earlier tonight,  liblrdf0-dev brought in libcurl4-openssl-dev and libcurl4-gnutls-dev but then
[01:53] <ScottL_> vampe-plugin-sdk (my build in ppa) said these packages (and more) were not needed anymore and could be autoremoved
[01:53] <ScottL_> other than that I didn't see any weirdness going on when I installed all the packages
[01:53] <ScottL_> by hand
[01:53] <persia> So, which two packages conflict?
[01:54] <ScottL_> well it was two packages that conflicted with the same virtual package
[01:54] <persia> And probably both provided it :)
[01:54] <persia> Which two?
[01:54] <ScottL_> libcurl4-openssl-dev / libcurl4-gnutls-dev with the virtual package libcurl-dev
[01:55] <ScottL_> ohhh, i understand you now....they both wanted to provide it and hence they conflict...duh
[01:55] <persia> OK.  And I presume you want libcurl4-gnutls-dev because you're working with some code that is GPL without the SSL exception?
[01:56] <ScottL_> the are depends of liblrdf0-dev...i'm not really sure what they are for to be honest...just building Ardour
[01:56] <ScottL_> s/the/they
[01:56] <persia> They are *both* dependencies for liblrdf0-dev?  So liblrdf0-dev cannot be installed?
[01:58] <ScottL_> when I installed liblrdf0-dev by hand in the chroot I believe they both installed as depends
[01:58] <ScottL_> when I run pbuilder it bombs
[01:58] <persia> And you're using the same chroot for pbuilder and checking the install?
[01:59] <ScottL_> aye
[01:59] <persia> OK.  I'm going to encourage you to double-check (based on "I believe they both installed"), because they should either conflict or not.
[02:00] <persia> If they conflict, then the trick is to find a way to work around that.
[02:00] <persia> If they don't, you have more checking to do to find out which packages conflict.
[02:00] <ScottL_> I read about a bug in the buildd system that didn't handle virtual packages very well from 1997, would my pbuilder in Hardy be susceptible as well?
[02:00] <ScottL_> s/1997/2007   LOL
[02:00] <persia> Which bug?  I have a feeling that might be about versioned virtuals.
[02:01] <ScottL_> :( I switch partitions to work on some lucid packaging and I dont' have it up, but might find it again quickly
[02:03] <ScottL_> https://bugs.launchpad.net/soyuz/+bug/335913
[02:04] <persia> That has nothing to do with it.  That has to do with the automated system that retries builds that failed for lack of build-dependencies not automatically retrying them when virtual packages are differently provided.
[02:12] <ScottL_> thanks persia, I'm going to stop for tonight, spend time with the family and work on it tomorrow
[02:14] <persia> ScottL_: OK.  Good luck with the investigation.  The key is understanding precisely what conflicts.  If you can reproduce it with the installation of a single package, that package ought be fixed.  If you can't, then it's just a matter of adjusting ardour's build-depends.
[02:16] <ScottL_> I was change son's diaper (like you needed to know that) and I remember before I hand installed everything
[02:17] <ScottL_> I remember pbuilder given me an error saying that libraptor1-dev was BROKEN: because libcurl4-gnutuls-dev was uninstallable
[02:17] <persia> In that case, it's likely to be a build-depends change.  But go have an evening, and come back when you have time :)
[02:17] <ScottL_> does that help at all?
[02:17] <ScottL_> all right, thanks again for your help
[02:17] <persia> Not without context.  I don't have a mental map of package relationships (and I doubt anyone does), so all I can do is give you strategies to track down the issue.
[03:23]  * persia grumbles at fpc, which won't even make clean unless it's already installed, which makes bootstrapping annoying.
[04:17] <persia> anyone know how to enable RANDR for xvfb?  libwx-perl seems to need it (or to make it not run those tests, but that seems less ideal)
[04:21] <lifeless> persia: no. I can WAG though.
[04:22] <persia> lifeless: Please WAG
[04:23] <lifeless> persia: RANDR, like most extensions, is a server specific thing. So you need to patch the server.
[04:23] <lifeless> persia: xvfb is just a specific server.
[04:23] <lifeless> persia: e.g. I don't think you can just enable it, you need to develop it. That said...
[04:23] <lifeless> PLEASE PLEASE PLEASE do so
[04:24] <persia> That goes a bit beyond the light FTBFS analyses I planned for today :)
[04:25] <persia> But maybe I'll take a look when I finish going through the QA stuff I had planned (although I expect it will take me *lots* of research to learn how)
[04:28] <lifeless> persia: A minimal 'here is the current res, GO AWAY NOW' implementation is probably fairly easy.
[04:29] <persia> lifeless: That does sound like the least difficult implementation, mostly involving lots of stubs.  I'm just not really comfortable with X programming in general (and tend to get confused at that layer), so it's still a bit of research.
[04:29] <lifeless> persia: sure
[04:29] <persia> That said, I did put it on my list, just not ahead of the stuff I know I can do fast and well.
[04:29] <lifeless> persia: perhaps we should make an avo to suck bryce's knowledge next week
[04:31] <persia> heh.  That could work nicely :)
[04:34] <lifeless> its something dx needs.
[04:34] <lifeless> that and opengl
[04:34] <persia> Can't one do openGL with xfvb with mesa?
[04:36] <lifeless> I assume yes in principle
[04:36] <persia> Ah, but it's the construction of the recipe that gets tricky.
[06:07] <kamalmostafa> Hello motu's:  Looks like http://qa.ubuntuwire.com/ftbfs has not updated in 36 hours.  What's up with that?
[06:07] <ScottK> kamalmostafa: There was a bug.  It's been fixed.
[06:07] <ScottK> (and no, I haven't forgotten)
[06:08] <kamalmostafa> :-)  Hi Scott.  Get back to $WORK now.
[06:08] <persia> ScottK: Do you know the schedule for the next run by any chance?
[06:08] <ScottK> I don't.  wgrant would be the one to ask.
[06:08] <persia> Probably 18:00 UTC then.
[06:18]  * wgrant pokes it in the face.
[06:20] <wgrant> It's on 10 */6, FWIW.
[06:20]  * wgrant runs it in screen this time.
[06:26] <micahg> anyone good with bzr merges?
[06:27] <persia> micahg: "bzr merge" meaning merging two branches, or "bzr merge" meaning using bzr to merge stuff between Debian and Ubuntu?
[06:28] <micahg> persia: merging with no common ancestor
[06:28] <micahg> non debian
[06:28] <persia> micahg: You have two bzr branches of the same source with no common ancestor?
[06:28] <micahg> persia: I'm trying to prepare TB3
[06:28] <micahg> TB3.head was a new branch
[06:29] <RAOF> You can't really merge two branches with no common ancestor; bzr will say that every file conflicts.
[06:30] <persia> Well, one can merge, but bzr likely isn't the easiest tool for that.
[06:30] <RAOF> Meld would probably work nicely.
[06:30] <persia> Or, perhaps by using bzr to track the changes whilst you do it with manual patch arrangements.
[06:30] <micahg> files have the same names..
[06:31] <micahg> problem is it's creating a debian and a debian.moved
[06:31] <vish> micahg: as RAOF mentioned even if same name exits , it wont merge... since there is nothing to merge _into_  ... you can setup a new branch
[06:32] <RAOF> Right.  Because it finds that both branches have entirely unrelated directories named “debian”, so it has to move one out of the way; you can't have both.
[06:32] <micahg> I can't force it to try to merge?
[06:32] <RAOF> Not as far as I'm aware.
[06:33] <RAOF> I've asked this before, many months ago.  It's possible that there's now some way to do it, but at the time there wasn't.
[06:34] <RAOF> The problem you're hitting is that bzr has an inode-like concept - the filename *isn't* what bzr uses to identify a file by (presumably because otherwise two people adding two separate 'foo' files could get messy).
[06:34] <persia> To force it, create an (empty) common ancestor.
[06:34] <persia> merge each tree into a new tree off the common ancestor
[06:34] <persia> Then merge those tress.
[06:34] <persia> But everything will conflict.
[06:40] <Hobbsee> !staff
[06:40] <Hobbsee> (hitting #ubuntu-women again)
[06:40] <Hobbsee> cheers
[07:34] <wgrant> kamalmostafa, ScottK, persia: Turns out the script was working fine, but some symlink shuffling went wrong. It's fixed and updated now.
[07:35] <persia> wgrant: Thanks.
[07:50] <siretart> mr_pouit: yes, I am interested. please send the patch to the pkg-multimedia-maintainers mailing list!
[07:50] <ScottK> wgrant: Sounds great.
[07:50] <siretart> morning, folks
[11:44] <mr_pouit> siretart: ok, done
[12:24] <ahe> someone here who could review the new version of my package http://revu.ubuntuwire.com/p/rubyripper , please?
[13:39] <lfaraone_> If the post-removal scripts of a package fails, will the post-removal scripts of the package that is going to replace it be used instead?
[13:41] <geser> yes, called with failed-upgrade; see http://women.debian.org/wiki/English/MaintainerScripts
[13:42] <lfaraone> geser; okay, i uploaded a sru with a fixed prerm, but fqiled to inckude that.
[13:57] <xteejx> Hi, I'm totally new to packging, I have read the Packaging Guides, and think I can just about get my head around it. Is the proceudr
[13:57] <xteejx> ... procedure the same for games that I want to package even if they're on PlayDeb?
[14:05] <persia> Maybe?
[14:05] <persia> I don't know much about playdeb, but I do know a fair bit about the Debian/Ubuntu Games team.
[14:06] <persia> So, if you want to package stuff, I'd be happy to help you get stuff there.
[14:20] <jariq> Could anyone please review packages ipwatchd - http://revu.ubuntuwire.com/p/ipwatchd - and ipwatchd-gnotify - http://revu.ubuntuwire.com/p/ipwatchd-gnotify . Just one more advocation needed :)
[14:34] <xteejx> persia: You were a great help last time, so if you could help I'd appreciate it :)
[14:35] <persia> xteejx: OK.  You've picked out a game already?
[14:35] <xteejx> I have 1 or 2 in mind, I'll settle on 1 hang on :)
[14:36] <iulian> jariq: Just out of curiosity.  Have you considered getting it into Debian?
[14:36] <xteejx> persia: I was looking at spacejunk http://spacejunk.sourceforge.net/
[14:36] <xteejx> It's not a PlayDeb one, I think that's something for another time when I've learned the ins and outs
[14:37] <persia> Well, I tend to think that it's just as easy to push to Debian as playdeb, if you did it right :)
[14:37] <jariq> iulian: well i've created package for ubuntu, submited to revu and then I've found info about debian syncing few days later..
[14:37] <persia> But anyway.
[14:38] <xteejx> persia: Are you sure you don't mind helping?
[14:38] <persia> xteejx: My first recommendation is to investigate the licensing and copyright of the source.  licensecheck and suspicious-source are good tools for that.
[14:38] <persia> Not at all.
[14:39] <persia> You'll want to make sure that you can distribute the packaging, and that all the files are appropriately licensed.
[14:39] <xteejx> persia: I've looked at the source it appears to be GPL3
[14:39] <xteejx> Not sure about all files though
[14:39] <persia> Lots of things do :)  One has to look at *each* file in the upstream tarball.
[14:39] <iulian> jariq: Ah-ha, OK.  It'd be nice to see it in Debian as well.
[14:39] <xteejx> oh right
[14:39] <persia> (Yes, this is painful and annoying: I think it's the hardest part of packaging)
[14:40] <xteejx> persia: Where can I get licensecheck and suspicious-source?
[14:40] <iulian> jariq: I will review it either later on or tomorrow.
[14:40] <lfaraone> xteejx: devscripts
[14:40] <persia> xteejx: devscripts and ubuntu-dev-tools
[14:41] <xteejx> ok
[14:41] <jariq> iulian: Thanx.
[14:42] <lfaraone> Hm. Why does suspicious-source flag on .py and .js files?
[14:42] <persia> lfaraone: Either there's a bug, or something is funny about those files.
[14:43] <persia> (if it's a bug, filing and fixing it would be appreciated)
[14:43] <iulian> jariq: Anyway, please do consider getting it in Debian as well.  I can give you a hand with it and guide you through the processes, even though I'm not a Debian developer.
[14:46] <lfaraone> persia: well, the files don't have GNU license headers, but other than that they're normal files...
[14:46] <persia> lfaraone: Do they have some other sort of license header?
[14:47] <lfaraone> persia: no.
[14:47] <persia> That's likely the issue then.
[14:47] <persia> (but check the suspicious-source source to be sure)
[14:47] <xteejx> persia: I'm not sure about the licensing of this one
[14:47] <persia> My understanding is that suspicious-source tries to find anything that might not be licensed, or might be binary, and flags it.
[14:48] <xteejx> persia: http://paste.ubuntu.com/361975/
[14:49] <xteejx> I'm not too sure, there are several licenses
[14:49] <jariq> iulian: I am definitely planning to do so and I am going to install debian on my dev machine next week. From what I've read so far I believe there won't be any problems because process seems to be almost identical to ubuntu's.
[14:49] <persia> xteejx: Well, investigate the "NO COPYRIGHT* and "UNKNOWN" bits, one-by-one.  There's no issue mixing GPL, LGPL, and BSD, so long as the collection is GPL.
[14:50] <xteejx> persia: Yeah the source is distributed under GPL3
[14:50] <lfaraone> xteejx: but you have to check whether upstream knows what they're doing, and didn't include other-sourced-code.
[14:50] <lfaraone> *other-licened-code
[14:50] <persia> xteejx: Also, I'll recommend you run `licensecheck --copyright -r .` rather than `licensecheck *` to make sure to catch subdirectories (and the output is nicer)
[14:50] <xteejx> persia: Ok, I'll do that :)
[14:51] <iulian> jariq: Yes indeed.
[14:51] <lfaraone> persia: I'm looking at the source of http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/ubuntu-dev-tools/karmic/annotate/head%3A/suspicious-source , and although I'm not too savvy at find, I don't see it doing anything that would cause the behavior I'm seeing.
[14:52] <persia> Well, the .js files just aren't listed in FILES (this would be an easy fix).
[14:52] <persia> But I don't have any explanation for the .py files.
[14:52] <lfaraone> persia: yeah...
[14:54] <persia> Maybe try with `set -x` ?
[14:56] <lfaraone> persia: it ends up running "find '!' '(' -name '*.h' -o -name '*.c' -o -name '*.cc' -o -name '*.cpp' -o -name extractDoc.py -o -name setup.py -o -name '*.sh' -o -name '*.txt' -o -name '*.text' -o -name '*.3' -o -name '*.m4' -o -name '*.xml' -o -name '*.html' -o -name '*.php' -o -name '*.php3' -o -name '*.php4' -o -name '*.class' -o -name '*.form' -o -name '*.module' -o -name '*.cfg' -o -name '*.conf' -o -name '*.config' -o -name '*.odt' -o -name
[14:57] <lfaraone> (was that cut off?)
[14:58] <persia> It was, but did it include "-o -name '*.py'" ?
[15:02] <lfaraone> persia: no, and I can't figure out why.
[15:02] <xteejx> persia: All done, the Unknown are copyrighted, and the no copyright ones had no Copyright information at all, just source
[15:02] <lfaraone> persia: "extractDoc.py" and "setup.py" are files in the root of the tree
[15:04] <persia> I *think* that the find command is excluding all the stuff that matches the -o -name rules.
[15:04] <xteejx> persia: The sge files are copyrighted, the others aren't
[15:04] <persia> (-o is logical-OR, -name means apply the following glob to file names)
[15:04] <persia> xteejx: So, is there anything that is copyrighted, but not licensed, or anything that is not copyrighted but appears to contain significant content?
[15:05] <xteejx> persia: Not that I can see, no.
[15:05] <xteejx> Everything copyrighted is licensed, and the ones that aren't are mkbin / mkinstaller files
[15:07] <lfaraone> persia: okay. I wonder why it expands the * on .py files
[15:08] <persia> lfaraone: I'm not sure at all.
[15:08] <persia> xteejx: Excellent.
[15:09] <xteejx> persia: So everything copyrighted must be licensed, and GPL, LPGL and BSD licenses are safe to work together as long as they're GPL licensed 'together' ? Is that right?
[15:09] <lfaraone> persia: so it's definently a bug?
[15:09] <persia> xteejx: So, unpack the source (you've probably done this), and create a debian/ directory inside.  Document your copyright findings in debian/copyright.  `echo 7 > debian/compat`, `cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules`, and `dch --create` to do most of the packaging.
[15:09] <lfaraone> ls
[15:09] <persia> xteejx: And everything significant must be copyrighted, but otherwise, yes.
[15:09] <xteejx> persia: Can I use dh_make to do this?
[15:10] <persia> lfaraone: Well, if there are sources you don't think are suspicious showing up in suspicious-source, then yes.
[15:14] <persia> xteejx: dh_make adds lots of example files you have to remove, and I don't tend to find the way it writes rules files easy.  It's a handy tool to explain a lot of the ways things work, but, in my opinion, useless when creating a package.
[15:14] <xteejx> ahh ok
[15:15] <lfaraone> persia: I'm curious, does the latest version of debhelper automagically handle python packages without manual rule tweaking?
[15:15] <persia> lfaraone: It's my understanding that it does, for the 90% case, with rules.tiny
[15:16] <lfaraone> persia: so should I convert my existing, working cdbs-based packages to it?
[15:16] <lfaraone> persia: i'm still fuzzy on the main advantage of dh7 over cdbs.
[15:16] <persia> But I don't tend to do python packaging, so my recommendation would be either try it or laboriously dig through debian-python's VCS to see examples of what has been done.
[15:17] <persia> lfaraone: The main advantages of dh7 over cdbs for me are 1) the sequences are better documented, 2) overriding stuff is lots easier, and 3) it installs changelogs properly
[15:19] <persia> lfaraone: So, I haven't converted my packages (although I probably will at some point, for consistency), but for new packaging I only use dh(1)
[15:37] <xteejx> persia: Still here? I think this should be ok for the debian/copyright http://paste.ubuntu.com/362007/
[15:38] <persia> xteejx: You need to include the 3-paragraph GPL header, the 3-paragraph LGPL header, and the entire text of the CC licenses.
[15:38] <xteejx> persia: What about the BSD?
[15:39] <persia> xteejx: Also, be aware that cc-nc-by-sa fails DFSG #6 (http://www.debian.org/social_contract#guidelines), which makes this non-free/multiverse
[15:40] <xteejx> persia: I thought cc-nc-sa would be ok to use...share-alike ?
[15:40] <persia> xteejx: You need the entirety of any BSD-style licenses, unless they are the current BSD as distributed by the Regents of the University of California (and the code is copyrighted by the Regents of the University of California).  I just didn't see the BSD references in your draft.
[15:41] <persia> xteejx: Issue is the "nc" bit: discriminates against commercial use.  One can't sell a CD containing it, or include it in a saleable product.
[15:41] <persia> (well, one can sell such a CD, but needs to go through annoying machinations to do so)
[15:41] <xteejx> persia: but Ubuntu is 'free', and it would be in Universe, so that would bypass that wouldn't it?
[15:46] <persia> xteejx: Ubuntu may be free or may be sold (with certain limitations).
[15:46] <xteejx> persia: So, this project is not a possibility without consent?
[15:46] <persia> Mind you, there's a inherent price limit in it also being available without cost, but there's no limit to commercial application.
[15:47] <persia> It's possible, it's just non-free in Debian, and multiverse in Ubuntu.  No reason not to package.
[15:47] <xteejx> persia: I see :) I got worried there
[15:47] <persia> Once packaging is done, it's worth asking upstream about it, but it's not that important.
[15:50] <ahe> until when are new packages are allowed to enter lucid?
[15:55] <xteejx> persia: Is this better? If I missed anything let me know :) http://paste.ubuntu.com/362016/
[15:55] <persia> ahe: FeatureFreeze is the typical deadline.
[15:57] <persia> xteejx: I'd prefer the complete text of the CC licenses be in debian/copyright (even though this duplicates text in the source), and only ship debian/copyright to end users, rather than needing to ship several license files (because this compresses better).
[15:57] <persia> xteejx: For GPL and LGPL, you need the text from the "How to use this license" section in each license.
[15:58] <persia> The BST stuff looks OK, although please don't call it "The BSD license" because it isn't.  It's the Guichan license, with almost the same text as the BSD license.
[15:58] <persia> s/BST/BSD/
[15:58] <xteejx> So having a REALLY long License: section is ok?
[15:58] <xteejx> persia: I didn't realise
[15:58] <persia> I'd recommend something like "The files int he guichan/ folder are subject to the following license: ..."
[15:58] <persia> Yes.  No limit to debian/copyright size, as long as it's complete.
[15:58] <persia> One large text file will compress better than several small ones.
[15:59] <xteejx> Ok, so copying and pasting the full licenses into it and formatting them correctly is ok?
[16:00] <persia> For licenses that appear (verbatim) in /usr/share/common-licenses, it's OK to just put the little headers one puts in source files, and then reference the common-license, but otherwise, yes.
[16:18] <shadeslayer> hi can someone help me with a bit pf packaging?
[16:19] <persia> shadeslayer: Sure, but I'd prefer to help you with packaging targeted at Ubuntu than at a PPA, if you're up for that.
[16:20] <shadeslayer> persia: um i actually was aiming finally at a PPA
[16:20] <shadeslayer> persia: whats the difference though?
[16:20] <persia> Yeah, I saw from identi.ca and #kubutnu-devel :)
[16:20] <shadeslayer> persia: lol :)
[16:21] <persia> Differences are mostly 1) we try to get things right, rather than mostly right for distro work, and 2) we tend to work more collaboratively
[16:21] <shadeslayer> and btw yayy... kde 4.4 rc2 out in a few hours
[16:21] <persia> Well, there's also freezes and stuff, but that's not usually directly related to packaging.
[16:21] <shadeslayer> persia: theres no difference as to building steps?
[16:22] <persia> shadeslayer: Aside from where the final upload happens, no.
[16:22] <shadeslayer> persia: so the PPA's accept .debs too?
[16:23] <persia> No, but we don't produce .debs.
[16:23] <persia> I once suggested that all of Ubuntu could be replaced with three PPAs.  People didn't like the idea, but the concepts are similar.
[16:24] <shadeslayer> persia: i think there should be just 2 repos : free and non-free
[16:24] <shadeslayer> much easier to remember :P
[16:24] <shadeslayer> keep everything else like betas and stuff to PPA
[16:25] <persia> My three were "free", "restricted software", and "restricted data", because there's lots of interesting data that doesn't grant the freedom to modify.
[16:25] <shadeslayer> persia: anyways i was here : https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging from Scratch
[16:25] <persia> OK.  That's the long-winded version :)
[16:25] <persia> Did you already pick out your software?
[16:25] <shadeslayer> persia: yep
[16:26] <persia> First step: check the licensing :)
[16:26] <shadeslayer> persia: its a kopete plugin for facebook alot of people are demanding it :P
[16:26] <persia> (yes, this means check every file).
[16:26] <shadeslayer> persia: :o
[16:26] <persia> I know, but it's important, as otherwise you can't be sure that you have permission to modify and redistribute.
[16:26] <hyperair> persia: why three "PPAs"?
[16:26] <shadeslayer> persia: one sec,which is preferred a point release or the current git version?
[16:26] <persia> hyperair: "main", "restricted-software", "restricted-data".
[16:27] <persia> shadeslayer: I prefer actual releases, personally.
[16:27] <hyperair> if you used PPAs as the main repository, then it'd still be that, the main repository.
[16:27] <jpds> shadeslayer: It's there a kopete-facebook package?
[16:27] <jpds> Isn't*
[16:27] <persia> If there's some cool stuff in git, extract and apply as patches.
[16:27] <shadeslayer> jpds: yeah its outdated
[16:27] <persia> hyperair: Right.  It's just an implementation thing.
[16:27] <hyperair> ah
[16:28] <persia> (and I no longer believe that three PPAs solves the issue, it was just an offhand comment during one of the ArchiveReorganisation discussions)
[16:28] <shadeslayer> persia: brb in a few secs
[16:31] <shadeslayer> unfourtunately im also involved in : http://mstc.tk/ : :P
[16:31] <shadeslayer> persia: lemme download their release
[16:32] <kamalmostafa> Is there any way I can run a test build on sparc and/or powerpc for a Lucid package?
[16:32] <persia> kamalmostafa: Get a sparc and/or powerpc :)
[16:32] <persia> But I have a powerpc.  Which package?
[16:33] <kamalmostafa> (I'm working on an amd64 machine!)...  Aw persia, you beat me to my correction!  ;-)
[16:33] <kamalmostafa> The package is libexplain, but it needs fixes (separate fixes) for sparc and powerpc.
[16:33] <shadeslayer> persia: next step?
[16:34] <shadeslayer> (i have the tarball
[16:34] <persia> kamalmostafa: Well, if you give me a .dsc, I'm up for running test-builds.
[16:34] <persia> shadeslayer: Unpack the source, create a debian/ folder, and document your copyright research in debian/copyright
[16:35] <kamalmostafa> persia: okay thanks.  I haven't actually tried fixing the problems yet -- just planning how I would test it if I did.  I'll holler for you when/if I need a powerpc test build.
[16:35] <persia> kamalmostafa: Just ask here (or in #ubuntu-powerpc) if someone can run a lucid test build.
[16:36] <persia> There's a few of us with various architectures.
[16:36] <shadeslayer> persia: what if a header file doesnt have the GPL?
[16:36] <persia> shadeslayer: What license does it have?
[16:36] <shadeslayer> persia: none at all
[16:37] <persia> Well, unless you're in Nicaragua or Honduras, that means that the author reserves all rights of copyright, so you can't distribute.
[16:37] <shadeslayer> persia: some of the files dont have the license but the COPYING file says GPL
[16:38] <shadeslayer> persia: what now? :P
[16:38] <persia> shadeslayer: COPYING is there to meet the "You should have received a copy of the GPL with this" bit, not to declare everythign GPL.
[16:38] <persia> shadeslayer: Talk to upstream about the issues.
[16:38] <shadeslayer> persia: um : Kopete facebook plugin is licensed under the GNU General Public License
[16:38] <persia> shadeslayer: If upstream didn't license GPL because they wanted open headers, suggest an ISC (or similar) license for the headers, and GPL for the code.
[16:39] <persia> Apparently some of the header files aren't.
[16:39] <shadeslayer> persia: http://pastebin.com/f19ec20db
[16:40] <persia> shadeslayer: I understand.  Please read the "How to use the GPL" section (at the bottom of the GPL), check the header files that don't have headers again, and explain to upstream.
[16:40] <persia> Alternately, explain to me if you're *really* sure they aren't required, but I believe them to be (outside Nicaragua and Honduras)
[16:42] <shadeslayer> persia: well i think the author simply forgot about applying the license to header files since the .cpp's are all licensed and the project is freely available on git
[16:42] <persia> shadeslayer: I think you're right, and I suspect the author would very much appreciate a patch adding the license headers and apply it in git with alacrity :)
[16:42] <shadeslayer> persia: also the the 5th line of the pastebin states all header files are licensed under GPL
[16:43] <persia> Right, but, at least from my reading of "How to use the GPL", it wasn't done according to the guidelines.
[16:43] <persia> I'm not sure how it might get argued in court, but I tend to be extra conservative, as I'd rather never find out.
[16:43] <shadeslayer> persia: you mean this : http://www.gnu.org/licenses/gpl-howto.html
[16:44] <persia> Actually, I meant the stuff at the bottom of COPYING, but the content isn't that different.
[16:45] <persia> http://www.gnu.org/licenses/gpl-3.0.html#howto seems to be a webified version of what I was referencing.
[16:45] <shadeslayer> so i guess no packaging lessons for me :P
[16:46] <persia> I didn't say that.  Checking and documenting copyright is the first step.
[16:46] <shadeslayer> persia: hmm well if the licensing isnt right we cant package it right?
[16:46] <persia> You've done half of that, and part of your packaging is to contact upstream and discuss it with them.
[16:46] <persia> You can package it, you just don't necessarily have permission to distribute it.
[16:47] <shadeslayer> persia: hehe :)
[16:47] <persia> Was it I packaging it, I'd do all the work, and keep a copy on my hard drive to finish up once I heard back from upstream.
[16:47] <shadeslayer> persia: thats what i was thinking ><
[16:48] <persia> So, put together a debian/copyright (noting which files are unlicensed, and what license applies to the rest, etc.).
[16:48] <persia> And when you're done, ask for the next steps.
[16:48] <xteejx> persia: This should be ok now http://paste.ubuntu.com/362045/
[16:49] <persia> xteejx: You still don't have the three-paragraph header for the GPL-3 stuff (see the last link I posted)
[16:49] <persia> xteejx: You're still calling the guichan license the "BSD" license, and it's not.
[16:49] <xteejx> persia: That's what is in its own copying file
[16:50] <persia> xteejx: Yes, but the idea is to put all the copyright information in one file, rather than distributing lots of files to end users.
[16:50] <xteejx> So, even though they *state* it's BSD, it really isn't, so just remove the BSD wording?
[16:50] <persia> xteejx: Also, I see cc-nc-by-sa, but I thought there was also some cc-by-sa (not NC) stuff, wasn't there?
[16:51] <persia> xteejx: Yep.  They got it wrong.  It can't be "The BSD license" unless copyright on the work is held by the Regents of the University of California.  Most people are lazy though, and prefer to say "BSD License" rather than "BSD license with ownership changes" or some similar, longer, phrase.
[16:51] <xteejx> persia: The Creative Commons Attribution-Share Alike license and the Creative Commons Attribution-Noncommercial-Share Alike license are there
[16:51] <xteejx> persia: I see
[16:52]  * persia looks harder, having thought there was only one.
[16:52] <persia> Right.  Sorry.  I see them both now.  They're so similar, I got confused reading them :)
[16:52] <xteejx> hehe
[16:53] <persia> So it's just adding the three paragraphs for each of GPL and LGPL, and dropping the "(BSD)" bit from the guichan license.
[16:53] <xteejx> persia: One last thing abut the GPL3 thing.....which parts have to be copied, I can't see any "how to use" section, or is it just the header?
[16:53] <xteejx> which paragraphs? Sorry
[16:53] <persia> xteejx: At the very bottom of the GPL, there should be a "How to use" section.  http://www.gnu.org/licenses/gpl-3.0.html#howto seems to be a webified version of the same thing, and describes the paragraphs.
[16:54] <shadeslayer> persia: ok can you just tell me to package it,ive sent a message to the dev about the GPL license
[16:54] <xteejx> persia: There's a 'How to Apply These Terms to Your New Programs' section...is that it?
[16:54] <persia> xteejx: Yep,  Those paragraphs.
[16:54] <xteejx> I see it now....it's so small!! Thanks :)
[16:54] <persia> shadeslayer: The next step is debian/copyright (which xteej is also working on right now).
[16:55] <persia> shadeslayer: Basically, just document everything in that file.
[16:57] <shadeslayer> persia: ok so i create : a folder debain with a text file called copyright and put what in it?
[16:57] <persia> shadeslayer: There's two formats that are widespread.  One is documented at http://dep.debian.net/deps/dep5/ and the other at http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[16:58] <xteejx> persia: All done 100% now http://paste.ubuntu.com/362052/ :)
[16:58] <persia> Pick whichever one seems easier to you :)
[16:58] <xteejx> persia: I see what you meant about this being quite a difficult bit!!
[16:58] <persia> Yep.  It's the hardest part, which is why I like to do it first.  Nothing is more annoying than packaging something and discovering one can't distribute.
[16:59] <shadeslayer> persia: i choose the second one :)
[16:59] <persia> shadeslayer: OK.  Go for it :)
[16:59] <shadeslayer> persia: hehe VICTIMS NAME :P
[16:59] <persia> xteejx: Did you already run all the other commands I listed to set up the boilerplate packaging?
[17:00] <xteejx> persia: Well thankfully it's done, so now I have debian/compat and copyright
[17:00] <shadeslayer> persia: btw theres already one package maintainer with ubuntu,should i put his name or mine?
[17:00] <persia> Next is rules (copy from /usr/share/doc/debhelper/examples/rules.tiny) and changelog (create a new one with dch --create)
[17:00] <persia> shadeslayer: Already working on this package?
[17:00] <xteejx> persia: Ok :)
[17:01] <shadeslayer> persia: i mean someone already created a .deb which is in repo
[17:01] <persia> shadeslayer: So you're not packaging something new, but just want to modify a package?
[17:01] <shadeslayer> persia: its a new version actually
[17:02] <shadeslayer> persia: theres already 0.1.4-0ubuntu1.1
[17:02] <shadeslayer> !info kopete-facebook
[17:02] <shadeslayer> persia: and i have 0.1.5
[17:02] <persia> shadeslayer: OK.  Go back to #kubuntu-devel, and ask "How I can help get a new version of ${whatever} into the repositories?".  You don't need to learn how to package something, but how to work with the kubuntu-ninjas to keep everything up to date.
[17:03] <shadeslayer> persia: well actually i want to start from scratch about building packages... not from the middle :)
[17:03] <xteejx> persia: I set version to 1.0.1-0ubuntu1, as its not in Debian and upstream version is 1.0.1
[17:03] <xteejx> persia: Is that correct?
[17:03] <persia> xteejx: That works for now.
[17:03] <xteejx> release = lucid?
[17:04] <persia> shadeslayer: I actually recommend starting in the middle.  It's a lot easier to make an impact by learning how to make small changes, and fixing lots of packages than to learn how to package new stuff (which can take months to get in).
[17:04] <xteejx> I'm a triager and use Lucid for testing anyway
[17:04] <persia> xteejx: Yep, lucid would be good.
[17:04] <shadeslayer> persia: hmm well atleast theres some activity there now :)
[17:05] <persia> shadeslayer: Also, by getting involved with the team, you'll get lots more experience working with them than by working on your own looking at random generic advice on how to package.
[17:05] <shadeslayer> persia: hehe... i just asked there :)
[17:05] <xteejx> persia: changelog created
[17:05] <shadeslayer> persia: btw whats your identi.ca URL?
[17:06] <persia> shadeslayer: No idea.  My nick is persia, but I only very rarely post anything.
[17:06] <xteejx> http://paste.ubuntu.com/362056/
[17:06] <persia> xteejx: OK, so you have copyright, compat, rules, and changelog?
[17:06] <shadeslayer> persia: no problem :)
[17:06] <xteejx> persia: Yup :)
[17:06] <persia> Cool.  Next up: debian/watch
[17:06] <persia> man uscan to read all about it.
[17:06] <xteejx> Me?
[17:07] <persia> Yep.
[17:07] <xteejx> Great!? lol :)
[17:08] <xteejx> Bloody hell I didn't know that could do that!!
[17:08] <persia> Nice, isn't it :)
[17:08] <xteejx> Very handy!
[17:08] <persia> Sometimes I do watch first, but copyright is the hard part, and most people already downloaded something they want to package.
[17:08] <xteejx> just need to read now heh
[17:10] <shadeslayer> persia: wanna help me out in kubuntu-devel?
[17:10] <persia> shadeslayer: I'm not familiar with the Kubuntu Ninja's workflows, which is why I sent you there.
[17:10] <shadeslayer> ah ok
[17:11] <persia> s/\'s/s\'/
[17:11] <dupondje> https://bugs.launchpad.net/ubuntu/+source/synce-sync-engine/+bug/511986 => how to make it seen by people that can do this ? :D
[17:11] <xteejx> persia: This is very confusing
[17:11] <persia> dupondje: What's holding it out of debian/testing?
[17:11] <shadeslayer> dupondje: its already public
[17:12] <persia> xteejx: https://wiki.ubuntu.com/PackagingGuide/Complete#Creating%20and%20Using%20a%20debian/watch%20File might provide more examples.
[17:12] <xteejx> Thanks persia :)
[17:13] <dupondje> persia: think slowlyness :D
[17:14] <persia> dupondje: Is it in unstable already?
[17:14] <dupondje> persia: nope
[17:14] <persia> Are you part of upstream?
[17:15] <dupondje> only user
[17:15] <dupondje> could do a bugreport on debian to get new version into unstable :)
[17:15] <persia> Please do, and link the Ubuntu bug to the Debian bug.
[17:16] <persia> We *can* put in a newer version, but since we have yet to hit DebianImportFreeze, it's better to work through Debian right now (as opposed to after freeze, when it's best to work in parallel).
[17:26] <sebner> dupondje: we don't sync from private PPA's btw
[17:26] <xteejx> persia: I can't work out how to do the watch file for a sourceforge project....
[17:26] <dupondje> sebner: I know its not a 'real sync', but it can be used as a start right ? :)
[17:27] <sebner> dupondje: depending on the quality ;) but as persia pointed out, getting it into Debian first and then sync to ubuntu is the prefered way
[17:28] <persia> xteejx: There's a special syntax.  Look at the examples in the uscan man page.
[17:28] <xteejx> persia: I have... its really difficult :(
[17:29] <xteejx> I'm still trying though
[17:34] <xteejx> persia: Got it!!!!
[17:35] <persia> xteejx: Excellent.  Now for the last bit to tie it together, and call it packaged (mind you, the package may be buggy, but it will be a package), debian/control
[17:35] <xteejx> persia: Ok...
[17:36] <persia> So, open your favorite text editor and open http://www.debian.org/doc/debian-policy/ch-controlfields.html in a browser
[17:36] <xteejx> yup
[17:36] <persia> Starting from Source: go through each field, read about what it does, and add the right entry.
[17:36] <xteejx> hey micahg
[17:36] <xteejx> persia: Ok, I'll try :)
[17:36] <persia> Put a blank line between the Source and Package sections (and each additional Package section if you have lots of them).
[17:37] <dupondje> did a bugreport into debian :)
[17:37] <shadeslayer> persia: btw whats a good page to learn packaging ive been empty for the past hour :P
[17:37] <runasand> shadeslayer: https://wiki.ubuntu.com/PackagingGuide
[17:38] <shadeslayer> runasand: i am reading that but persia said that was a pretty long wiki
[17:38] <persia> shadeslayer: Or read backscroll, as xteej is packaging something now :)
[17:38] <runasand> shadeslayer: sure, but there's lots of useful info in it :)
[17:38] <shadeslayer> runasand: ok
[17:38] <persia> Indeed.  It's full of useful info.  It's just long :)
[17:39] <shadeslayer> persia: i would rather read the wiki,since i cant read the backscroll ( just too lazy :P )
[17:39] <persia> OK.
[17:40] <shadeslayer> runasand: can you help with  A specific version of a package can be selected for installation by following the package name with an equals and the
[17:40] <shadeslayer>            version of the package to select. This will cause that version to be located and selected for install. Alternatively
[17:40] <shadeslayer>            a specific distribution can be selected by following the package name with a slash and the version of the
[17:40] <shadeslayer>            distribution or the Archive name (stable, testing, unstable).
[17:40] <shadeslayer> oh crap ..
[17:40] <xteejx> persia: What do I put in for build-depends, the source depends on sdl that's all
[17:40] <persia> xteejx: I suddenly think I wasn't clear: only the stuff in section 5.2 matters.
[17:40] <runasand> shadeslayer: sorry? what do you need help with?
[17:41] <shadeslayer> runasand: https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging from Scratch << stuck at 4th command
[17:41] <xteejx> persia: That's ok, I guessed :)
[17:41] <shadeslayer> runasand: yeah apparently the url didnt get copied :P
[17:41] <persia> xteejx: That's the idea :)  If you get it wrong, the package fails to build, and you can fix it :)
[17:41] <xteejx> hmmmm apt-cahce search sdl methinks
[17:41] <randomaction> shadeslayer: there was also a great session last UDW: https://wiki.ubuntu.com/MeetingLogs/devweek0909/PkgFromScratch
[17:41] <persia> xteejx: Also put "debhelper (>= 7)" in your build-deps.
[17:41] <runasand> shadeslayer: but what have you done so far?
[17:42] <shadeslayer> runasand: does it mean the tarball i downloaded via ftp?
[17:42] <xteejx> persia: What's the $sh:Depends thing I've seen before?
[17:42] <shadeslayer> runasand: all the commands before that command :P
[17:42] <shadeslayer> runasand: i did attend that session last time :)
[17:42] <persia> ${shlibs:Depends}?  You probably also want ${misc:Depends}.
[17:42] <runasand> shadeslayer: https://wiki.ubuntu.com/PackagingGuide/Complete#Getting%20Started -- start there ;)
[17:42] <shadeslayer> (didnt learn properly though )
[17:42] <xteejx> ok
[17:43] <runasand> shadeslayer: you can't really skip any steps if you want to learn it properly. Take your time and read everything :)
[17:43] <shadeslayer> runasand: as i said i did everything before that.. cmake,make etc
[17:43] <runasand> shadeslayer: so, which command are having problems with and what exactly is the problem?
[17:44] <shadeslayer> runasand: mkdir hello-2.4 << and the next one,does it mean that i need to extract the ftp download to this folder?
[17:44] <runasand> shadeslayer: have you actually downloaded the source for hello?
[17:44] <shadeslayer> runasand: see the 3rd command in that section
[17:45] <xteejx> persia: I'm not sure what to use for sdl... I could trial and error I guess....also what is the Standards-Version?
[17:45] <runasand> shadeslayer: if not, then that's what you need to do :)
[17:45] <shadeslayer> runasand: yeah as it says in : https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging from Scratch
[17:45] <persia> xteejx: Check which version of debian-policy is installed in lucid, and use the first three digits.
[17:45] <xteejx> persia: No probs
[17:45] <runasand> shadeslayer: if you already have the software, then there's no need to download it again
[17:46] <persia> For SDL, I'd probably use libsdl1.2-dev
[17:46] <persia> (but you may want more modules: `apt-cache search sdl dev` shows mostly development libraries)
[17:46] <shadeslayer> runasand: oh ok
[17:46] <xteejx> persia: I thought libsdl1.2 as well
[17:47] <persia> But it also doesn't matter: if you forget something, it will fail to build, and you can add it later (that's why I say this creates a buggy package, and then we get to fix bugs).
[17:47] <xteejx> Build-Depends: ${misc:Depends}    <  Do I put a comma after or whitespace between depends
[17:47] <xteejx> ?
[17:47] <shadeslayer> runasand: from where do i start after using apt-get source?
[17:47] <persia> xteejx: You generally want to build-depend on -dev packages, and let them decide if they need the libraries, or just headers.  It depends on the library.
[17:47] <runasand> shadeslayer: I thought you said you'd already run 'make' and friends?
[17:47] <persia> xteejx: ${shlibs:Depends} and ${misc:Depends} belong in Depends: not in Build-Depends.
[17:48] <persia> And separate with commas.
[17:48] <shadeslayer> runasand: eh? i told you that i knew about make
[17:48] <xteejx> persia: Ahh ok...won't the -dev cause problems when a .deb is made?
[17:48] <persia> Why?
[17:48] <runasand> shadeslayer: after you've downloaded the software you want to package, you need to run a command to create the debian directory
[17:48] <runasand> shadeslayer: that command is dh_make
[17:48] <xteejx> Also, it tells me I needed 2 paragraphs 1 for source, 1 for binary, or is that wrong?
[17:48] <shadeslayer> runasand: ok
[17:48] <persia> You need the -dev to build.  That might cause some dependency to be defined in ${shlibs:Depends}, which then goes to the deb.
[17:49] <runasand> shadeslayer: this is all in the wiki, you know :)
[17:49] <xteejx> persia: Ohhhhh I see
[17:49] <persia> xteejx: That's right.  Starting from "Source" is the source paragraph, and starting from "Package" is the binary paragraph.
[17:50] <shadeslayer> runasand: ok found it,thanks :)
[17:50] <xteejx> persia: I don't see how there will be any difference between the two...?
[17:50] <persia> xteejx: If there are lines that would be duplicate, don't bother adding them to the binary section.
[17:50] <xteejx> persia: Ok, makes sense, just double checking thank you :)
[17:50] <persia> But you need both.  One is about the .dsc and one is about the .deb
[17:54] <xteejx> persia: Architecture? It doesn't seem specific, so any?
[17:55] <persia> Yep.
[18:00] <xteejx1> persia: http://paste.ubuntu.com/362087/ hope this is ok
[18:00] <persia> xteejx1: Drop Priority and Section from the binary section
[18:01] <persia> Other than that, it looks like a good start.
[18:01] <persia> So, now run `debuild -S -us -uc` to build an unsigned, buggy, source package.
[18:01] <persia> Did you ever construct a lucid schroot?
[18:03] <persia> Oh, except you want to add "Build-Depends: debhelper (=> 7), libsdl1.2-dev" to the source section, and replace libsdl1.2-dev with ${shlibs:Depends} in the binary section.
[18:03] <xteejx1> persia: Yeah few weeks ago, but I had serious data corruption, my laptop hard drive failed, so reinstalled
[18:03] <xteejx1> ok
[18:03] <persia> Do you have any schroots setup?
[18:03] <xteejx1> nope
[18:03] <persia> Do you still have the LVM partition?
[18:03] <xteejx1> lol nope
[18:04] <xteejx1> Can't I just do it with pbuilder?
[18:04] <persia> Then go install pbuilder, and set it up (I don't know the best way to do this)
[18:04] <persia> !pbuilder
[18:08] <xteejx1> persia: http://paste.ubuntu.com/362089/
[18:08] <persia> Great.  `debuild -S -us -uc`
[18:10] <xteejx1> problems (as expected)
[18:10] <persia> Excellent.  Go fix them :)
[18:14] <xteejx1> They're only lintian errors, it appeared to debuild ok... ancient-autotools-helper-file, outdated-autotools-helper-file, and bad-relation build-depends: debhelper (= > 7)
[18:15] <persia> debhelper (>= 7) (no space)
[18:15] <xteejx1> There isn't a space in the control file
[18:15] <xteejx1> Build-Depends: debhelper (=> 7), libsdl1.2-dev
[18:15] <persia> Oh, sorry.  >= rather than =>
[18:16] <xteejx1> ohh :D
[18:16] <xteejx1> can I redo the debuild again without worrying?
[18:16] <xteejx1> i.e. no need to remove anything?
[18:16] <persia> Take a look around with ls.  You should be able to do so.
[18:19] <xteejx1> http://paste.ubuntu.com/362098/ I don't see any problems other than the ancient/outdated autotools helper files.... but this is ok right?
[18:21] <persia> Well, no.  It makes it less portable.  Try adding autotools-dev to build-depends and putting something like http://paste.ubuntu.com/362099/  in debian/rules
[18:23] <xteejx1> One day I will fully understand what that rules file does
[18:23] <persia> Also, to get lintian to tell you more (but it may make mistakes), try running `lintian -iIv spacejunk_1.0.1-0ubuntu1_source.changes` and also `lintian --pedantic ...`
[18:23] <xteejx1> W: spacejunk source: debhelper-overrides-need-versioned-build-depends (>= 7.0.50~)
[18:24] <persia> Then update that in the Build-Depends :)
[18:24] <xteejx1> persia: I was going to say shall I change the version :)
[18:24] <persia> At this point, lintian will be a better teacher than I (but ask questions if you're unsure).
[18:24] <xteejx1> Ok, so the ideal result is NO lintian errors at all?
[18:24] <randomaction> there should really be a debhelper command to update outdated config.*
[18:25] <persia> Once you get the source clean, try a pbuilder build, and run lintian against the binary .changes file.
[18:26] <persia> Getting no lintian Errors is a definite goal.  Getting no lintian messages is less so.  Sometimes lintian doesn't understand correctly, and it does have bugs.
[18:26] <persia> But most of the time, lintian has good advice, and you have to be fairly sure it's wrong to ignore it.
[18:27] <xteejx1> Which I'm not :P
[18:27] <persia> Right.  But now you have a buggy package, and once you fix the bugs, you'll have a good package.
[18:27] <persia> Once you have a good package, since it's a game, you'll want to get in touch with the Debian/Ubuntu Games team to get it uploaded.
[18:28] <persia> (or, if that's slow, stick it on REVU, but that may take just as long).
[18:28] <xteejx1> cool
[18:28] <xteejx1> btw $ lintian -ilv spacejunk_1.0.1-0ubuntu1_source.changes
[18:28] <xteejx1> Value "v" invalid for option l (number expected)
[18:28] <xteejx1> error parsing options
[18:28] <dupondje> persia: https://bugs.launchpad.net/debian/+source/synce-sync-engine/+bug/511986 linked upstream now :)
[18:29] <persia> xteejx1: lower-case i, capital i, lower-case v
[18:29] <xteejx1> ohhh :)
[18:29] <persia> dupondje: Great.  If we reach Debian Import Freeze, and it still isn't in unstable, ask back here about how to proceed.
[18:30] <dupondje> ok:)
[18:31]  * persia plots a good 15-30Ksec lag
[18:37] <xteejx1> persia: All good, except P: spacejunk source: source-contains-prebuilt-windows-binary windlls/libogg-0.dll but I think they MAY be needed
[18:59] <ahe> could someone review the new version of my package http://revu.ubuntuwire.com/p/rubyripper , please?
[19:03] <xteejx1> persia: Ping!
[19:07] <randomaction> xteejx1: I believe that 15-30K sec lag referred to sleep
[19:08] <xteejx1> I've been trying to build a new package for Ubuntu (my first time), I've got up to doing debuild, which after a little fiddling has went fine apart from lintian saying about windows binary dlls in the source, but I think they're needed... where do I go from here please can someone help?
[19:08] <xteejx1> randomaction: heh :)
[19:09] <xteejx> do I do pbuilder now to test the build process?
[19:17] <xteejx> Hey guys, http://paste.ubuntu.com/362127/ I have an error 9 in [override_dh_auto_configure] can someone help please?
[19:18] <xteejx> I'm trying to make a package, and this happened in pbuilder
[19:34] <kamalmostafa> Motu's please advise:  Debian's package libexplain 0.19.D001-1 seems stuck in unstable - http://packages.qa.debian.org/libe/libexplain.html - I don't understand the "Check why" explanation.  I would like to get that version into Lucid to fix some FTBFS's.  I can pbuilder-lucid-amd64 it fine and install it.  I think I should file a sync request -- but can I get some help understanding the "Check why" first?
[19:36] <randomaction> xteejx: the error occurred while running ./configure, it should be in the previous lines
[19:36] <Laney> kamalmostafa: sounds like it starts a transition
[19:36] <xteejx> randomaction: That's what I thought, I'm now trying to build it from source locally to test if it installs on my system, I'm guessing once I can do that, it'll be a LOT easier to package it
[19:37] <Laney> hmm, maybe not
[19:37] <randomaction> xteejx: that's true. configure often fails because of missing build-deps
[19:38] <xteejx> randomaction: Well it's having problems finding sdl so I'll work through the configure script problems to track it down :)
[19:39] <randomaction> kamalmostafa: maybe this is the case described by "Explanation #1" at http://release.debian.org/migration/testing.pl?package=libexplain ?
[19:40] <kamalmostafa> randomaction: Well, yes, that sounds most reasonable, but...  All of the packages that it claims will be "uninstallable" are just those that are produced by libexplain itself.  Note http://packages.qa.debian.org/libe/libexplain.html .   As stated, I don't get it ;-)
[19:40] <kamalmostafa> I meant this URL:   http://release.debian.org/migration/testing.pl?package=libexplain;expand=1
[19:42] <xteejx> Is it normal for a game to want -dev libs for the configure script to work??
[19:43] <randomaction> xteejx: yes, for games and most software :)
[19:44] <xteejx> randomaction: Ohh OK, just got a little worried when it looked like it wanted 50M+ of archives :)
[19:45] <randomaction> kamalmostafa: I think I got it: http://packages.debian.org/sid/libexplain9 - depends on non-existent libcap1 on i386
[19:46] <randomaction> so it should be rebuilt (binNMU'ed, in Debian language)
[19:46] <kamalmostafa> randomaction: but only i386?  Let me look at the deps here.
[19:50] <randomaction> it must have been build before the transition; if it were built now, it'd depend on libcap2
[19:50] <xteejx> This package I'm creating, I'm running 32 bit Lucid, will it be buildable on amd64?
[19:51] <kamalmostafa> randomaction: Where are you seeing that reference to libcap2?  Here's the control file from libexplain 0.19.*  http://paste.ubuntu.com/362150/
[19:52] <randomaction> ${shlibs:Depends} expands to list of packages containing libraries to which the binaries have been linked
[19:53] <kamalmostafa> randomaction: Ah, okay.  And how does one "expand" that list for inspection?
[19:54] <randomaction> it's done by dpkg-shlibdeps command which is run during build, after the executables have been created
[19:54] <randomaction> so you just build the package and look at dependencies of resulting debs
[19:56] <randomaction> Does anyone know the appropriate place to ask for binNMU? Is it debian-release@l.d.o?
[19:58] <kamalmostafa> randomaction: so given a .deb, what handy command will tell me its dependencies (without installing it)?
[19:59] <randomaction> dpkg -I (capital i)
[20:01] <kamalmostafa> randomaction: Got it.  Okay, now I do see the libcap2 depend.  Thanks.   What's my next step?
[20:02] <kamalmostafa> ... I mean, to poke Debian.
[20:04] <randomaction> I don't know much about how this works in Debian, but I think you should ask for binNMU of libexplain on i386. I'm not sure where to do this, probably debian-release@l.d.o, but you could be better off asking in some Debian channel.
[20:05] <randomaction> And if you did the build locally, not in pbuilder, you can examine the substvars file in debian/ to see what variables expanded to what.
[20:08] <kamalmostafa> randomaction: Okay, very good -- I'll chase that down with Debian.   In the meantime, can we just sync the unstable version into Lucid anyway?
[20:10] <randomaction> sure we can, just add a note in the sync bug why we need to sync from unstable
[20:11] <kamalmostafa> Excellent.  Thank you very much.
[20:14] <porthose> ScottK, ping! here is a list of rdepends for elementtree, celementtree and ctypes http://paste.ubuntu.com/362163/. Should we go ahead and start changing the dependencies in those packages?
[20:14] <ScottK> porthose: Yes.  In most cases it should be a sync/merge from Debian since they have done this already.
[20:14] <porthose> ScottK, yea that's what I was thinking :)
[20:57] <shadeslayer> persia: there?
[20:58] <shadeslayer> ok anyone who can help me finish building this package?
[20:59] <shadeslayer> wow..
[21:00] <shadeslayer> Laney: there?
[21:04] <shadeslayer> cd
[21:05] <geser> ~$
[21:05] <shadeslayer> geser: :D
[21:21] <shadeslayer> anyone who can help me build a package?
[21:41] <xteejx> Hey guys when running debuild, lintian gives me a possible-unindented-list-in-extended-description warning. Could this be because I added * bullet points of the features in the control file, and does it matter?
[21:42] <xteejx> I just re-read that don't worry, I obviously didn't indent it enough!
[21:42] <RAOF> Lintian would obviously prefer that you indented the list; I don't think that's a standard (yet), but I've certainly seen discussion about standardising list markup for control files.
[21:43] <xteejx> It's ok, I'm being dumb I re-read it and it made sense! :)
[21:43] <RAOF> Throwing -i at lintian can make the messages make more sense, too.  That generally includes a longer description and how to fix it.
[21:44] <xteejx> Can I just ask... it's a python game, the deps are set, no problems there, but how can I make it so that it has a menu entry?
[21:44] <xteejx> RAOF: I'll try that thanks :)
[21:45] <RAOF> xteejx: It needs to ship a .desktop file for it to appear in the GNOME menus.  If upstream doesn't have one yet, they're trivial to write; you can find examples in /usr/share/applications
[21:45] <shadeslayer> anybody around to help me?
[21:45] <micahg> !ask > shadeslayer
[21:45] <shadeslayer> im almost done with making a .deb
[21:46] <xteejx> RAOF: Great!!! Thanks again! You guys have been really helpful today
[21:46] <xteejx> ps... hi micahg
[21:46] <micahg> hi again xteejx
[21:46] <shadeslayer> well last command i did was debuild -S -sa
[21:46] <xteejx> I'm giving triage a rest for a day or two, trying my hand at packaging :D
[21:46] <shadeslayer> and idk the next step :P
[21:47] <micahg> shadeslayer: next step for what?
[21:47] <xteejx> what have you done so far shade?
[21:47] <shadeslayer> micahg: xteejx lemme pastebin the thing
[21:47] <micahg> shadeslayer: that should give you the files necessary for a source upload
[21:48] <xteejx> xteejx: I'm new to packaging, just asking what someone else would...makes sense to know what you've done so far :)
[21:48] <shadeslayer> xteejx: http://pastebin.com/f653178d5
[21:48] <shadeslayer> micahg: i have .build and .dsc files
[21:49] <micahg> shadeslayer: are you ready to upload to revu (what are you trying to do)?
[21:49] <xteejx> Is this a problem: "W: magicity: extra-license-file usr/share/doc/magicity/LICENSE.txt.gz" ... how the hell could anything be there, I haven't given sudo access..........
[21:50] <micahg> xteejx: that could be a subdirectory in the tarball
[21:50] <shadeslayer> micahg: well as you can see from the conversation,apachelogger was teaching me how to build a package ( in this case : kopete-facebook ) for lucid
[21:50] <xteejx> micahg: Nope...that's why I'm worried
[21:51] <micahg> shadeslayer: ok, but what are you doing this for, yourself, Lucid releasE?
[21:51] <shadeslayer> micahg: now i also wanted to port this package for kubuntu-backports and kubuntu-beta PPA's and ive reached till that command
[21:51] <micahg> is it a new package?
[21:51] <shadeslayer> micahg: no its a updated package
[21:51] <shadeslayer> micahg: apachelogger told me that i should make the package and they ( kubuntu devs ) will upload it
[21:52] <xteejx> micahg: http://paste.ubuntu.com/362208/ It's the blah_i386.build file, would you mind having a quick look please?
[21:52] <micahg> shadeslayer: so I would guess you want to push to REVU then?
[21:52] <shadeslayer> micahg: idk the next step apachelogger had to go :P
[21:52] <xteejx> I've seen the problem
[21:53] <xteejx> magicity/debian/magicity/usr/share... why has debuild put it there?
[21:53] <shadeslayer> micahg: i thought this would lead me to a fully furnished .deb :)
[21:53] <xteejx> I ran debuild from the main source dir... i.e. magicity (first one)
[21:53] <micahg> shadeslayer: no, it's a source build for upload
[21:53] <micahg> xteejx: idk
[21:54] <xteejx> strange
[21:54] <shadeslayer> micahg: ok,and do i need just to run debuild -S -sa or just debuild -S
[21:54] <micahg> shadeslayer: to do what?
[21:55] <micahg> shadeslayer: they need the source build to upload, not a .deb
[21:55] <shadeslayer> micahg: for the build files?
[21:55] <shadeslayer> micahg: ok i got that but whats the -sa option for?
[21:55] <micahg> shadeslayer: to include the .orig.tar.gz in the upload
[21:56] <shadeslayer> micahg: any place i can test this ?
[21:56] <shadeslayer> (uploading the source builds etc)
[21:56] <jmarsden> shadeslayer: Your PPA ?  :)
[21:57] <shadeslayer> jmarsden: i can upload these to my PPA? :o
[21:57] <jmarsden> Once you have a source.changes file from a working package build for a Ubuntu distribution, yes.  That's what dput does...
[21:58] <shadeslayer> Hoorah
[21:58] <shadeslayer> to the PPA mobile :D
[21:59] <jmarsden> shadeslayer: https://help.launchpad.net/Packaging/PPA/Uploading
[22:00] <shadeslayer> jmarsden: reading
[22:00] <shadeslayer> jmarsden: is it preferred to have a staging repo
[22:01] <jmarsden> Staging... for a personal package archive?  I don't think so.  PPAs are personal, your PPA is *yours* to use for testing what you are working on...
[22:02] <shadeslayer> jmarsden: hmm well ok
[22:02] <jmarsden> shadeslayer: I'd be careful about uploading stuff to a team PPA that hundreds of trusting people might have in their sources.list ... but your own personal PPA... use it for testing packages, that's pretty much what it is for.
[22:04] <shadeslayer> ok
[22:04] <xteejx> I've created a .deb, installed it. Not sure where it installed to, how can I find out?
[22:05] <jmarsden> xteejx: dpkg -L packagename
[22:05] <xteejx> thanks :)
[22:05] <jmarsden> You're welcome.
[22:05] <shadeslayer> uploading :D
[22:06] <shadeslayer> ok how soon does the build finish?
[22:06] <xteejx> The .deb only installs the docs
[22:06] <jmarsden> shadeslayer: That depends who is ahead of you in the build queue :)
[22:07] <shadeslayer> jmarsden: wheres the build queue?
[22:07] <shadeslayer> jmarsden: and why cant i see my packages?
[22:07] <jmarsden> shadeslayer: Look at your PPA on launchpad, when you see the packages there you can click on them and see how long before they start to build etc.
[22:07] <geser> https://edge.launchpad.net/builders/
[22:07] <shadeslayer> jmarsden: i cant see any :P
[22:08] <jmarsden> shadeslayer: Wait a few minutes :)   To see how busy the builders are as whole are, see the URL geser gave you.
[22:08] <geser> currently the i386 PPA queue contains over 600 packages
[22:08] <shadeslayer> :o
[22:08] <shadeslayer> geser: um Queue says empty
[22:09] <shadeslayer> oh thats the official builder
[22:09] <jmarsden> shadeslayer: You won't be uploading anything there for a while :) :)
[22:09] <geser> you looked at the official archive queue, not the ppa queue
[22:09] <shadeslayer> jmarsden: even the uploads dont show up?
[22:10] <jmarsden> shadeslayer: The uploads should show up in your LP PPA page within a few minutes.  Upload processing is not instant.
[22:10] <shadeslayer> ah
[22:10]  * shadeslayer waits
[22:11] <xteejx> Question: I'm packaging a python game, it needs only 1 package, python-pygame - it is safe to simply have a control file that creates a directory for it in /usr/bin/ and copies it there with a .Desktop file for menu launching? I'm unsure if this would be acceptable?
[22:12] <kamalmostafa> shadeslayer: Note also that LP will send you an email saying that your PPA upload was "Accepted" (or "Rejected" if you named something incorrectly) -- so keep an eye out for an email from Launchpad PPA <no_reply@launchpad.net>.
[22:12] <shadeslayer> kamalmostafa: ah ok
[22:13] <shadeslayer> kamalmostafa: nothing yet :)
[22:13] <geser> the uploads are processed every 5 minutes
[22:14] <shadeslayer> hmm
[22:14] <geser> and LP will only mail you if it knows to which LP account the gpg key belongs to which signed the package
[22:15] <shadeslayer> ok and if i want to build for karmic i just change the changelog right?
[22:15] <shadeslayer> um oops
[22:15] <shadeslayer> i didnt add my gpg key
[22:16] <shadeslayer> ><
[22:20] <shadeslayer> and btw can i delete keys on my system?
[22:22] <strycore> hey
[22:22] <strycore> no wrong channel
[22:23] <RAOF> xteejx: Does it have any buildsystem currently?
[22:24] <xteejx> RAOF: What do you mean?
[22:24] <RAOF> xteejx: If I got this game from upstream, how would I install it?
[22:24] <xteejx> RAOF: Oh, install python-pygame and run the game with 'python magicity' that's it
[22:25] <RAOF> Ah.  So there isn't actually any build system or install instructions.
[22:25] <shadeslayer> kamalmostafa: i guess i have to upload them again?
[22:25] <shadeslayer> all the source files etc
[22:26] <xteejx> If you mean make / configure script, no none of that, it's just a plain run and play
[22:26] <xteejx> RAOF: A few .py files and the fonts/music/images thats all
[22:26] <shadeslayer> jmarsden: do i have to upload the files again?
[22:27] <jmarsden> shadeslayer: Now you signed them?  Yes.
[22:27] <shadeslayer> ok
[22:27] <sebner> RAOF: hiya, --nvidia fixed the issue mostly for docky. Happens not that often now, though I can reproduce it sooner or later after playing a 2D/3D game
[22:27] <RAOF> xteejx: So, the fonts/music/images want to go in /usr/share, obviously.  You probably only want to put a single file in /usr/bin; this should have an appropriate shebang line (#!/usr/bin/python).
[22:28] <shadeslayer> jmarsden: ok thanks mate :D
[22:28] <jmarsden> shadeslayer: You're welcome.
[22:28] <RAOF> sebner: Yeah.  The --nvidia switch works around the problem by droppnig & redrawing the buffers every 10 minutes.  You can use -b $MINUTES instead if you find that 10 minutes is too long. :/
[22:28] <shadeslayer> jmarsden: btw can i delete my GPG keys on my local machine?
[22:28] <xteejx> RAOF: It's just I don't know how to make it do that... I know how I'd do it myself, but not how the config would do that, although I *think* it all needs to be together in 1 directory
[22:29] <shadeslayer> jmarsden: and how do i backup these keys?
[22:29] <jmarsden> shadeslayer: You should use those same keys for some time... a year or two is common.
[22:29] <sebner> RAOF: I'll try it out. The correct fix can only provide nvida I suppose?
[22:29] <RAOF> sebner: I believe so.  Docky's not doing anything wrong, as far as I can tell.
[22:30] <RAOF> xteejx: Heh.  Now you get to earn your keep as a packager.  The source doesn't comply with Debian policy, so you need to patch it until it does :)
[22:30] <jmarsden> shadeslayer: https://help.ubuntu.com/community/GnuPrivacyGuardHowto#Backing%20up%20and%20restoring%20your%20key%20pair
[22:30] <sebner> RAOF: kk, thx again for the infos :)
[22:30] <xteejx> RAOF: You're kidding me??
[22:31] <shadeslayer> jmarsden: what about deletion?
[22:31] <jmarsden> shadeslayer: What about it?  Why would you delete your own keys ??
[22:31] <RAOF> xteejx: No, not kidding you at all.  This is one of the main reasons why we package - so that the system maintains a consistent policy!  Since it's python, you probably want to look at http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html .
[22:31]  * xteejx cries
[22:32] <RAOF> xteejx: Yah.  I've written a couple of buildsystems and sent them upstream for things I've packaged :)
[22:33] <RAOF> xteejx: Sometimes you just have to do some work for upstream (and then submit it to them, so other distros don't have to duplicate it).
[22:33] <xteejx> RAOF: Could I not just ask them to restructure it so it can be included? lol
[22:34] <xteejx> RAOF: tbh I don't think it's maintained any longer, I just looked.... :(
[22:34] <shadeslayer> jmarsden: i have 3 of them... dont need 2
[22:34] <RAOF> xteejx: Yeah, that's what you're going to do.  But I find that asking developers to restructure it works better if you include a patch to restructure it at the same time :)
[22:35] <xteejx> Actually even after all the hard work so far, I could ditch it and try another package, it wasn't LP'd anyway.... I could do that one another time.... what about ones that already have /usr /bin in the directories in the source tree... would they be easier to try for a first time, as I assume they just need copied to the root /  ?
[22:36] <xteejx> It's gonna be my first package
[22:36] <jmarsden> shadeslayer: I think you can use gnupg --delete-secret-and-public-key NAME     # Just get the right ones to delete :)
[22:37] <shadeslayer> yayyy i got the mail about the packages
[22:37] <shadeslayer> :D
[22:37] <xteejx> Or put another way.... *ideally*, what should I look for when wanting to package for a first try to make it as easy as possible, with a smaller learning curve...I don't want to jump in head first and "hit my head on the bottom"
[22:37] <RAOF> xteejx: Programs that have a reasonably sane build system are much easier to package, yes.
[22:37] <jmarsden> shadeslayer: Make that    gpg --delete-secret-and-public-key NAME
[22:37] <shadeslayer> jmarsden: but all 3 have the same nape :)
[22:37] <kamalmostafa> shadeslayer: The gui program 'seahorse' might make finding the right keys easier also.
[22:37] <shadeslayer> *name
[22:38] <geser> shadeslayer: did you upload these keys to a keyserver?
[22:38] <RAOF> xteejx: If something has an autotools buildsystem (Makefile.am, configure.ac, etc) it's generally a good bet that it'll Do The Right Thing™.
[22:38] <shadeslayer> geser: yep
[22:38] <shadeslayer> geser: um no actually
[22:38] <jmarsden> shadeslayer: Then you need to read the GPG docs really carefully, I think... I've never had to differentiate between two keys with the exact same name :)
[22:38] <xteejx> LOL trademarked!
[22:39] <xteejx> I understand though...makefiles and configure scripts = slightly easier life
[22:39] <shadeslayer> woot : https://launchpad.net/~rohangarg/+archive/kde-extra
[22:39] <RAOF> xteejx: But you don't have to package from scratch to learn packaging; taking an existing package and fixing a bug in it is highly (possibly even more) worthwhile.
[22:39] <geser> shadeslayer: good, since once a key is uploaded you can't remove them from the keyservers anymore, only mark as revoked
[22:39] <shadeslayer> geser: ok
[22:40] <shadeslayer> ok and one more thing it says 32 bit build... but i wanted it to build for everything
[22:40] <xteejx> RAOF: Of course :) The reason I wanted to do it from scratch is to learn the entire process hands-on...made more sense to me
[22:40] <kamalmostafa> shadeslayer: Your build has already succeeded for amd64.  i386 build will start in 23 hours per your PPA page.
[22:40] <geser> shadeslayer: is it an arch:all or arch:any package?
[22:40] <shadeslayer> kamalmostafa: :o
[22:40] <jmarsden> shadeslayer: I suspect you could use the keyid value instead of the name??  Might be worth a try, at least.  I'd back things up first to be safe :)
[22:41] <xteejx> I want to find an unpackaged game that I think everyone will like...there doesn't seem enough choice (of immersive 3D ones I mean)...other than that we have absolutely LOADS!
[22:41] <RAOF> xteejx: I don't think many MOTU started off by packaging something from scratch; it's very easy to usefully contribute by fixing existing packages, and you'll end up learning the whole process bit by bit.
[22:41] <shadeslayer> jmarsden: ive already exported the key i wanted
[22:41] <shadeslayer> kamalmostafa: i cant see the amd64 build
[22:41] <xteejx> RAOF: You mean from bug reports that have patches on LP and just need repackaged?
[22:42] <shadeslayer> kamalmostafa: found it
[22:42] <shadeslayer> now onto to the karmic build :P
[22:42] <RAOF> xteejx: That's a fine start, yes.  Also, bugs that have upstream links where upstream has fixed it, merging new versions from Debian, etc.
[22:42] <xteejx> RAOF: The "please sync ### from Debian unstable" bugs?
[22:43] <geser> xteejx: "Yo Frankie!" is still unpackaged (it has now even a bounty for packaging it)
[22:43] <xteejx> geser: How much? haha
[22:43] <geser> http://blog.thesilentnumber.me/2010/01/35-50-if-you-package-yo-frnakie.html
[22:43] <sebner> geser: I've already read about it. wondering if this is possible. I don't think it has a (sane?) build system etc
[22:44] <xteejx> geser: omfg that looks amazing
[22:44] <geser> I didn't look at it yet
[22:45] <xteejx> I honestly don't think I'd be able to do it if MOTU haven't already after 2 years! hehe I want an 'easy' project for my first time
[22:45] <sebner> geser: I once downloaded it and had to open the files with blender and render it so get the game :P
[22:46] <xteejx> RAOF: I assume merges from Debian is just a case of checking the files in debian/ ?
[22:46] <xteejx> And editing of course
[22:47] <RAOF> xteejx: It's a case of working out what's different between the Ubuntu & Debian packges, *why* they are different, and what parts of that difference still matter.
[22:48] <xteejx> ROAF: I see, and apply those changes to our one, or simply copy it?
[22:48] <RAOF> xteejx: https://wiki.ubuntu.com/UbuntuDevelopment/Merging is some slightly out of date documentation.
[22:49] <ajmitch> geser: great bit of negativity in the comments there
[22:49] <xteejx> RAOF: Cool. The wiki is so helpful sometimes, others it's just damn confusing! heh
[22:50] <geser> I liked most "Ubuntu is dying." in one of its comments
[22:51]  * ajmitch didn't realise that MOTUs spent all their time partying & blogging
[22:51] <ajmitch> though I did just spend a week at LCA, so that's only partly true :)
[22:53] <shadeslayer> jmarsden: ok one more thing,cant lucid and karmic survive in the same repo?
[22:53] <jmarsden> shadeslayer: Packages for each of them?  Sure they can.
[22:53] <sebner> ajmitch: beer!
[22:54] <shadeslayer> jmarsden: and i just need to change the debian/changelog right?
[22:54] <jmarsden> shadeslayer: Yes.
[22:54] <shadeslayer> jmarsden: im getting Rejected:
[22:54] <shadeslayer> File kopete-facebook_0.1.5-0ubuntu1.diff.gz already exists in KDE Extra stuff, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
[22:54] <shadeslayer> Files specified in DSC are broken or missing, skipping package unpack verification.
[22:55] <ajmitch> sebner: yes, I did drink some of that
[22:55] <jmarsden> shadeslayer: You forgot to edit the package name in the changelog.  foo-0.1.5-0ubuntu1~karmic1~ppa or whatever
[22:56] <shadeslayer> ah
[22:56] <shadeslayer> thanks
[22:56] <jmarsden> shadeslayer: You *did* read the Packaging Guide before doing any of this, right?
[22:56] <shadeslayer> jmarsden: apachelogger told me this but i forgot :P
[22:57] <geser> shadeslayer: you can upload a version of a package only once (if it gets accepted). if you want the same package for different releases you need to use slightly different versions (e.g. mention the release name in the package revision or similar)
[22:58] <shadeslayer> jmarsden: i have to change (0.1.5-0ubuntu1) to kopete-facebook-0.1.5-0ubuntu1~karmic1~ppa
[22:58] <shadeslayer> um wait not that
[22:58] <shadeslayer> just the part after kopete-facebook :)
[22:59] <blueyed> When live-tracing a process using "strace -p $PID", how do I know what identifier 3 refers to in a read?
[22:59] <shadeslayer> jmarsden: right?
[22:59] <jmarsden> Right.  Use whatever naming system you like, but ~karmic1~ppa is fine.
[22:59] <shadeslayer> ok
[23:00] <shadeslayer> jmarsden: and i add 0 to superseed it then right
[23:00] <shadeslayer> at the end
[23:00] <shadeslayer> for future revisions i.e
[23:00] <jmarsden> shadeslayer: I'd do ~ppa1, ~ppa2, etc if you need minor changes to packaging only, yes.
[23:01] <shadeslayer> jmarsden: thanks again :D
[23:01] <jmarsden> You could do ~karmic2~ppa  ~karmic3~ppa  and so forth if you prefer...
[23:01] <shadeslayer> i prefer the former
[23:01] <jmarsden> Me too.  There;'s no magic in the naming, that's all I'm saying.
[23:02] <shadeslayer> next up is choqok :P
[23:02] <shadeslayer> or should is stop? its 5 in the morning :P
[23:03] <shadeslayer> meh.. lets do thi
[23:03] <shadeslayer> s
[23:05] <shadeslayer> grrr... somebody beat me to it :(
[23:05] <blueyed> answer to my question above: you can get this via "lsof -p $PID", which lists the descriptors.
[23:23] <dupondje> whats need to be done when there is a bug in a patch in the debian/patches dir?
[23:24] <dupondje> same steps to make new package or ?
[23:24] <sebner> dupondje: update the patch and increment the versionsnumber in the changelog
[23:28] <dupondje> diff -u ?
[23:28] <crimsun> debdiff
[23:29] <dupondje> crimsun: the patch in debian/patches is not created by debdiff I bet :)
[23:30] <crimsun> you misunderstand, I think. Make your changes, increment the changelog, regenerate the source package, and generate a debdiff.
[23:31] <dupondje> but the patch needs to be replaced first in debian/patches ..
[23:31] <crimsun> then do so first
[23:32] <crimsun> I would presume that falls under "Make your changes"
[23:32] <dupondje> well just wanted to make sure you create that patch with diff -u, and no more options :)
[23:33] <RAOF> There's generally an easier way to do it than that, but it depends on the patch system in use.
[23:37] <dupondje> https://bugs.launchpad.net/ubuntu/+source/xchat-xsys/+bug/512113
[23:41] <crimsun> that's a malformed debdiff
[23:41] <crimsun> note:
[23:41] <crimsun> $ diffstat -p1 -l ../xchat-xsys.debdiff
[23:41] <crimsun> debian/changelog
[23:41] <crimsun> debian/patches/fix_whitespace
[23:41] <crimsun> match.c
[23:42] <crimsun> you're touching the file to be patched /outside/ of the quilt infrastructure
[23:44] <dupondje> I know what I did wrong :( retry :)
[23:46] <dupondje> $ diffstat -p1 -l xchat-xsys.debdiff
[23:46] <dupondje> debian/changelog
[23:46] <dupondje> debian/patches/fix_whitespace
[23:46] <dupondje> is better :)
[23:52] <dupondje> ok
[23:52] <dupondje> patch uploaded
[23:52] <dupondje> and tested :)
[23:57] <dupondje> whats the next step ? :)