[00:16] <mde88> hi.
[00:16] <mde88> i was wondering if you guys knew how i could take a .deb
[00:17] <mde88> and make a .dsc
[00:19] <RAOF> The dsc is a part of the source package; it's not possible in general to go backwards from a binary package to a source package.
[00:21] <mde88> RAOF, oh, ok.
[00:48] <MTecknology> How can I see sections available for a package?
[00:48] <MTecknology> I'm not entirely sure where it should wind up
[00:54] <MTecknology> I'm guess a clock that sits in your dock should be in the x11 section..
[00:54] <RAOF> MTecknology: The canonical list of sections is in debian policy.  Let me grab the link for you.
[00:58] <MTecknology> RAOF: I'm guessing this - http://www.debian.org/doc/debian-policy/ch-controlfields.html
[00:58] <RAOF> It might depend on what dock, but x11 seems safe.
[00:58] <MTecknology> thanks :)
[00:59] <RAOF> http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections is what I was thinking of.
[00:59] <MTecknology> thanks :)
[01:00] <MTecknology> only two files left to figure out - changelog and one other, the other is going to be the hard one..
[01:00] <MTecknology> for now, break time :)
[01:15] <persia> MTecknology: changelog is trivial.  dch --create for a new one, dch to edit the current one, or dch -i to add an entry.
[01:16] <directhex> MTecknology, the hard one is debian/copyright. the rest have a much faster turnaround on discovering issues
[01:18] <persia> Well, depends.  I've seen lurking issues in debian/control as well :)
[01:19] <ajmitch> or a debian/rules more complex than the source it's for
[01:20] <directhex> ajmitch, i've done difficult rules and difficult copyright. copyright is far more infuriating
[01:21] <directhex> the openjdk maintainers might benefit from looking at debian/copyright in ikvm, since it's got a mostly-complete DEP5 for openjdk in it
[01:22] <persia> Why?  Is there that much source duplication?  Could it be avoided?
[01:22] <directhex> it's not feasible to avoid it
[01:22] <persia> ajmitch: There's very few packages that really need complex debian/rules: I'd rather see use of dh(1) (or even CDBS) to avoid manual mistakes.
[01:23] <persia> directhex: Hrm?  Why not.  Worst case, openjdk could generate openjdk-source on which ikvm could build-depend.
[01:23] <ajmitch> persia: I have seen a few complex examples, but they're usually for fairly large packages
[01:23] <directhex> persia, the openjdk-source package misses some of the more esoteric bits & pieces, and the whole thing is mildly forked here & there
[01:23] <persia> Generally, although sometimes they seem to be because the maintainer is trying to fit into something they aren't.  sendmail is a lovely example of that.
[01:24] <ajmitch> now there's a dirty word
[01:24] <persia> directhex: Missing bits are bugs in openjdk.  Forked bits can be handled with build-time patching.
[01:24] <persia> Which?  Sendmail?
[01:24] <ajmitch> yes
[01:24]  * persia remembers lovely afternoons spent pondering rule 3
[01:24] <directhex> persia, you're free to take a look, but you're proposing a maintenance nightmare
[01:25] <persia> directhex: Short-term, yes.  My actual proposal is for deeper coordination to avoid build-time patching.
[03:04] <dhillon-v10> hi all, I just finished a merge, and am about to upload it, so in the patch there are a lot of po files, should I keep that in the diff or remove it, I think its just some noise so it should be removed
[03:04] <persia> Generally we prefer Debian translations.
[03:05] <persia> The exceptions being when we've deliberately changed something, but this should appear in the changelog.
[03:05] <persia> If something is deliberately changed, please only merge those msgids in the .po files.
[03:06] <dhillon-v10> persia: so here: http://paste.ubuntu.com/362997/ i should remove all the .po changes right
[03:06] <persia> Well, I think you're merging too much there :)
[03:07] <dhillon-v10> persia: really ? this package had a lot of changes, especially the .po stuff, but if that's going to be removed then its not that much really
[03:07] <persia> Firstly, I think the update to debhelper 7 is worthless: I don't think we should be fixing lintian issues in stuff maintained in Debian.
[03:07] <persia> Standards-Version too.
[03:08] <dhillon-v10> persia: they updated it to 7 and same for standards, so I should just change them and not mention that in the changelog
[03:08] <ScottK> Standard version is something Ubuntu Policy says specifically not to touch
[03:08] <persia> Just revert to Debian, and drop it from the "Remaining changes"
[03:08] <dhillon-v10> persia: alright :)
[03:08] <persia> Same with overrides, in my opinion.
[03:09] <dhillon-v10> persia: this is from the debian's control file: Standards-Version: 3.8.3 so I just put that there, but will remove it
[03:09] <dhillon-v10> persia: so remove the overrides too, that file was renamed to a different one, so I didn't know how to put that down in words
[03:10] <persia> dhillon-v10: You want to use whatever Debian has for Standards-Version, debhelper compatibility, and lintian overrides *UNLESS* the package has an unlikely bug like some dh7 feature being used with declared compat level of 5.
[03:10] <persia> What is this diff anyway?  It doesn't appear to be a Debian->candidate or Ubnutu->Ubuntu.
[03:11] <persia> For Debian->candidate it doesn't have enough old changelog entries.  For Ubuntu->Ubuntu it includes some old Ubuntu changelogs.
[03:11] <dhillon-v10> persia: alright :) my mentor told me to document *every* single change I make so I did so but i will remove that, this one was done using bzr diff --old lp:debian/squeeze/ssl-cert
[03:11] <dhillon-v10> persia: why is that patch wrong, that's what the wiki page said
[03:12] <dhillon-v10> persia: I have actually had a couple of wrong ones like this, but don't know what to do
[03:12] <persia> dhillon-v10: I'm not saying the patch is wrong, just that it doesn't match either of the patches I'm used to reviewing.
[03:13] <persia> As a result, I'm uncertain about everything.
[03:13] <persia> But I know that we're not supposed to change Standards-Version and lintian stuff Ubuntu-local unless it makes some significant user-visible difference.
[03:16] <dhillon-v10> persia: alright, so I'll remove  that stuff, so what can i do to fix my patch, sorry I am taking a lot of your time
[03:16] <persia> I choose to spend my time answering questions in this channel, in hopes that it makes up for not uploading enough.  Don't worry about that :)
[03:17] <persia> I don't know how to tell you what to do with your patch.  I usually compare my candidate to both the package in Debian and the package in Ubuntu.
[03:17] <persia> Comparing against Debian lets me confirm that I included all the changelog entries and all the related patches.
[03:17] <persia> Comparing against Ubuntu lets me confirm that I included all the improvements from Debian.
[03:17] <MTecknology> And back at it.. I know I've been told this before.. so- is there any wiki that describes how packages should be named? mostly just the piece after app_version***
[03:18] <persia> MTecknology: You should never do anything manually that affects that unless you have a very special case and already know how to do it.
[03:18] <dhillon-v10> persia: so I should debuild the package and then compare the two candidates
[03:18] <MTecknology> persia: new package that will be in a ppa
[03:18] <persia> Just worry about the "app" part, and accept the dfaults for everything else.
[03:18] <MTecknology> persia: then try to make it into the repos
[03:19] <persia> dhillon-v10: I build source packages and compare those, but that's the idea.
[03:19] <MTecknology> What I have is this - lal (1.0-1) karmic; urgency=low
[03:19] <persia> MTecknology: Right.  Doesn't matter.  Accept the defaults.  Anything else is going to cause you more problems than you want to understand how to fix.
[03:20] <persia> I'd recommend lal (1.0-0Mtecknology1) for a ppa, and 1.0-0ubuntu1 for Ubuntu.
[03:20] <MTecknology> persia: ok, I've just always seen thins like ubuntu# or ppa#
[03:20] <persia> Ah, you want the revision number :)
[03:20] <persia> I thought you were talking about the architecture ID strings and the like.
[03:20] <MTecknology> oh
[03:20] <MTecknology> no thanks, I don't want to play with that :P
[03:21] <persia> Doesn't matter what you use.  Just pick something lower than -0ubuntu1 if you're out of repo, and -0ubuntu1 if you're in repo.
[03:21] <MTecknology> ok, there's actually no package yet :P
[03:21] <persia> dpkg --compare-versions lets you check various strings.
[03:22] <MTecknology> ok - two more things... I want to create a man page before going any further with this..
[03:23] <persia> help2man can be a useful way to get started, depending on the package.
[03:23] <dhillon-v10> persia: E: ssl-cert_1.0.25ubuntu1_source.changes: bad-ubuntu-distribution-in-changes-file lucid
[03:23] <persia> There's also txt2man, rst2man, info2man, djbdoc2man, docbook-utils, podulators-perl, etc.  Depends how you want to write the docs in the first place.
[03:23] <MTecknology> extremely simple; right now it's one .c that builds one binary
[03:23] <dhillon-v10> persia: what does that mean?
[03:24] <persia> dhillon-v10: It means you're not using the lintian from lucid.
[03:24] <persia> More specifically, it means that the lintian you're running doesn't know about lucid.
[03:24] <persia> Upgrade lintian.
[03:24] <dhillon-v10> persia: alright :)
[03:25] <MTecknology> persia: care if I pm you a political question?
[03:26] <persia> I prefer to just receive /queries without being asked.  Depending on the topic, I can't promise to discuss at length.
[03:37] <MTecknology> persia: I tried txt2man and that gave some really ugly output :P
[03:37] <MTecknology> as in, an ugly man page
[03:37] <persia> Right.  Now fix it :)
[03:38] <persia> But it's easier than creating a manpage from scratch (at least for me)
[03:43] <ScottK> "Fear.  Run.  Save yourself.  No user-serviceable parts." <-- comment from a man page nroff preamble.
[03:43] <RAOF> Heh.
[03:44] <MTecknology> persia: so.. html2man won't help because this app continues if it doesn't recognize --version :P
[03:45] <persia> MTecknology: Feel free to draft from scratch.  I just find that getting the framework from a tool (especially if it there are already convertible upstream docs) is easier to start.
[03:46] <MTecknology> persia: thanks
[04:05] <MTecknology> persia: jsut talked to the maintainer; they're excited
[04:05] <MTecknology> I'm going to just write this file from scratch :P
[04:14] <MTecknology> this isn't that hard... I'm kind of amazed
[04:16] <MTecknology> just not dure what .RE and .RS are for yet..
[04:16] <MTecknology> I think I get that part now too :)
[04:46] <zooko> Greetings, folks!
[04:47] <MTecknology> zooko: hi
[04:49] <MTecknology> persia: You going to be around a little bit longer?
[04:51] <ScottK> Heya zooko.  How's the release going?
[04:52] <zooko> Hi!  I decided today to stop trying to finish the last feature and start packaging and documenting and all that.
[04:52] <zooko> My goal is to release Tahoe-LAFS v1.6 this week and upload it to Ubuntu on Thursday.
[04:52] <zooko> http://allmydata.org/pipermail/tahoe-dev/2010-January/003664.html
[04:53] <zooko> I'm excited!  Cory Doctorow invited me to submit a news item about Tahoe-LAFS to Boing Boing.
[05:07] <zooko> ScottK: how is Lucid coming?
[05:07] <ScottK> Hard to say.  Lots of good stuff done, lots more to do.
[05:13] <zooko> Hm, this reminds me to mark a ticket in Nevow as review-needed...
[05:13] <zooko> Because I want the version of Nevow in Lucid to stop emitting DeprecationWarning...
[05:14] <zooko> Oh I suppose that picky exarkun will ask me to submit a unit test showing that it doesn't emit a DeprecationWarning!
[05:17] <zooko> ScottK: what are the sorts of things you're thinking of when you say "lots more to do"?
[05:18] <ScottK> Quite a number of features still being implemented, tons of bugs, lots of packages to merge from Debian.
[05:18] <ScottK> zooko: It might be worth it for you to look and see if any of the tahoe build depends/depends need updating.
[05:21]  * zooko checks http://allmydata.org/trac/tahoe/log/_auto_deps.py
[05:22] <zooko> We haven't changed the Tahoe-LAFS dependencies since v1.5.0 of Tahoe-LAFS.
[05:23]  * zooko looks at https://bugs.launchpad.net/ubuntu/lucid/+source/linux-mvl-dove/+bug/505772
[05:33] <MTecknology> Do I 'need' a ./configure script?
[05:33] <MTecknology> The app doesn't have any options to be passed to it..
[05:43] <fabrice_sp_> MTecknology, no, it's not mandatory
[06:04] <MTecknology> fabrice_sp: thanks
[06:27] <kamalmostafa> Hello motu's...  Is there a problem with openssl in Lucid?  Various packages (e.g. libavg) FTBFS with "ld: cannot find -lssl".
[06:32] <ScottK> Do they build-depends on libssl-dev?
[06:34] <kamalmostafa> well, not directly at least, but I imagine that libssl-dev is supposed to get pulled in by some dependency -- only because several unrelated packages are showing the same "cannot find -lssl" failure.
[06:35] <kamalmostafa> Here is libavg's build-deps
[06:35] <kamalmostafa> Build-Depends: cdbs, debhelper (>= 5), libavcodec-dev, libavformat-dev,
[06:35] <kamalmostafa>  libboost-python-dev (>= 1.34.1-8), libboost-thread-dev, libdc1394-22-dev,
[06:35] <kamalmostafa>  libgraphicsmagick++1-dev, libpango1.0-dev, libsdl1.2-dev, libswscale-dev,
[06:35] <kamalmostafa>  libtool, libxml2-dev, libxxf86vm-dev, python-all-dev, python-central (>= 0.5),
[06:35] <kamalmostafa>  quilt
[06:35] <ScottK> If packages were depending on an indirect depends to get the libssl headers, that's a bug in the package.
[06:36] <ScottK> If adding libssl-dev to the build-depends fixes it, then that's a correct fix in almost all cases.
[06:41] <kamalmostafa> ScottK: Ok, that's easy to try anyway.  But it doesn't look to me like the libavg actually refers to "ssl" directly at all.  Isn't it possible that it is pulling in "-lssl" from some build-time thing (pkgconfig of one its dependencies?) so that libavg wouldn't actually know that it needs libssl-dev?
[06:41] <ScottK> In that case it should be a depends of that dependency.
[06:43] <kamalmostafa> ScottK: That's what I meant by "supposed to get pulled in by some dependency".  Maybe one of its deps recently accidentally dropped its (required) dependency on libssl?  How can I trace that?
[06:43] <ScottK> If it did, it wouldn't have built.
[06:44] <ScottK> Alternatively it can be an actual bug in the package.
[06:45] <kamalmostafa> a bug in which package?
[06:48] <ScottK> Could be libavg in this case.
[06:48] <ScottK> Here's an example of another package that had this problem: http://git.quassel-irc.org/?p=quassel.git;a=commit;h=ab66db150c3eadf225fab28af591ba74093950f6
[06:51] <kamalmostafa> ScottK: Eight unrelated packages on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi get the same failure.  Can they all be buggy?  ;-)
[06:51] <ScottK> kamalmostafa: If they all made the same incorrect, but common, assumption: Yes.
[06:56] <dupondje> https://bugs.launchpad.net/bugs/512509 feel free to sponsor :D
[06:56] <ScottK> kamalmostafa: As an example, the Quassel bug was exposed by the qt4-x11 dev package dropping libssl-dev as a build-dep for this exact reason.  It wouldn't suprise me if there were several packages that broke just because of that.
[07:00] <kamalmostafa> ScottK: But Quassel (if I understand correctly) actually itself cares whether ssl is or isn't present, right?  Certainly its source refers to "ssl".  But libavg doesn't refer to "ssl".   Anyway -- lets set libavg aside for a moment...
[07:01] <ScottK> Right, I'm just speaking in general.
[07:01] <ScottK> In libavg's case it may be bug that it tries to build against it when it doesn't need to.  No idea.
[07:02] <kamalmostafa> Consider package 'dia' which shows a clean ubuntu build months ago, but recently FTBFS with the "cannot find -lssl" error in the udd.debian list.   Could we do a retry build on 'dia' now and see what happens?
[07:02] <ScottK> Is it FTBFS in the archive, or just in the rebuild test?
[07:02] <kamalmostafa> Or wait -- I could just pbuilder that myself.
[07:03] <ScottK> Yes.
[07:03] <ScottK> Then if it fails, add libssl-dev to the build-deps and see what happens.
[07:05] <kamalmostafa> ScottK: Okay, I will try that -- but I expect that in all cases, it would fix the build problem -- but still might not be the "right" fix.  Anyway -- it'll be informational.
[07:05] <ScottK> "Right" is one of two possibilities: Either that's right, or the package is buggy and looking for somethig it shouldn't during build.
[07:06] <ScottK> relying on indirect depends is a bug.
[07:07] <persia> In many cases where there's an indirect dependency on libSSL, it may be worth checking if there is a gnutls solution also available.
[07:07] <persia> (just because of the license checking requirements when linking against SSL)
[07:08] <kamalmostafa> I think the primary question (for e.g. libavg) is *why* is -lssl appearing in its link line at all?
[07:10] <persia> Probable a pkgconfig thing.  Dig through the ./configure output
[07:33] <geser> does libavg build a python extension?
[07:34] <geser> if yes, it might use LOCALMODLIBS (which contains -lssl) which it shouldn't use
[07:35] <kamalmostafa> geser: I do see a reference to "LOCALMODLIBS" in its configure script.
[07:35] <kamalmostafa> libavg's control file is here: http://pastebin.ubuntu.com/363080/
[07:37] <geser> "LOCALMODLIBS is a macro used to link the python binary against libaries needed for the binary. It must not used to link extensions."
[07:38] <geser> so you need to patch configure to not use LOCALMODLIBS
[07:38] <dholbach> good morning
[07:38] <geser> good morning dholbach
[07:38] <kamalmostafa> geser: Bingo. I do see the reference to -lssl in the definition of LOCALMODLIBS.  Thanks geser!
[07:40] <geser> kamalmostafa: I had a similar issue to fix yesterday. you might want to look at http://bugzilla-attachments.gnome.org/attachment.cgi?id=147050 to get an idea how to fix it and adapt this then on libavg
[07:41] <kamalmostafa> geser: Excellent -- thank you.  Note that libavg isn't the only package showing this problem.  Did something recently change in python that exposed this issue?
[07:43] <geser> if "recently" == "since lucid", then yes. As far as I understand it LOCALMODLIBS was never intended to by used outside the python interpreter itself.
[08:21] <dupondje> is there a way to set like 'depend on python-docutils (>6.3) or on (python-docutils <= 6.3 and docutils-writer-manpage) ?
[08:22] <persia> Not trivially.
[08:22] <persia> One *could* set up some dummy packages and then depend on the disjuction of the dummies, but that would be annoying.
[08:22] <persia> Why not just depend on python-docutils > 6.3
[08:23] <randomaction> what about "python-docutils, python-docutils (>>6.3) | docutils-writer-manpage" ?
[08:23] <persia> Alternately, if python-docutils > 6.3 provides docutils-writer-manpage, then it should say so in the package declaration.
[08:24] <persia> randomaction: I don't think versioned dependencies and disjunctions work well together (although I could be wrong).
[08:24] <persia> Anyway, I think one should never have to do this.  One should depend on python-docutils, docutils-writer-manpage, and if python-docutils supplies docutil-writer-manpage it should Conflict/Replaces/Provides.
[08:25] <persia> at some point the transition will be considered complete (docutils-writer-manpage is not a package in any supported release), at which point one can drop the Provides from python-docutils.
[08:25] <persia> That will trigger NBS updates of thngs that depend on it.
[08:28] <randomaction> persia: that sounds more maintainable in the long run
[08:29] <persia> I think so :)
[08:30] <randomaction> my suggestion was only based on formal logic anyway :)
[08:32] <persia> randomaction: Theoretically, it should work.  I have a feeling it might not in practice, just from the set of apt bugs I've heard about.
[08:33] <persia> I imagine the various package management tool maintainers would appreciate patches to make the dependency logic formally correct, but I also presume there are better ways for anyone capable of doing that to spend their time :)
[08:35] <randomaction> dkpg design must have been base on the fact that there's a disjunctive normal form for any logical expression :)
[08:38] <persia> randomaction: I'm not convinced it was that fancy.  I suspect it started with just foo, bar, baz
[08:38] <persia> And then someone said "But either of these things could work" and filed a bug, so we got
[08:39] <persia> foo, bar, baz | quux
[08:39] <persia> And then someone said "But it only works with version 1.4!", and filed a bug, and so on.
[08:43] <persia> randomaction: For an extended example of how complex it has become: see http://algebraicthunk.net/~dburrows/blog/entry/package-management-sudoku/ :)
[08:52] <randomaction> that's great :)
[09:06] <superm1> tseliot, looks like vdpau works for me in both mythtv and mplayer w/ a fresh install
[09:06] <superm1> so if someone has a problem with an old upgrade, then you probably just need c/r on an old package (if that package is present)
[09:06] <tseliot> superm1: what happens if the old vdpau is installed?
[09:07] <siretart`> superm1: did you already fix the package wrt libvdpau-dev build dependency in lucid by chance?
[09:07] <superm1> other than not working?  I'm not really sure
[09:07] <superm1> siretart`, no i didn't want to go trumping on your stuff since you maintain it all in debian
[09:08] <siretart`> superm1: no worries, I need to be able to git-import-dsc ubuntu uploads anyway
[09:08] <siretart`> a proper git-format-patch would be of course ideal to preserve attribution and commit messages in our git properly
[09:09] <superm1> bjsnider might actually already have a diff ready.  i dont currently
[09:09] <tseliot> superm1: do you think I need to take care of the vdpau-dev package too (with c/r) or would vdpau be enough?
[09:10] <superm1> tseliot, it wouldn't hurt to do it on the -dev too i suppose
[09:10] <tseliot> superm1: ok
[09:10] <superm1> although, you know wait a min?  why is this even necessary?
[09:11] <superm1> i thought that it's the exact same library that's in libvdpau1
[09:11] <superm1> so it shouldn't be installable side by side
[09:11] <superm1> so when mplayer grows the proper depends, there will be an error at that time too
[09:12] <tseliot> superm1: we install libraries in their own directories now
[09:12] <superm1> but i'm saying /usr/lib/libvdpau.so.1
[09:12] <tseliot> there may still be a link in /usr/lib though
[09:12] <superm1> the one that comes from the package libvdpau1
[09:13] <superm1> since mplayer doesn't yet have a depend on it, there wasn't an error for having the old package in place
[09:15] <tseliot> superm1: are you suggesting that we don't use c/r?
[09:16] <ideasman42> Hi there, Im wondering about licensing for upstream, its a practical matter
[09:16] <superm1> tseliot, lets get the new mplayer sorted out first, and see if this problem is persisting for upgraders
[09:16] <ideasman42> How should I license 3D models that have no header?
[09:16] <ideasman42> I was told that I had to license every file
[09:16] <superm1> there's still plenty of time to add the c/r if it's necessary
[09:17] <tseliot> superm1: but still that would break the alternatives system
[09:17] <ideasman42> they are all creative commons, but does each file need to explicitly state this somehow?
[09:17] <persia> ideasman42: In what format are the models?
[09:17] <ideasman42> blend
[09:17] <superm1> tseliot, which would? the c/r?
[09:17]  * persia hunts up file format specs
[09:17] <ideasman42> blender-3d
[09:17] <tseliot> superm1: not having c/r
[09:17] <directhex> ideasman42, are the copyright owners and specific CC version clearly defined in a file accompanying the models in the source distribution?
[09:18] <superm1> tseliot, i'm not entirely familiar enough with how the alternatives system is working, can you elaborate why it would break it by not having it?
[09:18] <ideasman42> directhex, when we distributed the DVD yes, from our SVN repo its not so clear
[09:19]  * persia doesn't really understand why it's not listed at http://wiki.blender.org/index.php/Dev:Ref/File_Formats
[09:19] <ideasman42> persia, its an internal file format - basically a memory dump
[09:20] <persia> ideasman42: Well, my general recommendation is that if the format supports internal tags, to have the tag contain at least the license name.  It the format is text-based, include the license information has a comment, and if the format restricts comments reference it in a README file.
[09:20] <tseliot> superm1: /usr/lib/libvdpau_nvidia.so is installed by the old vdpau and it's a link in the nvidia package. Even if the latter overwrites the link from the former, when you remove the former you break alternatives (as that file is removed)
[09:21] <ideasman42> persia, ok, thanks. will add some README / COPYING file
[09:21] <superm1> Ah, because a real file trumps a symlink in terms of a package - and the alternative happens postinst, it's not owned by a package
[09:21] <ideasman42> as downstream requires
[09:21] <tseliot> superm1: right
[09:21] <persia> ideasman42: tags or comments are best though, if possible.  When using tags or comments, also reference in the README, and don't forget to include a copy of the license with the upstream source so that people who download can be confident they are reading the same text the authors read.
[09:21] <directhex> ideasman42, if it's a binary format then a README of some kind should be fine. and you really want "svn export" to pick up on it if downstream is meant to package frmo svn
[09:21] <superm1> so yeah, definitely need a c/r if there is an old package that is providing that file in karmic
[09:22] <persia> No, just needs replaces.
[09:22] <directhex> ideasman42, i think there's a #debian-games on oftc too
[09:22] <ideasman42> directhex, have a makefile for svn export and fedora use this
[09:22] <persia> c/r is only needed if in addition to overwriting that file, the rest of the files need to be removed from the system.
[09:23] <persia> In face, #debian-games@oftc is where many of those who maintain games in Ubuntu hang out.
[09:23] <persia> s/face/fact/
[09:23] <ideasman42> thanks guys. back to bugfixing :D
[09:23] <directhex> (yo frankie discussion on planet/reddit)
[09:24] <directhex> (pabs & runa seemingly both gave up on it)
[09:24] <persia> licensing issues?
[09:24] <runasand> ah, that one
[09:24] <runasand> persia: yes
[09:24] <directhex> oh, a runasand!
[09:24] <persia> heh.  That keeps more stuff out of the archive than just about anything else.
[09:25] <directhex> well now i feel like i'm talking about people behind their back
[09:25] <persia> At one point there were about 40 games that were well-packaged in d-g svn that were under license negotiation.
[09:25] <runasand> directhex: :)
[09:25] <directhex> i'm happy to do packaging for tricky packages, as i enjoy a challenge - but that excludes debian/copyright which isn't challenging, it's just unfun
[09:26] <runasand> directhex: that's what I figured as well
[09:26] <persia> I usually do debian/copyright first, so that I know I don't want to package something before I get too excited about making it work.
[09:26] <runasand> persia: that's one of things I learned :)
[09:26] <persia> (of course, this fact also helps keep me from packaging new stuff much)
[11:44] <jetienne> q. how do i know the content of a .deb ? all the files in it i mean
[11:44] <sebner> persia: sounds familiar to me *ehehehehe*, huhu btw :)
[11:46] <directhex> jetienne, dpkg -c /path/to/file.deb
[11:46] <jetienne> directhex: thx
[11:59] <hyperair> is it possible to copy a package from lucid to karmic-proposed?
[11:59] <hyperair> say podsleuth for example.
[12:01] <hyperair> no nevermind, it isn't possible for podsleuth's case due to a transition
[13:57] <xteejx> Is there a mentoring scheme for packaging?
[14:00] <xteejx> Also this "Quickly" thing, is it usable for packaging anything?
[14:00] <persia> um, kinda sorta.
[14:00] <persia> It does have a module that creates a package wrapper.
[14:00] <persia> And you can start from that to have a package.
[14:01] <xteejx> Hmm
[14:01] <persia> There isn't really a mentoring scheme, although lots of people are always happy to explain.
[14:01] <persia> Did the recipe I gave you before not work sufficiently for something?
[14:02] <mira|AO> hi, I have a strange problem; if this is the wrong channel please tell me a better one…
[14:02] <mira|AO> I need to package a TTF (OTF, actually) font for hardy.
[14:02] <mira|AO> defoma segfaults on me.
[14:02] <xteejx> persia: I'll be honest I got really annoyed with it. I'm not sure if packaging is my thing, it's too damn difficult, and there's too many things to do with the rules file (poorly documented). Its a real shame, because I think that's the reason why there are very few new packagers :(
[14:02] <mira|AO> There is Debian #477435 but I did install libft-perl
[14:03] <mira|AO> does anyone have a solution? debian seems to have dropped defoma, but that was post-hardy AFAICT
[14:03] <persia> xteejx: As I tell nearly everyone at some point, despite packaging being deceptively easy, the best way to learn is really to debug existing packages and get a feel for how things work :)
[14:03] <MTecknology> persia: You want to check out the man page and let me know what you think?
[14:04] <persia> MTecknology: Please ask generally.  I'm a bit busy now, and surely someone else can help.
[14:05] <xteejx> persia: Easy!? I know what *needs* to be done, I just don't know how to do it. I know what goes where, and how it *should* all tie in.
[14:06] <MTecknology> Anyone up for letting me know what they think of this man page I made up? Nit picking welcome :)  http://paste.ubuntu.com/363246/
[14:07] <persia> xteejx: Just ask for each problem, but again, looking at other examples can help give you ideas.
[14:08] <xteejx> I think MOTU should have a school or session on how to create a package from scratch. Just pick an unpackaged upstream from ...wherever really... show the complications that can arise, how to effectively write a rules file, using debhelper and the dh_** things in the rules file, etc.
[14:08] <persia> xteejx: I've offered to teach such a class to the developer training group.  Watch their wiki to see when it gets schedule.
[14:08] <persia> d
[14:08] <xteejx> I'd be surprised if after reading something like that, we wouldn't have new packagers, this is probably one of the main problems they face as I am :(
[14:09] <xteejx> persia: This Dev OpenWeek?
[14:09] <persia> No.
[14:09] <persia> DEveloper Training is compeltely separate from Open Week.
[14:09] <xteejx> ok
[14:09] <MTecknology> xteejx: I'm packaging something that was never packaged before using the complete guide - so far I don't think I've been stuck (help from here too)
[14:10] <xteejx> MTecknology: Did you have any previous experience?
[14:10] <mira|AO> is there maybe a more appropriate channel for font packaging related issues?
[14:10] <persia> The wiki page keeps moving, but I *think* it's currently https://wiki.ubuntu.com/Packaging/Training
[14:10] <xteejx> Every Thursday?
[14:11] <MTecknology> xteejx: not really
[14:11] <persia> Well, assuming there is sufficient faculty, yes.
[14:11] <\sh> grmpf...
[14:12] <xteejx> MTecknology: Don't you have problems with debhelper and all the commands in debian/rules as well? It's doing my head in! lol
[14:12] <\sh> regarding this http://www.mail-archive.com/debian-devel@lists.debian.org/msg230777.html discussion, dpkg --purge / apt-get remove --purge shouldn't delete the /opt dir, but somehow it does exactly that, because of exactly the reasoning the threads tells us
[14:12] <\sh> how can someone avoid that?
[14:12] <xteejx> persia: If you do a session for something like that I can guarantee I'll be there!!
[14:12] <MTecknology> xteejx: I tried to work on existing packages but I coudln't figure it out - I'm hoping that a new app will be easier to package and a good place to start
[14:13] <persia> \sh create opt.deb that contains only /opt as an empty directory and pin it?
[14:13] <xteejx> That's my thought, and then I can see the whole process too
[14:13] <MTecknology> xteejx: debian/rules - last thing I think I have left; this part could use more explanation
[14:13] <persia> New packages are really harder.
[14:13] <\sh> persia: or we include /opt in base-files and not creating it in base-files postinst?
[14:13] <persia> Because there's so much that can go wrong.
[14:14] <persia> 95% of new packages I see from new packagers are wrong in several ways, and even after all the issue are corrected fail to follow best practices.
[14:14] <ogra> just touch /opt/blah :)
[14:14] <persia> \sh: No idea.
[14:14] <ScottK> \sh: It's optional in FHS, so failing to provide it isn't wrong.
[14:14] <ogra> dpkg wont delete non empty dirs
[14:14] <\sh> ogra: it will...
[14:14] <ogra> thats a bug
[14:14] <\sh> ogra: it already has in my test
[14:14] <ScottK> ogra: I think the problem is not deletion on removal, but deletion on purge.
[14:15] <MTecknology> persia: will lintain help me with that?
[14:15] <ogra> oh, purge
[14:15] <ogra> i messed that
[14:15] <ogra> *missed
[14:15] <persia> MTecknology: Not really, no.
[14:15] <MTecknology> persia: oh..
[14:15] <persia> lintain clean != cleanly packaged.
[14:16] <xteejx> MTecknology: I got up to that point, and started hitting my head on the wall... and then the files/folders have to comply with the set /usr/bin/ /usr/share/ directory structure!
[14:16] <persia> So, that's why it's nice to work with existing packages.
[14:16] <persia> They already work, except for something that's wrong.
[14:16] <xteejx> Yeah, but chances are that will lead to coding....
[14:17] <persia> So one can adjust packaging issues, or apply patches, or similar in an isolated fashion within a working framework.
[14:17] <mok0> persia: actually, that should be an implication: linitan clean <= cleanly packaged
[14:17] <MTecknology> xteejx: actually.. I did some coding on this :P
[14:17] <xteejx> heh...
[14:17] <persia> mok0: Hard to do, because there are many unclean but correct ways to package.  Better to have another tool for that.
[14:18] <mok0> persia: I was just commenting on your statment containing the != unequality :-)
[14:18] <persia> Right.  I think it *should* be an unequality.
[14:18] <persia> I think there is huge value in having something that validates policy and common practices.
[14:18] <mok0> Uhm, no. A clean package will also be lintian clean
[14:18] <persia> But I think that's a different tool than something that validates style.
[14:19] <persia> Not necessarily.
[14:19] <ScottK> mok0: Generally, yes, but not always.
[14:19] <persia> There's lots of times you want to do something lintian doesn't like, but you know it to be correct.
[14:19] <ScottK> Lintian documents general best practice.  It's not always appropriate.
[14:19] <mok0> Assuming the tool works
[14:19] <persia> Not all of these are bugs in lintian.
[14:19] <ScottK> In Debian the now autoreject uploads for some issues that lintian flags.
[14:20] <ScottK> My favorite so far was the autorejection of zlib for containing an embedded copy of zlib.
[14:20] <persia> heh :)
[14:20] <persia> Does autorejection ignore overrides?
[14:20] <ScottK> Depends on the tag.
[14:20] <persia> Oh my.
[14:21] <ScottK> Some are over-rideable, some aren't.
[14:21] <mok0> Nice way to limit the size of the archive :-)
[14:21] <persia> Well, no.  It doesn't do that.
[14:21] <persia> It's possible to construct many huge lintian-clean packages.
[14:21] <persia> But it may not be possible to construct a lintian-clean distribution.
[14:21] <mok0> Right. It limits the growth in the size of the archive
[14:21] <xteejx> Is that correct, we don't *actually* build the .deb files, and that the autobuilders do that for us from the source and the rules file?
[14:21] <persia> (or at least it puts a huge load on the installer and image building tools)
[14:22] <ScottK> I'm OK with that in general, although I think delegating to the lintian authors is probably not the best way to do it.
[14:22] <persia> xteejx: Most of us build .deb files for testing and throw them away, and then the autobuilders make trusted ones.
[14:22] <xteejx> Is that the debuild -sa ?
[14:23] <persia> mok0: It *doesn't* limit the growth.  Like I said, it's possible to construct lots of large lintian-clean packages.
[14:23] <persia> xteejx: No.  -sa makes sure that the orig.tar.gz is listed in the .changes file.
[14:23] <xteejx> Ohhh, it's just debuild on its own :P
[14:23] <persia> xteejx: I use sbuild for building .debs.  Some people use pbuilder.  Other tools are cowbuilder, qemubuilder, dpkg-buildpackage, etc.
[14:23] <persia> No.  That builds source *and* binary.
[14:24] <MTecknology> alrighty; the rules file has me lost
[14:24] <xteejx> ahhhh
[14:24] <persia> debuild -b builds a binary.
[14:24] <persia> But any binary built locally is suspect because the build-depends haven't been validated.
[14:24] <xteejx> that's why we use pbuilder right?
[14:24] <persia> MTecknology: 90% of the time /usr/share/doc/debhelper/rules.tiny should do 90% of what you need.
[14:24] <persia> Right.
[14:24] <xteejx> woohoo I'm learning :)
[14:25] <ScottK> But understanding what you are doing is still recommended even if rules.tiny works.
[14:25] <persia> OK.  So lets fix some bugs.
[14:25] <MTecknology> persia: I have one man page that wasn't there when I started and there's one file.c that produces one binary.
[14:25] <xteejx> Who?
[14:26] <persia> MTecknology: Hrm.  You probably need special stuff then.
[14:26] <persia> (or create a Makefile)
[14:26] <persia> xteejx: You.  Me.  Someone else :)
[14:26] <MTecknology> persia: sorry, there's a Makefile there, also README and COPYING
[14:26] <xteejx> Ohhh hehe I do enough triage as it is ;) I wanna get my hands dirty with packaging and then I can work through both
[14:27] <persia> Then it probably works for you.
[14:27] <xteejx> Makefile should be easier ./configure make make install thing
[14:27] <persia> xteejx: OK.  go pick a bug that you've triaged (so you understand it) on a package in universe, and let's fix it.
[14:27] <xteejx> Oh God
[14:29] <xteejx> I'd love to fix bug 230258
[14:29] <xteejx> but it's packaging
[14:30] <persia> Right, but it doesn't give you an example package to work within :)
[14:30] <persia> Pick something that looks like a packaging bug that isn't a needs-packaging bug.
[14:30] <xteejx> Ummmm..........
[14:30]  * xteejx hunts
[14:34] <xteejx> Trying to find one is hard!!
[14:35] <persia> OK.  I'll give you one if you want.
[14:35] <xteejx> ok
[14:35] <persia> libpam-alreadyloggedin FTBFS on i386 and powerpc because there's an issue with ld and stack-smashing-protection.
[14:35] <persia> So it needs to use gcc instead of ld to build the final library.
[14:36] <xteejx> bug number?
[14:36] <persia> Dunno if it's filed yet.  Go check :)
[14:36] <xteejx> lol
[14:36] <MTecknology> persia: wow - rules.tiny is micro.. I'll try that out..
[14:37] <xteejx> persia: Not filed
[14:37] <persia> OK.  File it.  Assign yourself.  Bug title is something like "libpam-alreadyloggedin FTBFS on i386 and powerpc"
[14:38] <EtienneG> hello all
[14:38] <persia> Hey EtienneG
[14:38] <xteejx> FTBTS = fails to build from source right?
[14:38] <xteejx> Hi
[14:38] <persia> Right.
[14:38] <EtienneG> just curious: is there any plan for Moonlight 2 in Lucid?
[14:38] <MTecknology> Is this bad output from debuild -S?  WARNING generated by debuild:  Making debian/rules executable!
[14:38] <EtienneG> hello persia!
[14:39] <persia> MTecknology: No.  That's safe.
[14:39] <xteejx> persia: bug 512806
[14:40] <persia> OK.  Now grab the lucid source, and look around at it.  You'll see how everything fits together.
[14:40] <MTecknology> 5min download for build deps.... hurray 90k network
[14:41] <xteejx> persia: That's a small lib
[14:41] <persia> Yep.  That's part of why I picked it as an example :)
[14:43] <xteejx> persia: Anything I should be looking at?
[14:43] <xteejx> I run i386, so try to build?
[14:43] <persia> Well, I'd start by looking at debian/rules and Makefile, to make sure I understood how the package gets built.
[14:44] <persia> We know we have to change ld to gcc, but we need to make sure we know how it gets called first.
[14:44] <persia> Build log for i386 is https://launchpad.net/ubuntu/+source/libpam-alreadyloggedin/0.3-1/+build/1428110/+files/buildlog_ubuntu-lucid-i386.libpam-alreadyloggedin_0.3-1_FAILEDTOBUILD.txt.gz
[14:45] <xteejx> I'm guessing from the build log that the problem is: pam_alreadyloggedin.c:267: undefined reference to `__stack_chk_fail_local'
[14:46] <MTecknology> It was building so nice - until the man page - http://paste.ubuntu.com/363263/
[14:46] <persia> Right.  If you want details on why the fix is switching from ld to gcc you can check backscroll in -devel and -meeting when I discused it previously.
[14:46] <persia> This was my bug, I just hadn't gotten to it yet.
[14:46] <xteejx> ok
[14:46] <xteejx> I'm looking at pam_alreadyloggedin.c line 267
[14:46] <xteejx> and it's gibberish
[14:47] <xteejx> same as rules and Makefile lol
[14:47] <persia> Yeah.  Ignore that.  The fix is in how it builds (packaging), not in the code.
[14:47] <persia> (another reason I picked this exampe)
[14:47] <xteejx> cool
[14:47] <MTecknology> Is this error just because my Makefile doesn't have anything about the man file?
[14:48] <xteejx> persia: I'm guessing its one of the first 2 lines in the Makefile
[14:48] <persia> xteejx: Those are just variable defintions.
[14:49] <persia> xteejx: You may want to read the make manual section about variables and about rules to get a good understanding to read this file.
[14:49] <xteejx> I know what variables are
[14:49] <geser> MTecknology: have you a debian/lal.docs file?
[14:49] <persia> You don't have to read the entire manual, but skim through until you understand debian/rules and Makefile
[14:49] <xteejx> Just....
[14:49] <MTecknology> geser: no, there's a docs/lal.1 file
[14:51] <geser> then why does cp say the file isn't there? (docs/lal.1)
[14:52] <xteejx> persia: Quick question... the $(MKDIR) $(FAKEROOT)$(SECUREDIR) bit in the Makefile, is that just how they insert the defined variables above, so for this one it'd be to run "mkdir -p /lib/security" ??
[14:52] <xteejx> btw its the first install: line
[14:52] <MTecknology> geser: I have no idea.. I just created that file yesterday
[14:52] <persia> Right.
[14:52]  * xteejx holds back from swearing in a good way hehe
[14:53] <MTecknology> oh well - I need to run, I'll figure it out later
[14:53] <xteejx> Yippee!
[14:53] <xteejx> :P
[14:53]  * MTecknology runs off
[14:53] <xteejx> and the next would be "install -m 700 pam_alreadyloggedin /lib/security" ?
[14:54] <persia> Let's not review every line, but you're getting the idea.
[14:54] <persia> Just make sure you understand every line :)
[14:54] <xteejx> I think I'm getting it yes
[14:54] <xteejx> some bits a little confusing though
[14:56]  * ScottK tries again
[14:56] <xteejx> persia: So in reality, assuming I want to make a package from scratch, I could just redefine the variables, or insert new ones to get things in the right place?
[14:56] <persia> xteejx: Sure, but we're working with an existing package now.
[14:56] <xteejx> Of course :) Just wondering how it all fits
[14:56] <persia> The idea being that working with a few existing packages will help you understand how everything works, and make packaging easier.
[14:56] <xteejx> :)
[14:58] <persia> So just let me know when you have a suggestion as to how to swtich from ld to gcc.
[14:58] <mira|AO> nm, got it… Invalid_File_Format – cf. /usr/share/doc/libttf-dev/docs/apiref.txt.gz
[14:59] <mira|AO> libttf doesn’t seem to handle *.OTF files
[14:59] <xteejx> persia: Replace the LD = ld variable with LD = gcc ?
[15:00] <xteejx> Or change the $(LD) $(LDFLAGS) $(OBJS) -o $@ line to be $(CC) $(CFLAGS) $(OBJS) -o $@  ?
[15:01] <persia> I'd probably try $(CC) $(LDFLAGS) $(OBJS) -o $@ first.
[15:02] <persia> (can you tell me why?)
[15:02] <xteejx> So that gcc still uses the -lpam.... part? (I don't understand why though)
[15:04] <persia> OK.  Check the gcc and ld manpages, to figure out what the arguments do.
[15:06] <mira|AO> usually, CCLD is used as linker, which is the same as CC, as ld cannot, by itself, know enough to link a regular unix userspace utility
[15:06] <persia> Often, yes.  In this case, it's only linking a shared library, which ought to work.
[15:07] <persia> But there's some little-understood interaction with the stack-smashing protector, and it's confusing LD.
[15:08] <mira|AO> even shared objects need things like crti.o, crtbeginS.o, …
[15:08] <mira|AO> so, no
[15:08] <mira|AO> ;)
[15:09] <persia> mira|AO: This is a PAM plugin.  Works fine with ld in debian :p
[15:10] <xteejx> persia: I can't see a "gcc -lpam" option in the man gor gcc
[15:10] <xteejx> *for
[15:11] <persia> xteejx: search for -l
[15:11] <persia> the "pam" part is a library name.
[15:13] <xteejx> It searches for pam using the -l option ... I can read it fine, it's understanding it that's the problem
[15:13] <persia> Hrm.  Anyone have a good link to an intro doc on using gcc as a compiler and linker?
[15:14] <xteejx> Anyone able to tell me what those 2 words mean? :P
[15:15] <mok0> "compiler" and "linker" ?
[15:15] <xteejx> I think a compiler is a program that compiles code, right?
[15:15] <mok0> right
[15:15] <xteejx> to what end?
[15:15] <mok0> a linker combines several chunks of compiled code to one executable
[15:16] <mok0> xteejx: a compiler "translates" human readable program code (for example C, C++, FORTRAN, etc) to machine code
[15:16] <xteejx> so in essense one makes the code the linker needs to pull into an executable?
[15:16] <xteejx> I understand
[15:16] <mok0> xteejx: yes, because a program is often split into many files
[15:16] <mok0> xteejx: and each file is compiled separately
[15:18] <xteejx> ohhhhhh, so all these .c files or whatever are just the code that's needed, and things like gcc read them, put them into machine code from the 'human readable' code that can be passed on to a linker to compile *that* into an executable?
[15:18] <persia> Well, for the linker to *link* into an executable, but yes.
[15:18] <mok0> xteejx: yes
[15:19] <xteejx> cool
[15:19] <mok0> xteejx: but with gcc, those two functions (compiler and linker) are both carried out by the "same program"
[15:19] <persia> OK.  Now that this has been explained (thanks mok0), do you understand why I suggested that substitution?
[15:20] <persia> Err, let me revert that, since there is more explanation (which may be useful)
[15:22] <xteejx> huh?
[15:23] <persia> I had thought the explanation was complete, and so was proceeding, but the explanation may not have been complete, so I wanted to withdraw the next question until you understood enough to move forward.
[15:24] <xteejx> phone call brb
[15:25] <xteejx> back, sorry about that
[15:26] <xteejx> persia: Is the answer so that it can compile the pam library for use with pam_alreadyloggedin?
[15:26] <persia> Rather that we want to use gcc in the first case to compile the objects, and in the second case to link against the pam library.
[15:26] <persia> So we need to pass different arguments to gcc to achieve this.
[15:27] <xteejx> the objects being the .o files?
[15:28] <xteejx> and shared libraries are .so ?
[15:28] <persia> Right.
[15:28] <xteejx> This is a rather steep learning curve, but getting there :)
[15:29] <persia> Indeed, but by working with an existing package, this is the *only* bit you need to learn to fix the bug.
[15:29] <persia> And for the next bug, you'll learn a different bit.
[15:29] <persia> And eventually you'll be an expert :)
[15:29] <xteejx> Hopefully! :D
[15:30] <persia> OK.  So do you understand the change?
[15:31] <xteejx> That we need to change from ld to gcc (for whatever reason to fix the bug), and we need to keep the same flags so that gcc can replace ld, but without replacing what it was meant to do, i.e. continue to use LDFLAGS so that the objects can be compile and linked to the libraries?
[15:32] <persia> RIght.
[15:32] <persia> I don't 100% understand why it needs to change either, but I have it on good authority that it needs the change.
[15:32] <xteejx> :D :D :D :D :D :D
[15:32] <persia> So, make that change.
[15:32] <xteejx> done, saved
[15:32] <persia> This package stores all the patches in the diff.gz, so we don't have to worry about patch systems.
[15:33] <persia> Some packages store patches in debian/patches, and we'd have a different procedure to make the change.
[15:33] <mok0> persia, probably has to do with options that are silently set when gcc calls ld
[15:33] <persia> Next, run `dch -i` to add a new revisoin to the changelog, and describe your changes.
[15:33] <xteejx> thought that would come next :)
[15:34] <persia> mok0: There's some special hints for the SSP involved that were added to gcc, but not yet to ld.
[15:34] <mok0> ok, yeah
[15:34] <xteejx> what would i write for description? "changed usage from ld to gcc Closes (LP: #*****)" ?
[15:35] <sistpoty|work> hm... http://qa.debian.org/developer.php?login=ubuntu-motu@lists.ubuntu.com
[15:35] <persia> That ought be sorted.
[15:36] <persia> xteejx: http://irclogs.ubuntu.com/2010/01/25/#ubuntu-devel.html contains the log of the discussion I had about it.
[15:36] <persia> (near the top)
[15:37] <xteejx> i'll have a look at that later, bookmarked :)
[15:37] <persia> I'd probably put something like "Use gcc to call the linker to take advantage of improved .spec files (LP: #xxxxxxx)"
[15:38] <persia> Oh, I wsa referencing it to help you write the changelog.
[15:38] <persia> It's not worth bookmarking.
[15:38] <xteejx> ohh
[15:38] <persia> It's maybe 10 lines of discussion from around 4:35
[15:38] <kamalmostafa> Motu magic needed...  "bzr branch lp:ubuntu/libavg" pulls a slightly stale revision.  (Last time I had a similar problem with another pkg, geser and james_w declared it to be a "spurious failure to import" and fixed it instantly).
[15:38] <xteejx> Ok, changelog done
[15:39] <persia> xteejx: Great.  Next `debuild -S -uc -us` to get a candidate source package.
[15:39] <xteejx> persia: Standards-Version: 3.8.1  .... bump to 3.8.3?
[15:39] <persia> Nope.  We leave that alone for packages maintained in Debian.
[15:39] <xteejx> ok
[15:40] <persia> We only update it for stuff that doesn't have a Debian maintainer, and for which we are willing to put in the effort to maintain properly.
[15:40] <xteejx> debuild: fatal error at line 1340:
[15:40] <xteejx> dpkg-buildpackage -rfakeroot -d -us -uc -S -uc-us failed
[15:40] <persia> OK.  Why?
[15:40] <xteejx> Pass
[15:40] <persia> Then paste more context.
[15:40] <persia> (in a pastebin)
[15:40] <xteejx> its my fault
[15:40] <xteejx> -uc-us should have a space :P
[15:41] <geser> kamalmostafa: unless james_w can help you, you need to do it the "old" way: apt-get source libavg
[15:41] <xteejx> persia: Done, it complained about standards version, but mehh
[15:41] <persia> xteejx: Now, try compiling it for i386 or powerpc (using pbuilder or sbuild or something)
[15:42] <xteejx> i386 here
[15:42] <xteejx> how to I clean pbuilder?
[15:42] <xteejx> dw
[15:43] <dholbach> Day 2 of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in #ubuntu-classroom (on irc.freenode.net) in 17 minutes!
[15:44] <xteejx> persia: No build errors
[15:45] <persia> xteejx: Just to confirm, try building the original package to make sure you can replicate the failure.
[15:47] <xteejx> persia: I did 'sudo pbuilder build --architecture powerpc libpam-alreadyloggedin_0.3-1ubuntu1.dsc ' but it built an i386.changes
[15:47] <xteejx> .deb even
[15:47] <persia> That's correct.  It built it for i386, right?
[15:47] <xteejx> yes
[15:47] <persia> That's how it says which arch the .deb is for.
[15:48] <xteejx> I tried --architecture powerpc
[15:48] <persia> Your machine probably can't be a powerpc :)
[15:48] <xteejx> ohhh I see, it only builds on that hardware for that arch?
[15:48] <persia> Well, there are ways to fake it for certain architectures, like using i386 on amd64, or using qemubuilder for armel.
[15:48] <persia> But mostly, yeah.
[15:49] <xteejx> shame my ps3 won't run ubuntu well .... lol
[15:49] <kamalmostafa> geser: okay, but it sure seems like that flow will involve more work later -- someone will eventually have to apply my patch to a branch, right?
[15:49] <kamalmostafa> (BTW, as suspected package 'dia' also exhibits the "cannot find -lssl" problem if I try to build the current Lucid source -- it has the same python LOCALMODLIBS problem)
[15:50] <xteejx> persia: the original .dsc failed :)
[15:50] <persia> In the same was as the buildd log?
[15:51] <xteejx> yup
[15:51] <persia> Excellent.
[15:51] <xteejx> ld final link failed, etc
[15:51] <persia> Now use debdiff to generate the differences between your new candidate version and the old version.
[15:51] <persia> Make sure that the debdiff only includes the changes you intended to add.
[15:52] <xteejx> which one is first i forget is it "A Bubuntu1 > C"
[15:52] <persia> debdiff old new
[15:52] <xteejx> ok
[15:53] <geser> kamalmostafa: as we can't build from branches yet, your sponsor has to upload a source package anyways. as the libavg branch isn't uptodate anyways getting it more outdated shouldn't matter much
[15:53] <xteejx> persia: Done :)
[15:54] <persia> xteejx: Attach the debdiff as a patch to the bug, and subscribe ubuntu-universe-sponsors.
[15:54] <persia> Someone will either upload or critique your work.
[15:54] <xteejx> Ok :)
[15:54] <persia> And thanks for fixing a bug.  Now go find another one and fix that.
[15:54] <kamalmostafa> geser: okay, thank you.
[15:55] <persia> I won't walk you through it again, but you should have the basic procedure down: 1) understand the bug, 2) get the source, 3) understand the part of the source related to the bug 4) fix the bug 5) document the fix 6) create a source 7) test to confirm the change did what you wanted 8) request sponsorship
[15:56] <persia> oops :)
[15:57] <xteejx> done...bug 512806 :) Again, persia you have been brilliant! Thank you.
[15:57] <xteejx> lol
[15:59] <xteejx> I can delete all this libpam stuff now right?
[15:59] <persia> If you're sure the patch on LP is correct, yeah.
[16:00] <xteejx> Cool
[16:00] <xteejx> I'll be back later, gonna get some food, thanks again persia you're just brilliant!!
[16:07] <NateW> im getting "gpg: skipped "Nate Wiebe <nate@natewiebe.com>": secret key not available" when building a source file using debuild -S
[16:07] <NateW> i have already created a gpg key
[16:08] <persia> NateW: Did you add a comment to your identity when creating your GPG key?
[16:10] <NateW> yes
[16:10] <persia> Did you put the same comment in your name in the changelog entry?
[16:10] <NateW> no.. so i should change it then?
[16:12] <persia> yes.  The two have to match exactly.
[16:12] <persia> So you either need to edit your key, or your changelog.
[16:12] <NateW> how would i edit the key?
[16:13] <geser> did you upload your key to a keyserver yet?
[16:13] <NateW> yes
[16:14] <persia> I find that using the GUI tools tend to be the easiest way to edit the key.
[16:15] <geser> just add a new uid and revoke the old one (if wanted) but you can keep the old uid too (revoking is the only option, you can't delete it)
[16:15] <persia> Are you sure you can't edit it.
[16:15] <geser> or just use the comment in your changelog entries too
[16:15] <persia> My signatures are preserved over the edits I've done.
[16:16] <persia> So I've presumed my UIDs have been preserved.
[16:16]  * persia uses seahorse to edit the gpg key
[16:16] <NateW> after editing i have to reupload correct?
[16:17] <persia> RIght.
[16:17] <geser> you can't change the uid after creating (not sure about comments) as this would make signature useless (collect first signatures and change later the uid to something different)
[16:18] <persia> Maybe it only works for the comment.
[16:19] <persia> But I could be wrong.  It's been a *long* time since I had a comment in a GPG key (and that was probably a PGP key, back then)
[16:19] <NateW> alright.. its working.. thanks for the help
[16:57] <kamalmostafa> geser: please have a look at bug 512861 -- is my description of the problem correct?  its ready for sponsor review, I think.
[17:01] <geser> kamalmostafa: looks ok, I see that you set py_localmodlibs="" (which is ok). have you looked if dropping this variable at all is possible or would that channge too much?
[17:11] <kamalmostafa> geser: I wanted to minimize the change (and make it obvious as to "what happened to py_localmodlibs" if anyone was looking for it in the future).  But it would be easy to remove it altogether, if you'd prefer that.
[17:12] <geser> ideally this should get included by upstream, so we don't have to look at it again in future :)
[17:13] <kamalmostafa> geser:  oh, and btw, I see the *exact* same construct in package 'dia' also, and it also FTBFS in my own pbuilder.
[17:13] <kamalmostafa> geser: I will file an upstream bug and submit the patch, once its approved here.
[17:19] <xteejx> Hey guys, I'm trying to fix FTBFS in emacs-chess-2.0b6, but http://paste.ubuntu.com/363328/ it appears the command emacs cannot be found. Do I have to explicitly tell it /usr/bin/emacs ?
[17:19] <xteejx> the error I think is in the makefile
[17:22] <geser> is emacs installed through build-depends?
[17:22] <xteejx> geser: No there is no emacs in build-depends
[17:22] <xteejx> oops, that's the problem :P
[17:23] <xteejx> thanks geser I'll try that ;)
[17:24] <xteejx> Can I do "Build-Depends: emacs23 | emacs 22" ?
[17:25] <geser> sure
[17:31] <xteejx> I ran the updated .dsc through pbuilder, where can I find the build log?
[17:31] <xteejx> (I have more problems with menus)
[17:32] <geser> in your terminal, but pbuilder has an option to also write it into a file
[17:32] <xteejx> geser: What's the option for that, I can't scrollback far enough :(
[17:33] <geser> pbuilder build --logfile mypackage.log mypackage.dsc (the same works if you use the pbuilder-dist wrapper)
[17:33] <xteejx> pbuilder-dist??
[17:34] <xteejx> No worries, that's one to learn methinks, thanks geser :)
[17:40] <sistpoty|work> xteejx: I find PKGNAME_LOGFILE=yes in .pbuilderrc quite useful
[17:40] <xteejx> oooh didn't know about that :)
[17:40] <kamalmostafa> xteejx: fyi, pbuilder-dist is good stuff -- essentially, it lets you set up pbuilders for different release/architectures so that you can, for example, build Lucid packages on a Karmic machine, or build i386 packages on an amd64 machine.   The man page 'man pbuilder-dist' explains in more detail.
[17:41] <xteejx> kamalmostafa, as good as that sounds, I'm running Lucid i386 at the mo anyway, I don't think it's of any use to me, I would use AMD64 Ubuntu, but my laptop is too new, something to do with the instruction set isn't supported by the kernel, but 32 bit mode is
[17:42] <xteejx> otherwise, I'd be building for amd64 and i386 or testing them anyway
[17:42] <xteejx> but it's another snippet that I'm putting in Tomboy for future reference :)
[17:51] <xteejx> Another missed build-depends: texinfo heh least this one seems to be easy so far :D
[19:03] <shadeslayer> persia: around?
[19:04] <shadeslayer> ok well  ok apparently debuild -S -sa does not recognise the original tarball and gives me : http://paste.ubuntu.com/363387/
[19:04] <shadeslayer> the orignal tarball is rekonq_0.3.33.orig.tar.gz
[19:05] <shadeslayer> as you can see from line 49 it seems to be a tarball problem.... or am i wrong?
[19:07] <sebner> shadeslayer: it seems the tarball is b0rken. download the sources again and make a new .orig one
[19:08] <shadeslayer> sebner: the thing is its a git clone and i archived it with git archive
[19:08] <sebner> shadeslayer: ah, haven't worked with git archive yet, I'm sorry
[19:09] <shadeslayer> sebner: it worked till yesterday,today they updated the git repo and now its broken?
[19:09] <shadeslayer> weird
[19:10] <shadeslayer> maybe im archiving wrong with : git archive <revision no.> >rekonq
[19:20] <MTecknology> This rules file is throwing me for a loop; I try to compare to others but they all seem to be so different and some are really ugly
[19:22] <fabrice_sp> a package that has entered into testing on the 23rd should have been automatically synced in lucid?
[19:22] <fabrice_sp> or no "automatic" synced has been performed since the 23rd?
[19:22] <fabrice_sp> s/synced/sync/
[19:23] <fabrice_sp> it's for bug 512667
[19:29] <MTecknology> How do I include a man page? There's a debian/docs file. I added docs/lal.1 to it. I have the docs/lal.1 file as well....
[19:39] <randomaction> MTecknology: dh_manpages does it, you need to add it to debian/PACKAGENAME.manpages
[19:40] <randomaction> I mean, add filename to debian/PACKAGENAME.manpages
[19:41] <MTecknology> randomaction: how do I install dh_manpages?
[19:42] <randomaction> it should be called from debian/rules. If you use rules.tiny, this happens automagically.
[19:44] <MTecknology> alrighty, so I was just in the wrong file
[19:44] <MTecknology> I'll try it now :)
[19:59] <MTecknology> last problem.. I ran lintain and it gave me this.. http://paste.ubuntu.com/363419/
[19:59] <MTecknology> In the changelog it's 1.0-0ppa1
[20:02] <shadeslayer> sebner: it worked out.... people from #git helped :)
[20:02] <fabrice_sp_> MTecknology, this happen when you don't have a .orig.tar.gz tarball
[20:02] <fabrice_sp_> debuild generate in that case a native package
[20:04] <MTecknology> fabrice_sp_: so I don't need to worry about it?
[20:06] <geser> in most cases you want non-native packages
[20:09] <randomaction> MTecknology: do you have an upstream tarball?
[20:10] <fabrice_sp_> MTecknology, you should have a upstream source tarball
[20:12] <MTecknology> fabrice_sp_: randomaction: I only got the git source from upstream
[20:13] <randomaction> you should probably export it as a tarball
[20:13] <fabrice_sp_> randomaction is faster ;-)
[20:13] <randomaction> it they provide some tarball, your life is easier
[20:14] <MTecknology> they don't, it's a new package too
[20:14] <fabrice_sp_> MTecknology, rename the git export directory to <source>.orig, and copy it to add the debian directory
[20:15] <fabrice_sp_> this way, you will have a <source> directory with the packaging changes and <source>.orig directory with original source
[20:16] <MTecknology> fabrice_sp_: so mv lal-git lal-1.0/debian/lal.orig ?
[20:17] <fabrice_sp_> MTecknology, nop: cp lal-git lal-<version>.orig and mv lal-git lal-<version>
[20:18] <fabrice_sp_> you should have both directory at the same level
[20:18] <MTecknology> thanks :)
[20:18] <shadeslayer> ok anyone around to look at : http://paste.ubuntu.com/363430/ : lines 51 and 52
[20:19] <shadeslayer> please explain those warnings to me :)
[20:19] <fabrice_sp_> shadeslayer, you created 2 new empty files in the root directory of your source. Just delete them
[20:20] <fabrice_sp_> if it's something produced during the build process, you should delete them in the clean target of debian/rules
[20:20] <shadeslayer> fabrice_sp_: ah nice catch
[20:21] <shadeslayer> fabrice_sp_: no apparently i also copied the original tarball into the extracted source.... dont know how that happened :P
[20:21] <randomaction> shadeslayer: you're using CDBS, right?
[20:21] <randomaction> and there's tarball.mk in your debian/rules?
[20:22] <shadeslayer> yeah
[20:22] <MTecknology> fabrice_sp_: that gave me two top level directories, lal-1.0 and lal-1.0.orig; with lal-git inside of lal-1.0/
[20:22] <shadeslayer> and for the second question lemme check
[20:23] <fabrice_sp_> MTecknology, lal-1.0 should contain the content of lal-git, so no intermediate directory there
[20:23] <shadeslayer> randomaction: i have : /usr/share/pkg-kde-tools/makefiles/1/cdbs/kde.mk
[20:23] <MTecknology> fabrice_sp_: fabrice_sp_ ok, so that's something I already did before :P
[20:23] <shadeslayer> randomaction: anyways ive deleted both those files and it worked :)
[20:23] <randomaction> great
[20:24] <shadeslayer> wth... 32 bit version was compiled too!
[20:24] <shadeslayer> thats quick :P
[20:24] <MTecknology> fabrice_sp_: lal-1.0.orig has no debain/ directory in there
[20:24] <fabrice_sp_> MTecknology, ok :-D So the content of lal-1.0 and lal-1.0.orig should be almost the same. lal-1.0 should contain an additional debian directory
[20:24] <fabrice_sp_> right
[20:25] <MTecknology> fabrice_sp_: I also made a code change and added a man page to the new one
[20:25] <fabrice_sp_> MTecknology, if it's a new application, you should use a patch system
[20:25] <MTecknology> fabrice_sp_: oh...
[20:25] <fabrice_sp_> and add the man into debian directory, and use <paxkaga>.manpages to install it
[20:26] <fabrice_sp_> s/<paxkaga>/<package>/
[20:26] <MTecknology> fabrice_sp_: oh, I had docs/lal.1 and debian/lal.manpages
[20:26] <fabrice_sp_> MTecknology, did  you add docs/lal.1?
[20:27]  * fabrice_sp_ keeps typing lala! :-)
[20:27] <MTecknology> ya; it'll be in the next git version though
[20:27] <fabrice_sp_> MTecknology, it's better to keep separate what comes from upstream, and what comes from packaging, so the manpage should go into the debian directory
[20:28] <MTecknology> ok
[20:28] <MTecknology> so next verion it'll move
[20:29] <MTecknology> actually... I should maybe just wait until they finish the patches I requested from them... or just make the changes myself and submit a patch..
[20:30] <fabrice_sp_> MTecknology, as you want. If you are adding a patch system, you could use source format 3.0, with quilt
[20:31] <MTecknology> fabrice_sp_: that's entirely new territory for me :P - any guide for that?
[20:32] <fabrice_sp_> http://wiki.debian.org/Projects/DebSrc3.0
[20:32] <fabrice_sp_> MTecknology, it explains you the format, and how to convert an existing package to it
[20:32] <MTecknology> thanks
[20:33] <MTecknology> wow... there's a LOT to packaging
[20:41] <bdrung> fabrice_sp_: we got an collision. ;)
[20:41] <bdrung> (bug #512648)
[20:42] <fabrice_sp_> bdrung, oooppps
[20:42] <fabrice_sp_> doble ack, then :-)
[20:42] <bdrung> tested twice.
[20:42] <bdrung> fabrice_sp_: btw, the build+ack script is nearly finished
[20:42] <fabrice_sp_> with piuparts, in my case ;-)
[20:43] <fabrice_sp_> I can send you the piuparts part also: it took me some time to have the right command line
[20:43] <fabrice_sp_> (and hacked a bit the source, to get rid of the huge generated log)
[20:44] <bdrung> fabrice_sp_: let me put it in a bzr branch
[20:44] <fabrice_sp_> fabrice_sp_, ok
[20:44] <fabrice_sp_> ?!
[20:45] <fabrice_sp_> bdrung, ^ (I'm beginning to be tired: I speak to myself :-D )
[20:45] <bdrung> haha
[20:54] <bdrung> fabrice_sp_: here it is: https://code.launchpad.net/~ubuntu-dev/+junk/ack-sync
[20:57] <fabrice_sp_> bdrung, nice!
[20:58] <bdrung> fabrice_sp_: i added my default python parameter handling snipped after i forgot one parameter ;)
[20:59] <fabrice_sp_> :-)
[21:00] <geser> bdrung: I'm looking at the code: you sure line 54 is correct? "group = package[0-3]" shouldn't the - be a :?
[21:01] <bdrung> geser: you are right - do you fix it?
[21:02] <geser> bdrung: I leave it to you (busy with other things and don't want to start an other task)
[21:03] <bdrung> fixed
[21:03] <bdrung> and pushed
[21:03] <fabrice_sp_> by the way, pbuilder build will build also -all packages in amd64? Or it requires a -A, like sbuild, to build them?
[21:04] <blueyed> it will build all, fabrice_sp_
[21:04]  * fabrice_sp_ is not using pbuilder anymore :-/
[21:04] <sebner> shadeslayer: how did you fix it?
[21:04] <fabrice_sp_> ok. thanks blueyed
[21:04] <blueyed> fabrice_sp_: took me some time to get used to -A with sbuild.. ;)
[21:04] <bdrung> fabrice_sp_: you could add an option for using sbuild (or and system environment variable)
[21:05] <fabrice_sp_> bdrung, I was thinking about that (and also add piuparts support)
[21:05] <bdrung> fabrice_sp_: that would be nice
[21:05] <geser> by default pbuilder behaves like a "i386 buildd" (uses debian/rules binary), if you want to behave it like an "amd64 buildd" (debian/rules binary-arch) you need to specify an option (-B)
[21:06] <geser> s/-B/--binary-arch/
[21:06] <fabrice_sp_> that's different from sbuild, then
[21:06] <shadeslayer> sebner: git archive HEAD | gzip > rekonq.tar.gz
[21:07] <fabrice_sp_> I still remember telling people that I was missing -all packages, when I first switched to sbuild :-D It was my fault! :-/
[21:07] <shadeslayer> sebner: also used a --prefix
[21:07] <sebner> shadeslayer: k, thx for the info
[21:07] <shadeslayer> sebner: #git is a pretty good place if you tell them youre fed up of git :P
[21:08] <shadeslayer> same for #kubuntu #ubuntu etc
[21:08] <sebner> shadeslayer: heh, I'm still happy with it
[21:09] <shadeslayer> sebner: :)
[21:09] <shadeslayer> sebner: well its just that people help half heartedly unless you use the magic words
[21:09] <shadeslayer> the magic words being im fed up of so and so not working
[21:10] <sebner> shadeslayer: heh, did you try the git community book already?
[21:10] <fabrice_sp_> bdrung, are you using windows? ack-sync is full of ^M ;-)
[21:10] <shadeslayer> sebner: yeah but its not that detailed...
[21:10] <shadeslayer> missing some stuff here and there
[21:10] <bdrung> fabrice_sp_: windows? what's that?
[21:10] <fabrice_sp_> lol
[21:10] <bdrung> fabrice_sp_: ^M?
[21:11] <fabrice_sp_> yes
[21:11] <bdrung> ^M = ?
[21:11]  * fabrice_sp_ will try to pastebin
[21:11] <fabrice_sp_> http://pastebin.ubuntu.com/363464/
[21:12] <fabrice_sp_> this is how it appears in vi
[21:13] <bdrung> fabrice_sp_: fixed
[21:14] <bdrung> fabrice_sp_: that's maybe because i grabbed this file through pastebin
[21:14] <fabrice_sp_> hmm, could be, yes
[21:19] <MTecknology> fabrice_sp_: I just made the code changes and sent the patch to the author. He's going to apply it, create a new version, then I'll resume packaging :)
[21:19] <fabrice_sp_> MTecknology, sound good :-)
[21:20] <MTecknology> fabrice_sp_: this is hard stuff, but it's fun
[21:20] <fabrice_sp_> we all began this way ;-) (in my case, it was because of dvdstyler :-) )
[22:10] <MTecknology> How can I update a Makefile to handle a man page?
[22:14] <cody-somerville> MTecknology, If you're packaging, you don't need to do that.
[22:14] <cody-somerville> MTecknology, Theres a debhelper for that.
[22:15] <cody-somerville> If you need to build the manfile from another format or something, you can just do that in your debian/rules instead of patching the Makefile.
[22:17] <MTecknology> cody-somerville: thanks
[22:22] <xteejx> bug 512890, I've been told to subscribe and assign Universe Sponsors, but that's what I did before the assignee was removed....
[22:22] <MTecknology> So- is it a big deal ifI accidentally have too many build dependencies?
[22:23] <ajmitch> xteejx: what he really meant was subscribe, not assign
[22:23] <geser> no, the build just takes a little bit longer
[22:24] <xteejx> ohhhh I see, thanks ajmitch, didn't realise :)
[22:24] <MTecknology> ok, I think I might have one extra dep, but I know it's related
[22:24] <MTecknology> now lintain
[22:24] <xteejx> Is it Ok to go ahead and fix the FTBFS errors without getting shouted at? :P
[22:24] <xteejx> Or at least try...
[22:25] <MTecknology> Any ideas what I should be doing here? It's a new package but I do plan on getting it into debian and ubuntu - http://paste.ubuntu.com/363496/
[22:26] <ajmitch> xteejx: it should be fine, any shouting should be done in a loving & caring way
[22:26] <xteejx> ajmitch: Lol ;) But cool :)
[22:26] <xteejx> MTecknology: It's a suggestion to create a debian/watch file
[22:27] <MTecknology> xteejx: the packaging guide doesn't describe that at all
[22:27] <xteejx> Its in the Debian Policy manual I think
[22:27] <MTecknology> eh - I looked at the wrong wiki page :P
[22:28] <xteejx> ;) hehe
[22:28] <porthose> https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[22:29] <xteejx>  I've given up on packaging for now... doing some "Failed to build" stuff :)
[22:30] <zooko> How do I request that Ubuntu upgrade the version of a package?
[22:30] <cody-somerville> zooko, file a bug against that package in launchpad
[22:30] <statik> hey zooko, nice to see you
[22:30] <ajmitch> zooko: it'll depend on the package, whether it was modified from debian or not
[22:30] <ajmitch> or if you want a version not in debian
[22:31] <statik> i want to use the new ubuntu distributed development tools for updating a package to a new upstream release. uscan gets me the new tarball, and i've got the lp:ubuntu/packagename branch already. do i need to do anything special to import the tarball to bzr?
[22:31] <MTecknology> porthose: if tarballs aren't published at all.. then what should I do? I could import the project to launchpad and start importing the git source and use that for release tarballs
[22:33] <zooko> Hello statik!
[22:33] <MTecknology> porthose: This is a new package too- so I'm kinda fumbling around some
[22:34] <RAOF> MTecknology: If there are no tarball releases then you create a debian/watch file with nothing but a comment explaining why you can't write a debian/watch file.
[22:35] <MTecknology> RAOF: ok, thanks
[22:35] <kjele> Hello
[22:36] <kjele> Is it possible to pack a package without autoconf?
[22:37] <MTecknology> RAOF: it's only available via git and a single tarball - no directory listing available. I could try to ask the author if they could offer that
[22:37] <RAOF> MTecknology: If they're not cutting proper releases then there's not much point.
[22:39] <MTecknology> RAOF: I meant ask them to offer releases like that, He's been happy for my help so far - maybe he'd be up for that too
[22:39] <RAOF> If he wants to offer releases then your watch file can pick them up.
[22:40] <MTecknology> RAOF: Just a directory on a web server that lists all tarballs in it would work?
[22:41] <MTecknology> I guess. that would look like this then - http://people.canonical.com/~dholbach/motu/ :P
[22:41] <MTecknology> I'm sure that he'll be up for that idea
[22:42] <MTecknology> Then maybe I can package the rest of his software :P
[22:56] <xteejx> Fixing FTBFS bugs are rather easy once you get started :)
[23:00] <MTecknology> xteejx: FTBFS?
[23:00] <MTecknology> I'm just waiting on the LP email..
[23:00] <xteejx> Failed to build from source.... i.e. autobuilder problems
[23:00] <MTecknology> oh
[23:01] <MTecknology> accepted - now waiting for build
[23:02] <MTecknology> xteejx: unless you're up for hosting on sourceforge..
[23:03] <xteejx> MTecknology: hosting what?
[23:03] <MTecknology> xteejx: wrong person - sorry
[23:03] <xteejx> lol :)
[23:05] <MTecknology> xteejx: I want to convince the author of this app to host the files so a watch file can keep track of it
[23:05] <MTecknology> actually - does anybody want to review my package for correctness once it builds?
[23:06] <xteejx> MTecknology: Well there several good reasons ... most important one being he'd have his package shared with the world, ~10 million people use Ubuntu
[23:06] <xteejx> bug 512890 - how long does it take for someone to look at my debdiff? Is there a waiting process?
[23:07] <MTecknology> xteejx: I think he'll go for it; the two options are 1) +Indexes on Apache for the directory or 2) host on something like sf.net
[23:07] <xteejx> hmm... if I had an app I wanted to give away, I'd be doing it through sourceforge
[23:08] <MTecknology> package built
[23:09] <MTecknology> xteejx: two days of learning - and this is what I have to show for it - https://edge.launchpad.net/~mtecknology/+archive/ppa
[23:10] <xteejx> MTecknology: Wow, a whole package?! What's it do?
[23:11] <geser> xteejx: small improvents for your debdiff: don't forget to update the maintainer (update-maintainer does it for you) and don't forget to close your bug in the changelog entry (lp: #xxx)
[23:11] <geser> and please also forward the patch to Debian (if you didn't already did it)
[23:11] <MTecknology> xteejx: that sounded mean :(
[23:11] <xteejx> MTecknology: Mean?? Not at all, I'm intrigued :)
[23:12] <xteejx> Is it a new package?
[23:12] <MTecknology> ya
[23:12] <xteejx> Cool :D
[23:12] <MTecknology> xteejx: In my defence, I also wrote some patches for the code and got them pushed upstream; and made a man page for it
[23:13] <xteejx> MTecknology: Bloody hell, that's really good!!! :)
[23:13] <MTecknology> thanks :)
[23:13] <xteejx> geser: I've removed the packages, I assume it's safe to edit debdiff by hand?
[23:14] <MTecknology> now I need to convince him to do the directory listing so the watch has a purpose; I also need to get this into Debian so Ubuntu will import it
[23:15] <MTecknology> ugh
[23:15] <MTecknology> Apparenlty the man page goes where it's supposed to - but the binary doesn't
[23:15] <xteejx> :(
[23:16] <MTecknology> xteejx: hurray, 'find / -name lal' came up with nothing
[23:16] <MTecknology> well - this /usr/share/doc/lal
[23:16] <geser> xteejx: if you know how to edit patches that they still work afterwards sure (else grab the source package and apply your current debdiff)
[23:16] <xteejx> geser: How do I apply a debdiff, I've only ever created one?
[23:17] <geser> apt-get source package; cd package; patch -p1 < debdiff
[23:17] <MTecknology> geser: any chance you could grab that source and tell me what I did wrong?
[23:18] <xteejx> geser: Great thanks :)
[23:19] <xteejx> Also, why do I need to update the maintainer?
[23:19] <xteejx> I mean it's a Debian sync package
[23:20] <xteejx> geser: ^
[23:21] <geser> it's not anymore when we touch it, so we need to update the maintainer and point to us
[23:22] <xteejx> ohhhh I see...any changes we make reverts it to us? That's cool
[23:24] <MTecknology> this sucks... I thought I hadit
[23:24] <MTecknology> At least the man page went where it was supposed to
[23:24] <xteejx> ^ hence the reason I tried something other than packaging :P
[23:27] <geser> MTecknology: sure, url?
[23:27] <MTecknology> geser: https://edge.launchpad.net/~mtecknology/+archive/ppa/+packages
[23:28] <xteejx> geser: bug 513014 that one should be ok
[23:31] <geser> xteejx: yes, just a very small issue: as updating the maintainer field is a common change (we must do it for every package we modify) we don't have to document it
[23:31] <xteejx> oh hehe
[23:33] <geser> and please file the bugs against the package and not ubuntu in general, it makes it easier for someone else to see if fix waiting for sponsoring (e.g. an other contributor or dev fixing FTBFS)
[23:34] <xteejx> geser: I forgot to do that :) new debdiff uploaded though :)
[23:35] <geser> MTecknology: your problem is the missing binary in the package?
[23:37] <MTecknology> geser: ya
[23:38] <MTecknology> geser: manual stuff works perfect; I'm working on adding a watch
[23:38] <geser> simple: you only build it but don't install it (below the staging directory from where the package gets constructed)
[23:39] <MTecknology> geser: I have no idea how to make it install it..
[23:39] <geser> this is usually done by "make install" but your Makefile doesn't support this (which is no problem itself)
[23:40] <geser> echo "lal usr/bin" > debian/lal.install
[23:40] <MTecknology> it's that simple?
[23:40] <geser> yes, man dh_install if you want to know more what happening
[23:41] <MTecknology> /usr/bin or usr/bin ?
[23:42] <geser> usr/bin (but doesn't really matter) as debian/$package/ gets prefixed
[23:43] <MTecknology> thanks :) - I'm making a sf project for the watch right now
[23:44] <geser> in the end it's a "cp lal debian/lal/usr/bin/" what this does
[23:47] <MTecknology> geser: do I need only the tarball in the sf project, without the debian/ in it?
[23:49] <geser> yes, the just the contents of the .orig.tar.gz
[23:53] <MTecknology> geser: I suppose the watch file can't be tested until this is uploaded to debain, huh?
[23:55] <geser> as I don't know who exactly uscan and debian/watch and sf.net work together, I can't answer this
[23:56] <MTecknology> ok, I'll just trust that it'll work correctly
[23:56] <geser> I heard that uscan can't "access" sf.net directly and needs some sort of "mirror/proxy" (don't know the details)
[23:57] <MTecknology> that's probably why it complained; I pretty much copied the exact syntax of stalonetray for the watch which is on sf.net; it complained about debian.org
[23:57] <MTecknology> I'll assume I did this part right.. :)
[23:59] <MTecknology> geser: I'm uploading the new package hopefully this one builds correctly
[23:59] <MTecknology> :D