[00:01] <geser> did you update it to -0ppa2? if not, it gets rejected
[00:11] <cyphermox> MTecknology, geser, there is a special cgi proxy thing somewhere on debian.org that translates calls to sf.net.. it was broken for a while this summer
[00:45] <MTecknology> geser: ya, I did
[00:45] <OrgulloCachanill>   Forum welcomes anybody who hates niggers and isn't a nigger.      Asian?  No Problem!  Jewish?  We have Jewish mods!  Mexican?  Bienvenido amigo!  No matter what race you are, join us if you hate niggers!
[00:46] <sebner> far too quick for an op :(
[00:46] <MTecknology> hurray spam
[00:48] <MTecknology> sebner: ya, but staff got them instead :P
[00:50] <sebner> lol
[00:50] <sebner> anyways
[00:50] <sebner> far too late already .. gn8
[00:53] <MTecknology> geser: is there any chance you could check over that package for errors?
[00:54] <MTecknology> It builds fine, installs correctly now, and lintain sees no issues - just the way I did everything..
[03:55] <MTecknology> So when I have something I want to push to Debian, what should the version number look like?
[03:56] <MTecknology> in the changelog..
[03:56] <persia> MTecknology: Is it maintained by Debian QA or someone else?
[03:57] <MTecknology> persia: I'll probably be the one maintaining the package, somebody else manages the code
[03:57] <persia> Oh, a new package.
[03:57] <persia> Generally one uses a revision number of 1 for a new package, so something like 1.2.3-1
[03:57] <MTecknology> ok, thanks :)
[03:58] <MTecknology> I didn't know if I wanted anything like ubuntu0 at all
[03:58] <persia> The reason I ask is that I believe it to be poor manners to attach changelog changes to a patch one is submitting to a Debian maintainer not oneself, except in certain special cases.
[03:58] <MTecknology> does that get attached on import from there?
[03:58] <persia> No.
[03:59] <MTecknology> I like to think I have good manners - I want to do that :P
[03:59] <MTecknology> I wonder if this is what I want for the watch... http://projects.l3ib.org/lal/files/ lal-(.*)\.tar\.gz debian debian/orig-tar.sh
[04:01] <MTecknology> :P
[04:01] <MTecknology> looks good     => remote site does not even have current version
[04:02] <MTecknology> 1.1 will get released tomorrow, it'll just be a small Makefile change
[04:03] <persia> Does the watch file work?  You can test with `uscan --report-status` and `uscan --force-download`
[04:03] <MTecknology> persia: so when a new tarball gets published and it gets scanned, what happens?
[04:03] <persia> Nothing, unless someone decides to update.
[04:04] <persia> It might show up in UEHS and DEHS reports.
[04:04] <MTecknology> where's that?
[04:05] <persia> http://qa.ubuntuwire.org/uehs/ and http://dehs.alioth.debian.org/
[04:05] <persia> (It's at times like these that search engines are handy)
[04:08] <MTecknology> so once I get this latest version packaged; I upload it to debian.mentors.net; then something happens there; then it gets sync'ed into 10.04?
[04:09] <hyperair> mentors.debian.net
[04:09] <persia> Well, you'll want to contact the debian mentors to get it uploaded, but ideally.
[04:09] <MTecknology> hyperair: ya, that one :P
[04:09] <hyperair> you upload it to mentors.debian.net, you get the RFS template and mail it to the debian-mentors mailing list, you wait for a sponsor to get back to you, and once the sopnsor has uploaded, it'll get synced.
[04:10] <MTecknology> cool :)
[04:10] <hyperair> but unlike revu, it's actually very difficult to get a sponsor for new packages in debian-mentors.
[04:10] <hyperair> you can wait for months on end
[04:11] <persia> hyperair: You clearly haven't looked at REVU recently :)
[04:11] <hyperair> persia: er. i guess not.
[04:11] <persia> I think the latency is about the same: in both cases some stuff moves very quickly, and some stuff sits there for months.
[04:11] <hyperair> persia: i haven't attempted to get anything into ubuntu via revu for a long while.
[04:12] <MTecknology> via revu means it's in ubuntu only?
[04:12] <hyperair> MTecknology: yes.
[04:12] <hyperair> MTecknology: rather, ubuntu and its derivatives.
[04:12] <ajmitch> both debian & ubuntu suffer from the problem of reviewing & sponsoring not being much fun :)
[04:12] <MTecknology> I have something I want to pckage later that will be Ubuntu specific
[04:12] <hyperair> MTecknology: submitting to debian would mean it'll get into debian and its derivatives, and since ubuntu is a debian derivative, that has a wider reach.
[04:13] <hyperair> ajmitch: but stuff i've attempted to get into ubuntu via revu entered much faster than through mentors.debian.net
[04:14] <ajmitch> hyperair: it depends on how persistent you are, and responsive with making requested changes
[04:14] <persia> hyperair: Mostly that's a function of timing.  Sometimes REVU gets lots of attention.  Sometimes mentors.  When things are especially fast is when both sets of sponsors are competing, but that doesn't happen often.
[04:14] <hyperair> ajmitch: i've been quite responsive with revu imo, but with mentors.debian.net, it's kinda hard to be responsive when you don't even get a reply to begin with.
[04:15] <persia> Well, some things on REVU haven't been reviewed in months as well.
[04:15] <MTecknology> I like to think I'm extremely responsive..
[04:15] <persia> You may just be better at advertising your stuff on REVU.
[04:15] <hyperair> perhaps.
[04:15] <MTecknology> I'm reading the intro on m.d.n
[04:16] <hyperair> codelite entered ubuntu in a few weeks.
[04:16] <hyperair> it's been many months since then
[04:16] <hyperair> and codelite is still sitting in mentors.debian.net
[04:16] <hyperair> i just gave up trying to get it in
[04:16] <cyphermox> hyperair, with an email on the ML too?
[04:16] <hyperair> the only response i got was "isn't it just like code::blocks? we don't need another editor"
[04:16] <hyperair> cyphermox: weekly mails, which is the maximum allowed frequency for RFS's
[04:17] <cyphermox> wow.
[04:17] <hyperair> it's easier to get stuff into debian if you can find a team with a DD, or otherwise find a DD who's interested.
[04:17] <MTecknology> DD?
[04:18] <hyperair> debian developer
[04:18] <MTecknology> oh
[04:18] <hyperair> people with upload privileges
[04:18] <MTecknology> I want to be able to call myself an Ubuntu developer someday
[04:18] <RAOF> Or there's an interested team; the cli-{apps,libs} team is responsive.
[04:18] <persia> The same is true with Ubuntu.  Packages of interest to Ubuntu Developers tend to pass through REVU faster.
[04:18] <hyperair> MTecknology: so would i. =)
[04:18] <cyphermox> two fairly specialized packages I've uploaded through mentors finally, got almost immediate attention, compared to revu with few comments after weeks.
[04:19] <cyphermox> getting the input from the two sides was very interesting and useful though
[04:19] <hyperair> i guess the size of the package also matters. codelite is a behemoth.
[04:19] <cyphermox> probably
[04:20] <persia> Definitely.  It's much easier to review small stuff.
[04:20] <hyperair> on top of that, upstream insists on including the windows specific files (especially the binaries) in the tarballs, so i have to get those repacked out.
[04:20] <MTecknology> the actual code in this is about 300 lines
[04:20] <cyphermox> persia, even small packages can get complicated :)
[04:20] <hyperair> that's tiny.
[04:20] <MTecknology> ya
[04:20] <MTecknology> but dang this thing is awesome
[04:21] <MTecknology> I figured it's the perfect point to learn
[04:21] <persia> cyphermox: Yes, but they tend to take less time to download, less time to build, and less time to read.
[04:21] <cyphermox> yup
[04:21] <MTecknology> I learned .. a lot .. in the last two days
[04:23] <MTecknology> Intro page - "Besides from not being able to upload the package directly into Debian you are treated as a full member of the community."
[04:23] <MTecknology> heh.. most debian folke I know aren't friendly enough to call anyone but the few l33t part of their community
[04:25] <persia> Then you're not looking in the right places.  Several Debian folk have previously contributed to this very conversation in the past hour.
[04:25] <cyphermox> MTecknology, I think when it's apparent that you do a good job or that you are eager to learn, you're taken seriously
[04:25] <MTecknology> persia: I meant when I popped into #debian
[04:26] <cyphermox> E.g. my first emails with my regular sponsor seemed a little cold... which was really just a perceived thing on my end it seems, because he's been extremely nice and useful.
[04:27] <MTecknology> I only have experience asking for support in the main channel
[04:28] <MTecknology> persia: you're probably right..
[04:38] <MTecknology> Thanks for all the help everyone - I appreciate it :)
[04:38] <MTecknology> persia: are debian channels mostly on freenode or oftc?
[04:39] <persia> OFTC
[04:39] <persia> Although I find that Debian is largely mail-driven, rather than IRC-drvien.
[04:39] <MTecknology> oh
[04:39] <MTecknology> that could also be part of my experience..
[07:00] <dholbach> good morning
[07:00] <Omar87> dholbach: good morning. :-)
[07:00] <dholbach> hi Omar87 :)
[07:05] <stochastic> On an upgrade request bug what's the best way to attach a patch?  In the form of a debdiff from the previous version, or as a .dsc file for the new package?
[07:07] <randomaction> stochastic: attach diff.gz and live a link to source tarball
[07:07] <stochastic> okay, thanks
[09:14] <hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? - There are no lintian warnings or other errors. http://revu.ubuntuwire.com/p/qt-shutdown-p
[10:15] <abogani> Hi All, Little questions: if the source of a don't-yet-packaged software don't contains automated build procedures (autotools, Makefile, ant etc etc) what I should do for packaging it in the right way? Thanks in advance!
[10:17] <mok0> abogani: it really doesn't matter how you build the software.
[10:18] <mok0> abogani: just compile it and install it in the debian/tmp tree
[10:18] <abogani> mok0: Can I insert gcc command into debian/rules?
[10:18] <abogani> directly?
[10:18] <mok0> abogani: sure
[10:19] <mok0> abogani: although it might be more maintainable to write a Makefile
[10:32] <abogani> mok0: Ok. Thanks a lot! :-)
[10:32] <mok0> np
[10:47] <xteejx> How do I apply a debdiff to a downloaded source?
[10:48] <xteejx> I've made a debdiff for emacs-chess FTBFS, but I removed the source and the things I changed, can I reapply the debdiff to redo what I deleted?
[10:49] <mok0> xteejx: yes, that's how the sponsor would do it
[10:49] <randomaction> xteejx: typically you go to source directory and "patch -p1 </PATH/TO/DEBDIFF"
[10:49] <xteejx> No...how do I do it, I need to change a couple of other things
[10:50] <xteejx> randomaction: Thanks. Will that make the changes I made in debian/ folder appear again, or do I need to unpack or anything?
[10:50] <randomaction> to go to source directory, you need to unpack the package
[10:51] <xteejx> apt-get source already did that
[10:51] <xteejx> and I have my debdiff
[10:51] <randomaction> good for you :)
[10:51] <xteejx> So just the patch -p1 and that's it? That's handy :)
[10:51] <mok0> yep
[10:52] <randomaction> that's why people ask for debdiffs
[10:52] <xteejx> I see now, it saves a lot of messing about :)
[10:52] <mok0> old package + debdiff = new package
[10:52] <xteejx> I suppose that's also the reason why we aren't supposed to mess around with the actual source code, only make patches, right?
[10:53] <randomaction> no, reason for this is that you have a handy patches directory an can at any time review any changes you have made
[10:54] <mok0> xteejx: exactly
[10:54] <xteejx> I see, it all makes a lot more sense now.
[10:54] <xteejx> Is the patch -p1 command meant to take any more than a few seconds?
[10:54] <mok0> there's a bunch of tools that can analyze diffs as well. lsdiff is one of my favourites
[10:54] <randomaction> xteejx: did you miss the "<" symbol?
[10:54] <mok0> xteejx: you need to read from stdin
[10:55] <xteejx> oops :P
[10:55] <mok0> Unless you enjoy typing diffs :-)
[10:55] <xteejx> read form stdin?
[10:55] <mok0> xteejx: yes, with a redirect (<)
[10:55] <xteejx> *from
[10:56] <mok0> patch < file
[10:56] <xteejx> I don't know what the techincal thing is for that, but yeah I missed the < ;)
[10:56] <xteejx> I'll just call it greater than :P
[10:56] <randomaction> xteejx: http://en.wikipedia.org/wiki/Redirection_%28computing%29
[10:56] <mok0> xteejx: that a different context thoug
[10:57] <mok0> h
[10:57] <xteejx> I see
[10:57] <xteejx> So it means "do this to that"
[11:00] <mok0> xteejx: huh? It means "instead of reading from stdin, read from file"
[11:00] <xteejx> Ok, I'm consued in the space of 2 minutes then, don't worry I'll pick it up eventually ;)
[11:01] <mok0> xteejx: good
[11:01] <mok0> because redirects and pipes are among the most amazing useful features ever invented
[11:02] <hyperair> mok0: hear hear!
[11:02] <mok0> hyperair!
[11:02] <hyperair> mok0!
[11:02] <mok0> :)
[11:03] <hyperair> =P
[11:05] <mok0>  cat  /etc/dictionaries-common/words |rev|sort|rev|less
[11:06] <hyperair> mok0: why reverse it twice?
[11:06] <mok0> hyperair: to regenerate the words... it's a rhyme dictionary
[11:06] <hyperair> ah
[11:07] <hyperair> i see
[11:07] <hyperair> that's interesting.
[11:07] <mok0> cool huh :-)
[11:07] <mok0> Ooops gotta go, see you later
[11:07] <hyperair> yeah cool
[11:55] <angelabad> Hi, can anyone review pidgin-embeddedvideo? Embedded video is a GTK+ plugin for pidgin. http://revu.ubuntuwire.com/p/pidgin-embeddedvideo
[12:53] <ScottL_> persia:  last night I ran "lintian -iIv" and "lintian --pedantic" against my zynjacku.source.changes file and only received "bad distritibtuion type"
[12:54] <ScottL_> persia: which was expected as this is for lucid - thank you again for your help
[13:14] <xteejx> https://launchpad.net/ubuntu/+source/zshdb/0.03+git20090920-1/+build/1341562 shows failed to build on i386 but I don't see any obvious errors in the build log...am I missing something?
[13:15] <geser> "19 of 19 tests failed" but I can't tell you why
[13:16] <xteejx> oh i see that
[13:16] <geser> see also Debian bug #560665
[13:17] <xteejx> Hmm....
[13:33] <xteejx> In the rules/debian it says $(MAKE) - my question is, where is $(MAKE) defined, or does it just go through the Makefile in that directory?
[13:34] <xteejx> debian/rules even
[13:34] <geser> $(MAKE) gets defined by make itself
[13:34] <xteejx> so it's just the command 'make' alone
[13:35] <geser> yes
[13:35] <xteejx> Also, if there is a Makefile.am and Makefile.in which is the one that is read? Am I right in thinking the .am is used my automake to make Makefile.in ?
[13:35] <xteejx> cool
[13:36] <geser> yes, and configure usually turns Makefile.in into Makefile which gets used in the end
[13:36] <xteejx> I see
[13:37] <xteejx> i don't see any striaght Makefile... I suppose configure is called somewhere in the rules?
[13:37] <xteejx> duh! I can see it, why am I asking : ./configure --prefix=/usr --with-zsh=/bin/zsh --disable-maintainer-mode --with-lispdir=/usr/share/emacs/site-lisp/zshdb
[13:38] <xteejx> thx geser :)
[13:38] <geser> re $(MAKE) see http://www.gnu.org/software/make/manual/make.html#MAKE-Variable
[13:40] <xteejx> I get it... so $(MAKE) just calls make to make... lol instead of typing /usr/bin/make which could be wrong on other systems
[13:42] <xteejx> I think the error is just after : /usr/bin/make  check-TESTS
[13:43] <xteejx> How do I search the directory for files containing "TESTS"?
[13:43] <xteejx> grep something
[14:03] <kklimonda> how can I get bzr branch for debian package uploaded to sid?
[14:04] <geser> lp:debian/sid/package
[14:05] <kklimonda> how often is it updated?
[14:06] <geser> I don't know and it also depends if the package import into the branch works (there are several packages where this fails)
[14:07] <kklimonda> or a more direct question - why is the last transmission version 1.77 when 1.82 was uploaded few days ago? can I check it somewhere?
[14:07] <kklimonda> or maybe it's a broken upload.. hmm..
[14:08] <geser> http://package-import.ubuntu.com/transmission: AssertionError: Can't handle non gz tarballs yet
[14:08] <kklimonda> ach, thanks
[14:10] <kklimonda> it doesn't make any sense but I have a new link to play with :)
[14:11] <kklimonda> ach, orig is in bz2
[14:12] <jpds> kklimonda: Not according to https://edge.launchpad.net/ubuntu/+source/transmission/1.80~b5-0ubuntu1
[14:13] <geser> jpds: but according to http://ftp.debian.org/debian/pool/main/t/transmission/transmission_1.82-1.dsc
[14:13] <kklimonda> jpds, I guess debian maintainer have changed it recently to not repack original .tar.bz2 to .tar.gz
[14:14] <sebner> debsrc3.0 ftw!
[14:14] <ari-tczew> I'm learning to use bzr, I got a problem :-/
[14:14] <kklimonda> I was hoping to play with the new bzr merges but it looks like I just should do that in the old fashion way :/
[14:14] <geser> ari-tczew: what problem?
[14:15] <geser> kklimonda: or pick an other package to merge :)
[14:15] <ari-tczew> I used: bzr launchpad-login ari-tczew then I've asked about key, I give YES, then OK. Now I put: bzr branch lp:~ari-tczew/+junk/gambas2 and it fails
[14:16] <geser> error?
[14:16] <ari-tczew> bzr branch lp:~ari-tczew/+junk/gambas2
[14:16] <ari-tczew> Permission denied (publickey).
[14:16] <ari-tczew> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[14:18] <geser> you use the same SSH key as listed on your LP page?
[14:19] <ari-tczew> I don't know
[14:19] <ari-tczew> if no, how can I sync key with LP?
[14:20] <geser> just add it like you did with your first SSH key
[14:21] <geser> use the link besides "SSH keys" on your LP page
[14:23] <ari-tczew> I don't understand
[14:24] <ari-tczew> _now_ what I have to change?
[14:24] <ari-tczew> any thing on my pc? or any thing on LP?
[14:24] <ari-tczew> fu*king keys...
[14:25] <geser> have you an SSH key on the PC you try to push from?
[14:26] <ari-tczew> yes, I created ssh key on my PC and succefly imported to LP
[14:26] <geser> and it doesn't work? -> try #launchpad then
[14:30] <ari-tczew> I lost inclination, another time
[14:42] <kklimonda> hmm, could anyone check if mozilla-noscript from repository actually works with seamonkey in karmic?
[14:50] <xteejx> Hey guys, I have 3 files, the orig.tar.gz, the -1ubuntu1.diff.gz and the .dsc... how do I extract the source from that, i.e. not the original, the Ubuntu-edited one, as it's in a PPA without any debdiff ??
[14:51] <sistpoty|work> xteejx: dpkg-source -x *dsc
[14:52] <xteejx> Cool thanks :)
[14:55] <xteejx> Also, what is the correct Ubuntu version if the PPA version is 0.6.4-1~name1? Is it 0.6.4-1-0ubuntu1?
[14:57] <ari-tczew> no
[14:57] <ari-tczew> ppa is unofficial, personal repositories
[14:58] <xteejx> Oh... :)
[14:58] <hyperair> anyone from motu-release here? i'd like to request for clearance to get the new banshee into lucid during the featurefreeze (banshee upstream has now committed to a schedule and will release 1.6.0 on march 31st)
[14:59] <sistpoty|work> hyperair: /me looks
[14:59] <hyperair> sistpoty|work: http://banshee-project.org/about/calendar/
[15:00] <hyperair> xteejx: you generally add stuff to the version number that your package is based on
[15:01] <xteejx> hyperair: Well I was thinking about repacking some PPA stuff into debian policy standards, don't know if that's possible
[15:01] <hyperair> xteejx: and don't add another "-", it's usage is strictly restricted to separating upstream from debian revisions
[15:01] <xteejx> ohh i see
[15:01] <hyperair> s/it's/its/
[15:01] <sistpoty|work> hyperair: hm, that's (only) two weeks away from final freeze...
[15:01] <sistpoty|work> hyperair: do you plan to track the release closely?
[15:02] <hyperair> sistpoty|work: yes
[15:02]  * sistpoty|work shrugs
[15:02] <hyperair> sistpoty|work: as usual, banshee will get a bucketload of bugfixes per release -- generally an amount large enough that it's not practical to backport all
[15:03] <hyperair> sistpoty|work: not to mention that the current banshee in ubuntu, 1.5.1 is labelled as "1.6.0 beta 2"
[15:03] <sistpoty|work> hyperair: I think I'm generally in favor of it, but can you please also mail to ubuntu-motu@luc to reach other motu-release members as well?
[15:03] <hyperair> sistpoty|work: okay, will do. thanks.
[15:04] <sistpoty|work> oops, keyboard shortcut accident :)
[15:04] <sistpoty|work> thanks hyperair
[15:04] <hyperair> =)
[15:16] <xteejx> Are there any guides on packaging python games for Ubuntu?
[15:18] <randomaction> xteejx: today will be a UDW session on python application packaging
[15:19] <xteejx> randomaction: Oh cool :) Is it on lernid?
[15:19] <strycore> Hi
[15:20] <xteejx> Hi
[15:20] <randomaction> xteejx: don't know, check 20:00 UTC
[15:20] <xteejx> yeah it's at 8PM. I'll try to be there, thanks randomaction :)
[15:21] <strycore> I'm filling a bug against inkscape because it suggests ttf-bitstream-vera and this package was removed since Karmic , I'd like to find out why this package was removed
[15:21] <strycore> it's still in debian
[15:22] <randomaction> strycore: check https://launchpad.net/ubuntu/+source/ttf-bitstream-vera/+changelog
[15:22] <acicula> where is the python packaging demo, in ubuntu-classroom?
[15:22] <strycore> ok thanks
[15:24] <strycore> that was useful , I'll replace the suggestion by ttf-dejavu instead of removing it
[15:24] <xteejx> What happens with the copyright/licensing if the website states it is GPL licensed, but there are no obvious authors and no provided license files in the source? I mean, how is the debian/copyright written in that case?
[15:26] <randomaction> acicula: yes
[15:27] <strycore> debian/control: Replaced ttf-bitstream-vera suggestion with ttf-dejavu
[15:27] <strycore> is that ok for a changelog entry ?
[15:27] <acicula> randomaction: thnx
[15:31] <bddebian> Heya gang
[15:32] <sistpoty|work> hi bddebian
[15:33] <directhe`> it's the ever-sexy bddebian!
[15:33] <bddebian> Heh, heya sistpoty|work, directhe`
[15:36] <randomaction> xteejx: you should beat upstream with a stick and tell them to include AUTHORS and COPYING files in the source
[15:36] <xteejx> hmmm .... not a bad idea heheh
[15:36] <xteejx> Hi bdebian :)
[15:44] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starting in #ubuntu-classroom (on irc.freenode.net) in 16 minutes
[16:41] <randomaction> jdong: ping, looking for an SRU ack for bug 424249
[16:44] <jdong> randomaction: you're ACKed :)
[16:45] <randomaction> jdong: thanks, uploading then
[17:24] <zooko> statik: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567145
[17:54] <statik> zooko, thanks!
[18:07] <jariq> How often are advocated packages from revu processed by archive admin ?
[18:09] <geser> if a package on revu gets two "advocated" it should get uploaded by the 2nd dev advocating it to the archive where the archive admin process it (review it from the NEW queue)
[18:10] <jariq> geser: is there any way I can check if it was uploaded ?
[18:13] <randomaction> jariq: https://launchpad.net/ubuntu/lucid/+queue
[18:17] <jariq> I cannot find package ipwatchd in queue at https://launchpad.net/ubuntu/lucid/+queue Does it mean it was not uploaded yet ?
[18:18] <persia> jariq: Better to check https://launchpad.net/ubuntu/+source/ipwatchd if you're looking for a specific package.
[18:19] <persia> jariq: You might want to check with iulian to see if it was uploaded, or if it waits on the requested minor modifications.
[18:20] <jariq> persia: thx
[21:36] <xteejx> Hey guys
[21:37] <RAOF> Good morning.
[21:37] <xteejx> A source is trying to install to /usr/local/bin/ I've tried adding DESTDIR=$(CURDIR)/debian just above the %: of my rules file (template from rules.tiny) what am I doing wrong?
[21:37] <xteejx> Good evening RAOF ;)
[21:40] <RAOF> You need to work out what part of the upstream buildsystem you need to fix - is there a Makefile that you call to install?  If you pass that Makefile DESTDIR=foo, does it install into foo?
[21:40] <xteejx> rules http://paste.ubuntu.com/364139/ Makefile http://paste.ubuntu.com/364138/  .... I *think* it may be that I need to add --PREFIX=/usr/ or something...
[21:41] <xteejx> and no, it doesn't
[21:41] <xteejx> I'm very new to this as you probably know :)
[21:41] <RAOF> Yeah :)
[21:41] <RAOF> Ok, so what you want to do is to override their PREFIX variable.
[21:42] <xteejx> to just /usr/ ?
[21:42] <RAOF> You can do that by passing PREFIX=/usr to the make call.
[21:42] <RAOF> Because you're using dh7 which is all kinds of awesome, you can do this by adding a override_dh_autobuild: target.  Like so:
[21:43] <xteejx> I'm not sure how to do that :( Is it something like dh_install --PREFIX=/usr/
[21:43] <RAOF> http://paste.ubuntu.com/364141/
[21:44] <xteejx> So I don't need that DESTDIR bit then?
[21:44] <RAOF> Sorry: that should be override_dh_auto_build and dh_auto_build.
[21:46] <xteejx> Is there any space between the -- and PREFIX=/usr i.e. -- PREFIX or --PREFIX?
[21:46] <RAOF> xteejx: Right.  That makefile doesn't use a DESTDIR variable, so whatever you set it to it won't make any difference.
[21:47] <RAOF> Yes, there is a space - the “--” tells dh_auto_build that we've finished giving options to dh_auto_build, and the rest of the command line should be passed as arguments to the makefile.
[21:47] <xteejx> Ohhh I see :)
[21:47] <xteejx> It acts as a kind of separator
[21:48] <RAOF> So, that's telling dh_auto_build to pass PREFIX=/usr (acually, we want PREFIX=$(CURDIR)/debian/tmp).
[21:48] <RAOF> Exactly.  It's a separator to tell dh_auto_build that we've finished passing arguments to *it*.
[21:48] <xteejx> I see :)
[21:49] <xteejx> Does it matter that it wants to do it directly to /usr/bin or /usr/share  or should it be building in a temporary directory?
[21:49] <xteejx> Its not building with debuild -us -uc
[21:50] <geser> be careful with setting PREFIX to something other than /usr/ for this package
[21:51] <geser> as CFLAGS include a define that uses PREFIX (via SHAREDIR) it might get included into the binary (needs checking) so the final binary looks for its files in the wrong place
[21:51] <RAOF> If PREFIX gets encoded into any part of the binaries, then yeah.   That's certanily something to look for.
[21:51] <xteejx> Well, it's not building because it wants root access, I guess I want to do it in a temporary directory and then copy it to /usr/whatever at the end
[21:52] <RAOF> It looks like you'll need to patch that makefile, actually.
[21:52] <xteejx> I did think I may need to rewrite it :(
[21:53] <RAOF> No, not rewrite it.
[21:53] <RAOF> It'll be pretty easy.
[21:53] <xteejx> It installs fine btw
[21:53] <xteejx> I meant rewrite it in a patch :)
[21:54] <xteejx> Well I'm guessing the two things I would need to do would be fix that PREFIX bit and the install: section to copy it to root / when built - correct me if I'm wrong
[21:54] <RAOF> http://paste.ubuntu.com/364148/ would make “make install” it respect DESTDIR.
[21:56] <xteejx> The install: section? I see
[21:56] <RAOF> xteejx: You need to ensure that the code has the right DATADIR - somewhere in the code it will (presumably) be referencing that define, so that will need to be set to where it'll end up on the user's system.
[21:57] <RAOF> You also need to, during the build process, install the stuff into a subdir of debian/
[21:58] <xteejx> I'm confused... this change allows the rules file to make the Makefile install to *current directory*/debian right?
[21:59] <geser> yes
[21:59] <RAOF> Yes.  With that Makefile, you'd pass “dh_auto_install -- PREFIX=/usr DESTDIR=$(CURDIR)/debian/tmp”.
[21:59] <xteejx> I thought I couldn't change the source files? Or is that the idea of the patch?
[22:00] <RAOF> That's the idea of the patch.
[22:00] <xteejx> cool
[22:00] <RAOF> We quite often need to touch the source; we use patches to do that so that (among other reasons) it's obvious what's from upstream and what changes we've made.
[22:00] <xteejx> What happens then after it's built? Will it copy itself to / to install itself?
[22:01] <RAOF> I think you'll need to clarify what you mean by “it” in that sentence.
[22:04] <RAOF> You want upstream's build system to install to debian/$SOMEDIRECTORY (where $SOMEDIRECTORY can quite happily be tmp), while at the same time knowing that it will end up in /usr.
[22:05] <xteejx> the result of the install: section ... I assume this builds the executables to run to play the game, so .... actually hang on.... I need a bigger patch don't I because game executables get installed in /usr/games and the media in /usr/share/games/foo/ right?
[22:05] <RAOF> Then in the process of building the binary deb those files will be copied into the deb; when the deb is unpacked, they all end up in the dpkg root prefix (which is only ever /, really; it passing other roots to dpkg doesn't really work)
[22:05] <MTecknology> I thought I had this working perfect - but now it's not.. any ideas why I'm getting this error? http://paste.ubuntu.com/364155/
[22:05] <xteejx> RAOF: Ohhhhhhhhhhhhhhhhhhhhh I see now!!
[22:06] <xteejx> RAOF: Because of gdebi or synaptic or whatever that installs it as root, it'll go in / ahhhhhh :)
[22:07] <RAOF> MTecknology: Your upstream's “make install” is trying to install the man page in /usr/local; that isn't going to work.
[22:07] <xteejx> Didn't realise there was a man page
[22:07] <MTecknology> RAOF: oh... what should I do?
[22:08] <xteejx> oops
[22:08] <RAOF> MTecknology: That'll depend on your upsream's build system.  Scrollback where xteejx & I are discussing almost exactly this problem might be helpful :)
[22:08] <xteejx> MTecknology: Hey again :)
[22:09] <MTecknology> xteejx: hi
[22:09] <xteejx> More problems?
[22:10] <geser> MTecknology: packages get installed into a staging dir (debian/packagename) from where the deb gets build. And dpkg installs them later relative to / so the paths are correct after installation
[22:11] <geser> this also means you can't (and shouldn't) install outside the package directory (you want to install the file into the package and not into the host system (buildd))
[22:11] <MTecknology> This is the Makefile - http://paste.ubuntu.com/364158/
[22:11] <RAOF> :)
[22:12] <MTecknology> RAOF: exact same thing?
[22:12] <xteejx> RAOF: If I edit the Makefile to how I want it (as a draft example) can I paste it to have a look at please?
[22:13] <geser> first make install respect $(DESTDIR) and make the installation prefix configurable (packages shouldn't install in /usr/local, that's directory is reserved for the local admin)
[22:13] <RAOF> xteejx: Certainly.
[22:13] <xteejx> Thanks guys
[22:13] <RAOF> xteejx: Where by “paste”, you mean “pastebin” :)
[22:13] <xteejx> Of course ;)
[22:14] <MTecknology> geser: so I need to correct the Makefile install section?
[22:14] <geser> yes
[22:14] <MTecknology> sounds like fun
[22:15] <MTecknology> Is there any idiots guide to make files?
[22:17] <RAOF> The GNU documentation is quite readable.
[22:18] <RAOF> http://www.gnu.org/software/make/manual/make.html
[22:19] <xteejx> Think I got it
[22:20] <xteejx> rules: http://paste.ubuntu.com/364164/ Makefile (to be patched like this): http://paste.ubuntu.com/364165/
[22:22] <xteejx> actually I think it should change to SHAREDIR=$(PREFIX)/share/doc/XorCurses
[22:22] <xteejx> as well
[22:23] <geser> what's inside this dir? if it needed during runtime it shouldn't be inside /usr/share/doc
[22:24] <xteejx> the maps for the game and documentation, but I thought docs had to be split
[22:24] <xteejx> SHAREDIR=$(PREFIX)share/XorCurses/  but MAPDIR=$(SHAREDIR)maps   PREFIX=/usr/
[22:25] <xteejx> but then again... under install: install -t $(SHAREDIR) help*.txt
[22:26] <geser> are the help files needed during the game? e.g. for an in-game help system
[22:26] <xteejx> I'm not sure I'll check
[22:27] <xteejx> No they're not
[22:29] <geser> then either patch the Makefile to support the installation of the documentation to an other directory or don't install them with the Makefile but use dh_installdocs for it
[22:29] <xteejx> I think I got it :)
[22:29] <geser> "Packages must not require the existence of any files in /usr/share/doc/ in order to function" (from Debian Policy)
[22:30] <geser> (the admin is allowed to removed /usr/share/doc)
[22:30] <geser> so you can't install the map files there
[22:30] <xteejx> geser: So any txt files that were called within the game would need to be with the game itself?
[22:30] <xteejx> the maps go in /usr/share/xorcurses/maps/
[22:31] <geser> yes, those help files should go to /usr/share/package/
[22:31] <geser> http://www.debian.org/doc/debian-policy/ch-docs.html#s12.3
[22:32] <xteejx> Ok I think I got it now :) How do I make a patch to patch the Makefile?
[22:33] <geser> like any other patch, the Makefile is not special
[22:33] <xteejx> I don't know how to do that
[22:33] <geser> do you use a patch system?
[22:33] <MTecknology> RAOF_: thanks for thaat link
[22:34] <xteejx> I haven't told control to use one, no.
[22:34] <geser> do you want to use a patch system?
[22:34] <xteejx> If it makes it easier to fix the Makefile, yes
[22:35] <geser> the "easiest" way is to use no patch system and simply edit the files (all changes will appear in the .diff.gz)
[22:35] <geser> the downside is that with many changes you don't know anymore what changes belong together
[22:36] <MTecknology> xteejx: In my case I can make about any patch I want and the maintainer will apply it :)
[22:36] <xteejx> Ok I understand, I'd rather go with a patch system then
[22:36] <xteejx> :)
[22:36] <MTecknology> time to get my hair cut :)
[22:36] <randomaction> best patch system is debsrc3 :)
[22:36] <xteejx> What's the easiest one for a beginner?
[22:37] <xteejx> I only need to patch 1 file, I've seen one with a 00 list thing that looked ok
[22:43] <angelabad> Hi, can anyone review pidgin-embeddedvideo? Embedded video is a GTK+ plugin for pidgin. http://revu.ubuntuwire.com/p/pidgin-embeddedvideo
[22:48] <micahg> xteejx: quilt is pretty easy
[22:48] <xteejx> I'll look into it thanks micahg :)
[22:50] <xteejx> I'm now getting this error: "install: cannot create regular file `/home/teej/build/xorcurses-0.1.2/debian/xorcurses/usr/bin/games': No such file or directory"
[22:51] <xteejx> Can I tell the Makefile to mkdir $CURRENT/debian/xorcurses/usr/bin/games ?
[22:55]  * ajmitch was about to answer that question, too...
[23:08] <Nahsei> hei guys
[23:09] <Nahsei> I'm having some problems here
[23:11] <Nahsei> (nobody says anything... I will assume someone is waiting for me to say something more...)
[23:11] <Nahsei> I've tried to follow this recipe   https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[23:12] <Nahsei> I was able to create the diff... but then when i tried to patch a new source code i had this error:
[23:13] <Nahsei> Hunk #1 FAILED at 2.
[23:13] <Nahsei> 1 out of 1 hunk FAILED -- saving rejects to file debian/control.rej
[23:13] <Nahsei> patching file debian/changelog
[23:13] <Nahsei> Hunk #1 FAILED at 1.
[23:13] <Nahsei> 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
[23:13] <Nahsei> can someone help me please?
[23:18] <geser> that's because the context for the patch changed, so patch can't apply it anymore
[23:19] <geser> you need to apply this changes by hand (look at the .rej files what couldn't be applied)
[23:20] <Nahsei> what do you mean by context? what changed, besides the working directory?
[23:22] <geser> the constant lines around the changed ones for a chunk of the patch
[23:22] <geser> patch uses 3 lines at the beginning and 3 lines at the end to determine the place where to do the changes
[23:23] <geser> if those lines changes between the versions, patch won't find where the patch should get applied
[23:24] <Nahsei> hmmm.... I see
[23:25] <Nahsei> so... what is the solution for this?
[23:26] <geser> apply the changes manually (you are smarter than patch :) so you figure the correct place for the changes)
[23:27] <Nahsei> yes... of course... but then there wouldn't be a meaning for doing patches right?... I would like to do it automaticaly
[23:29] <geser> if the files you try to patch don't change between new version (or in parts you don't touch) then you can use a patch for several versions
[23:30] <Nahsei> ok
[23:32] <Nahsei> from the begining..... I tried to patch and I got that error... what should I do?
[23:34] <geser> open debian/changelog, look into changelog.rej what couldn't get applied (probably the new changelog entry as the version who got patched isn't the topmost one anymore) and apply the changes (put the Ubuntu changelog entry into the correct position)
[23:36] <Nahsei> ok... i'll try that. thanks
[23:40] <Nahsei> well ... in the top of changelog there is a version 2-3   and in the bottom of changelog.rej the version is 2-2... maybe that's why
[23:41] <Nahsei> patch could not see the correct line, saying that the version was 2-2 ... it saw 2-3 and rejected the modification
[23:41] <Nahsei> is this correct?
[23:45] <geser> yes
[23:46] <Nahsei> ok :) now i understand thanks
[23:47] <Nahsei> but then the tutorial is not up to date... or was made this way, on purpose, for people to understand better what is behind patching...
[23:48] <Nahsei> anyway... I know now.. that's what matters
[23:48] <Nahsei> :)