[02:43] <tbrock> hey guys
[02:50] <tbrock> was wondering if i could get a mentor
[02:54] <tbrock> want to get involved with ubuntu
[02:59] <tbrock> anyone around?
[03:18] <LaserJock> tbrock: have you read https://wiki.ubuntu.com/MOTU/GettingStarted ?
[03:21] <tbrock> hey sorry i cleared the screen
[03:21] <tbrock> would you be able to paste that again?
[03:22] <tbrock> i believe I've gone through that site before but i wanted to make sure so I don't annoy you guys and know what i need to do
[03:24] <jmarsden> tbrock: https://wiki.ubuntu.com/MOTU/GettingStarted and https://wiki.ubuntu.com/PackagingGuide are good places to start with
[03:26] <tbrock> thanks
[03:26] <tbrock> ok and after i read them
[03:26] <tbrock> then where should i go from there
[03:27] <LaserJock> tbrock: you could start thinking of something you'd like to do, some area you're interested in
[03:27] <jmarsden> Well, that depends what you decide you want to do?  Triage: https://wiki.ubuntu.com/BugSquad/GettingInvolved
[03:28] <tbrock> cool thanks guys
[03:28] <tbrock> and if i see something i'd like to help with i should come back and ask you guys
[03:28] <jmarsden> Or just dive in :)
[03:29] <tbrock> i'd love too, and i have some experience developing, but never something open source, i may need some hand holding lol
[03:29] <jmarsden> That's when you come back here and ask for a hand to hold :)
[03:38] <tbrock> hahah
[03:38] <tbrock> thanks!
[03:44] <terli> I understand someone in this room is responsible for trying to package parallels workstation for linux
[03:52] <tbrock> not me, thats for sure
[06:56] <AnAnt> Hello, can someone review: http://revu.ubuntuwire.com/details.py?package=ubuntume-themes
[09:08] <AnAnt> DktrKranz: hello, thanks for reviewing thwab
[09:08] <DktrKranz> AnAnt, you're welcome :)
[09:09] <AnAnt> DktrKranz: regarding debian/pypython file, I duno what Python versions are supported
[09:09] <DktrKranz> AnAnt, if you're unsure, you could put "2.4-"
[09:09] <DktrKranz> without " 's
[09:10] <AnAnt> DktrKranz: ok, thanks
[09:23] <AnAnt> Hello, can someone review: http://revu.ubuntuwire.com/details.py?package=ubuntume-themes
[10:35] <AnAnt> bddebian2: hello
[12:08] <jpds> Mez: Can you please renew my backporters membership? Cheers. :)
[15:05] <Laney> DaD DeaD?
[15:06] <AdamDH> hi all, I am in the process of making some ubuntu packages for a cross compiler based on GNU binutils, and gcc, I need some advice with version numbers for it
[15:06] <iulian> Laney: Yeah. It's really dead.
[15:07] <AdamDH> the project gets the offical GNU binuntils source and applys a patch to make it work with MSP430 microcontrollers
[15:07] <AdamDH> do I use the binutils version or create my own based on the CVS snapshot the patch is made from?
[15:08] <AdamDH> at the moment I am using msp430-binutils-cvs-0.0.20081227
[15:13] <delicowa> i wanna be a part of the ubuntu development team how do i start
[15:13] <jpds> delicowa: The links in the /topic are a good place to start.
[15:28] <AdamDH> can any one here help me with the correct way to version packages that use an upstream package put apply a CVS patch to add additional features?
[15:28] <AdamDH> would you use the upstream version and append -1 etc?
[15:29] <Laney> AdamDH: patchset-x-binutils-y?
[15:29] <Laney> or binutils-y+patchsetx
[15:31] <AdamDH> Laney is a new package I am taking to package but based on upstream binutils 2.18
[15:31] <AdamDH> with a patch applied to create MSP430 support
[15:33] <Laney> AdamDH: Can't you get it into binutils upstream?
[15:33] <Laney> code duplication is usually a bad thing
[15:33] <AdamDH> not yet, its still considered unstable, there is a binutils with support but not support for all the MSP processor types out there
[15:34] <AdamDH> everything is in a CVS resp at the moment, the packages will be unoffical
[15:34] <AdamDH> i have to do the same for gcc
[15:34] <Laney> Is it parallel-installable with normal binutils?
[15:34] <AdamDH> yes
[15:35] <Laney> then binutils-x-patchset-y or patchset-x-binutils-y is probably ok
[15:35] <AdamDH> you do ./configure --target=msp430 so you end up with msp430-ld etc
[15:36] <AdamDH> so I create my package using 2.18 as version, and then append a -1 etc on the end of that for each CVS update of the patch?
[15:37] <Laney> .s might be better actually, we use - in debian revisions
[15:37] <AdamDH> i was doing msp430-binutils (cvs-0.0.20081227-1) in the debain files
[15:38] <AdamDH> but I think that's wrong
[15:38] <AdamDH> and I was going to increment -1 with the cvs updates
[15:38] <AdamDH> I am packaging this project http://mspgcc.sourceforge.net/
[15:39] <Laney> binutils.x.msp.y probably works
[15:39] <Laney> y can be whatever, probably the date of your cvs checkout
[15:41] <AdamDH> this is my first attempts at packaging, so its a learning curve for me
[15:41] <AdamDH> so what would the full version string be?
[15:42] <AdamDH> 2.18 is the current binuils version I am patching against
[15:42] <AdamDH> and cvs-0.0.20081227 is my patch version, I am creating the patches as well
[15:44] <Laney> binutils.2.18.msp.20081227 looks sane to me
[15:44] <Laney> but you can choose what you will, as long as it increases with each version it doesn't matter so much
[15:45] <AdamDH> thanks Laney, I am just trying to show that its based on binutils 2.18 and there is a patch applied that I made from CVS sources
[15:45] <vorian> what's the lp link to the new queue?
[15:45] <vorian> (and hi)
[15:45] <AdamDH> the project is a mess what they do on CVS is have the modified files you copy accross the upstream source, instead of doing that I create a patch
[15:45] <Laney> vorian: /ubuntu/jaunty/+queue
[15:45] <vorian> pfft
[15:45] <vorian> too easy
[15:45] <vorian> thanks Laney
[15:46] <Laney> welcome
[15:46] <AdamDH> i dont think any of this will ever get offically into ubuntu, so will live in a 3rd party repo
[15:47] <AdamDH> thanks for the help Laney
[15:47] <Laney> np
[15:49] <AdamDH> just at the stage of writing the rules file
[15:50] <isle85> I 'm trying to write the watch file, but I don't know what to upload on "my" server, and the right syntax for it
[15:52] <AdamDH> Laney does the orignal source have to be in the binutils.2.18.msp430.20081227.tar.gz ?
[15:53] <Laney> AdamDH: If you're calling the package msp then it'll be called msp_binutils.218.msp340.20081227.orig.tar.gz
[15:53] <AdamDH> im calling the package msp430-binutils
[15:54] <Laney> the package name goes before the _
[15:54] <AnAnt> Hello, could someone review http://revu.ubuntuwire.com/details.py?package=ubuntume-themes ?
[15:54] <AdamDH> i am then applying msp430-binutils-cvs-20080212.patch using the rules file
[15:55] <AdamDH> just realised I dropped 2.18 from that need to update my script
[15:55] <Laney> AnAnt: You don't need to use revu for a package update
[15:55] <Laney> Just file a bug and attach the .diff.gz
[15:55] <AnAnt> Laney: it's a native package
[15:55] <Laney> AdamDH: I was thinking you'd apply the patch in the orig
[15:56] <Laney> AnAnt: So attach the new tar.gz, and maybe a diff too
[15:58] <AnAnt> can someone help me with a python package ?
[15:58] <AdamDH> Laney, I have done that and made a msp430-binutils-cvs-20080212.patch
[15:58] <AdamDH> sorry msp430-binutils-cvs-0.0.20081208.tar.gz
[15:58] <AnAnt> when I use dh_pysupport , all the *pyc files are removed, whys that ?
[15:58] <AdamDH> so this msp430-binutils-cvs-0.0.20081208.tar.gz is ready to go and can be compiled from source
[15:59] <Laney> AdamDH: That's cool, then you don't need to patch it in debian/rules then
[16:00] <AdamDH> i wrote a php script that goes about and creates the package and patches from CVS etc
[16:00] <Laney> AdamDH: You can create a get-orig-source target in debian/rules which will do whatever is necessary to create the .orig.tar.gz
[16:01] <Laney> downloading, patching and so
[16:01] <Kalidarn> mm i wonder where the launchpad admins are ;)
[16:01] <AdamDH> thanks Laney
[16:01] <Laney> Kalidarn: In #launchpad?
[16:01] <AdamDH> i am a good programmer but never packaged anything before
[16:01] <Kalidarn> channel seems dead
[16:01] <Laney> AdamDH: It's just a new set of skills
[16:01] <Laney> Kalidarn: It is the holidays and a weekend
[16:01] <Kalidarn> true
[16:02] <Kalidarn> :P suppose
[16:02] <AdamDH> do you think this should be renamed to show what verison of binutils it uses msp430-binutils-cvs-0.0.20081201.tar.gz?
[16:02] <AdamDH> at the moment it shows the patchset only
[16:03] <AnAnt> Laney: thanks
[16:03] <bluesmoke> AnAnt: pyc files are version and arch specific
[16:03] <AnAnt> bluesmoke: so ?
[16:03] <Laney> They're byte-compiled at install-time, aren't they
[16:03] <Laney> ?
[16:03] <bluesmoke> AnAnt: So they don't belong in an arch-independent package that can work with multiple versions of python
[16:05] <AnAnt> are they really compiled at install-time ?
[16:08] <AdamDH> so Laney this would be sane, msp430-binutils.2.18.msp430.cvs-0.0.20081227?
[16:08] <AdamDH> and the 20081227 updates each day
[16:08] <Laney> AdamDH: Looks good to me
[16:08] <AdamDH> thanks again
[16:09] <Laney> AdamDH: Actually the - after cvs might mess things up, better to use a .
[16:09] <Laney> (or test it)
[16:09] <AdamDH> i will add a . i read something in the debian stuff - are bad
[16:10] <Laney> AnAnt: See /usr/share/doc/python-support/README.gz
[16:13] <AdamDH> Laney my source now looks like msp430-binutils.2.18.msp430.cvs.0.0.20081227.tar.gz and sp430-binutils.2.18.msp430.cvs.0.0.20081227.orig.tar.gz so this is right so far?
[16:15] <Laney> AdamDH: It needs to be msp430_...
[16:15] <AdamDH> can I do msp430-binutils_ ?
[16:16] <Laney> if you want the package name to be that, yes
[16:17] <AdamDH> thanks, looks like I need to update the versioning on the source packages I create as well
[16:17] <AdamDH> as when I extract msp430-binutils-cvs-0.0.20081227 i get my orignal version
[16:19] <AdamDH> thanks for the help I think I know where I am going now
[16:21] <Laney> good luck!
[16:22] <AnAnt> Laney: thanks
[16:22] <AdamDH> what are the chances of getting packages like this into the offical tree?
[16:23] <AdamDH> i think I would be better of trying to get it into upstream like the AVR cross compiler did
[16:24] <Laney> That's a good long term goal
[16:26] <AdamDH> people are not using the cross compiler as its hard at the moment to get a working tool chain my aim is to improve that as the MSP430 is a good microcontroller and the compiler is stable, just no packages only a souce install
[16:26] <AdamDH> or packages that are years out of date
[16:35] <Adri2000> Laney, iulian: dns are dead. adding "88.191.82.11 dad.dunnewind.net" to your hosts file should work
[16:42] <AdamDH> the first line of my changelog Laney should read: msp430-binutils (msp430-binutils.2.18.msp430.cvs.0.0.20081227-1) unstable; urgency=low
[16:43] <AdamDH> is that correct?
[16:43] <Laney> AdamDH: If your orig.tar.gz is msp430-binutils_...that really long version...orig.tar.gz then yes
[16:44] <AdamDH> this is my source: msp430_binutils.2.18.msp430.cvs.0.0.20081227.orig.tar.gz
[16:45] <AdamDH> ah got the _ in the wrong place
[16:46] <Laney> AdamDH: Take the "msp430-binutils" out of the ()
[16:46] <Laney> then you should have
[16:46] <Laney> then you should have iain@intrepid:~$
[16:46] <Laney> iain@intrepid:~$
[16:46] <Laney> shit
[16:46] <Laney> sorry!
[16:47] <Laney> msp430-binutils_binutils.2.18.msp430.cvs.0.0.20081227.orig.tar.gz
[16:47] <Laney> msp430-binutils_2.18.msp430.cvs.0.0.20081227.orig.tar.gz even
[16:51] <AdamDH> right following that I should have msp430_binutils.2.18.msp430.cvs.0.0.20081227.orig.tar.gz and msp430_binutils.2.18.msp430.cvs.0.0.20081227.orig.tar.gz and then control is then msp430-binutils (2.18.msp430.cvs.0.0.20081227-1) unstable; urgency=low?
[16:51] <jpds> You should have: msp430-binutils_2.18.msp430.cvs.0.0.20081227.orig.tar.gz as Laney said.
[16:52] <AdamDH> crap got the - and _ mixed up I will fix that
[16:52] <AdamDH> realised after I pasted it
[16:53] <AdamDH> i should have said msp430-binutils_2.18.msp430.cvs.0.0.20081227.orig.tar.gz
[16:57] <AdamDH> so this is right for the changelog? msp430-binutils (2.18.msp430.cvs.0.0.20081227-1) unstable; urgency=low
[16:58] <jpds> Yes.
[16:58] <AdamDH> thanks jpds
[16:58] <Laney> if you want to upload to sid, that is
[17:02] <AdamDH> standards version, for my system a apt-cache show debian-policy | grep Version. shows 3.8.0.1ubunu2 so I just use this?
[17:03] <Laney> 3.8.0 is the most recent, but you don't have to follow Debian policy if you're not going to upload to Debian
[17:03] <Laney> or Ubuntu
[17:05] <AdamDH> i dont think I am going to be able to get this officaly into debian or ubuntu, never had any look getting it into Gentoo either so its going to have to be in a 3rd party repo maintained by myself until the code is added upstream
[17:07] <AdamDH> now I need to write my first rules file
[17:12] <AdamDH> is there a template rules file somewhere? just a generic one I can add my code into?
[17:14] <maxb> The program dh_make asks you some questions and generates boilerplate debian-packagings
[17:14] <AdamDH> i was not using dh_make but will give it a try
[17:14] <Laney> AdamDH: ^, or you can copy another rules file (binutils?) and modify that
[17:14] <AdamDH> dpkg-buildpackage -S -rfakeroot was going to do that
[17:14] <Laney> also there is a packaging guide on the wiki, you should check it out
[17:15] <AdamDH> there is http://packages.ubuntu.com/intrepid/binutils-avr this but I could not find the debain control files
[17:15] <Laney> AdamDH: apt-get source binutils
[17:17] <Mez_> jpds: done
[17:17] <jpds> Mez: Thanks.
[17:25] <AdamDH> cheers, the rules files take some reading to understand
[17:47] <AdamDH> dont like modifying something unless I know what each line does, but I have gone down the rules file and I see a #ifeq (,$(DEB_BUILD_GNU_TYPE))
[17:47] <AdamDH> #  include /usr/share/dbs/dpkg-arch.mk
[17:47] <AdamDH> #endif
[17:47] <AdamDH>  what is that for?
[17:48] <maxb> Ewww, you've got a DBS package?
[17:49] <maxb> DBS is a build system which is rather strongly deprecated these days
[17:49] <Laney> it's commented out
[17:49] <AdamDH> i added the comments
[17:49] <AdamDH> i grabbed the apt-get source binutils-avr
[17:50] <AdamDH> as its close to what I am doing and its in there
[17:50] <maxb> The purpose of that specific fragment is more general though - it's to test if certain values were already supplied by the environment, and if not, set them up via including a makefile fragment for the purpose
[17:50] <AdamDH> i notice the configure arguments: CONFARGS = --prefix=/usr \
[17:50] <AdamDH>            --build=$(DEB_BUILD_GNU_TYPE) \
[17:50] <AdamDH>            --host=$(DEB_HOST_GNU_TYPE) \
[17:50] <AdamDH>            --target=$(TARGET) use it
[17:51] <AdamDH> seems allot of work in rules just to run ./configure make and make install
[17:59] <maxb> I think the general essence of that build host stuff is that the rules file is not trusting the ./configure to pick the right system types automatically and is feeding the ones known to the debian build system
[18:07] <AdamDH> ah I follow
[18:08] <AdamDH> its my first package / rules file so would like to fully understand what is going on
[18:24] <isle85> a question about /debian/manpage.1 do I have to rename it the name of my package as "mypackage.1" ?
[18:27] <directhex> name of executable.
[18:28] <loic-m> name_of_executable.1 usually
[18:28] <loic-m> Don't forget to write it ;)
[18:28] <isle85> directhex: thank you.
[18:29] <isle85> loic-m: done ;-)
[18:36] <maxb> Does anyone know why this package was only built on i386? https://edge.launchpad.net/ubuntu/+source/zblast/1.3-2.3ubuntu1
[18:37] <Laney> maxb: Look at the architectures in control
[18:37] <jpds> maxb: It's an "all" package, only needs to be built once as it's arch indepent
[18:37] <Laney> or ^ for a less obtuse response :)
[18:37] <jpds> independant*
[18:38] <jpds> maxb: ACtually if you click on the seperate binary packages, you get a list of different arch builds on the side.
[18:39] <directhex> +Package: zblast-svgalib
[18:39] <directhex> +Architecture: i386
[18:40] <maxb> Yes... but what about zblast-x11? It's missing for amd64 and I can't figure out why
[18:40] <maxb> And *that* package is Arch: any
[18:41] <AdamDH> how do I correctly determine the build type and host type for use in rules?
[18:41] <directhex> Published as
[18:41] <directhex>     * zblast-x11 1.3-2.1 in amd64 (Release)
[18:41] <directhex> http://launchpadlibrarian.net/3094533/zblast-x11_1.3-2.1_amd64.deb
[18:41] <isle85> loic-m: something must be wrong, as my man page doesn't appear in the files installed by my package ;-)
[18:42] <AdamDH> im guessing this is the best way: DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
[18:42] <AdamDH> DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
[18:43] <maxb> directhex: Yes - but that's an old version - the binary is outdate w.r.t. source
[18:44] <maxb> I'm trying to chase down some of the long-term outdates that existed in the intrepid release and still exist in jaunty
[18:44] <directhex> possibly it's on p-a-s?
[18:45] <maxb> Well, the zblast-svgalib package is P-a-s'ed, but not %zblast or zblast-x11
[18:56] <loic-m> isle85: sorry, away. You need to specifically install it with a line in debian/rules
[18:57] <isle85> ah, ok. I'm gonna try to find examples.
[18:58] <loic-m> isle85: in the binary arch: build install section, use 	dh_installman debian/binary_name.1 debian/other_binary_name_if_you_have_more_than_one.1
[18:59] <loic-m> the dh_installman line should already be there in the rules file created for you, you just need to tell it which page to install
[18:59] <isle85> my rules file is simple as that : include /usr/share/cdbs/1/rules/debhelper.mk
[19:01] <loic-m> You should have a pre-filed rules file in debian (along with plenty of .ex .EX files) if you follow the howto to create your package
[19:01] <ebroder> isle85: You probably want to create a file called debian/man with the list of manpages
[19:01] <ebroder> (or debian/$package.man if there are multiple binary packages)
[19:02] <isle85> ok, I'm gonna try the first one. debian/man
[19:02] <ebroder> Oh wait - it's debian/manpages, sorry
[19:04] <loic-m> ebroder: is debian/manpage a requirement < Debian policy?
[19:05] <AdamDH> this is something that is confusing me: you do unpack: then direct it to unpack-stamp why? unpack: unpack-stamp
[19:05] <AdamDH> unpack-stamp: why not just do unpack: and run it all in there? why is it called unpack-stamp?
[19:05] <ebroder> loic-m: Huh? debian/manpages is a file that dh_installman uses to get a list of manpages to install. It uses that in addition to what it gets passed on the command line
[19:06] <ebroder> loic-m: It's the same concept as debian/links, debian/install, debian/dirs, etc...
[19:07] <loic-m> ebroder: thanks. But what is the prefered method in Debian/Ubuntu? (I'm asking because I've got a package on REVU)
[19:07] <maxb> AdamDH: IIUC, stamp files allow a time-consuming operation to not be unnecessarily repeated across multiple invocations of the rules file
[19:07] <ebroder> loic-m: I don't know that there's a preference. Personally, I use CDBS for all of my packages, so I try to use files outside debian/rules to adjust behavior when I can
[19:08] <isle85> doesn't work
[19:08] <ebroder> isle85: You created a debian/manpages?
[19:09] <isle85> I created a file named "man", not manpages. my mistake
[19:09] <AdamDH> maxb: so if I am compiling say binutils that's a long compile time, using the stamp files would be the best way to go?
[19:09] <ebroder> isle85: Yeah, sorry - I corrected myself later
[19:13] <isle85> ebroder: in that debian/manpages file, I just add a line : mypackage.1 is it correct ?
[19:13] <ebroder> isle85: I think so
[19:13] <isle85> ebroder: so it doens't work
[19:14] <ebroder> isle85: Look in the build log - do you see dh_installman getting run?
[19:16] <isle85> no
[19:16] <ebroder> isle85: Can you pastebin your debian/rules and you debian/control?
[19:19] <AnAnt> Hello, is this the place to ask a package be nuked from REVU ?
[19:19] <isle85> ebroder: find when it failed : dh_installman -pgenj-arvernes
[19:19] <isle85>  -> Aborting with an error
[19:21] <crimsun> AnAnt: yes, which? (no, i'm no a revu admin. someone will process the request)
[19:21] <isle85> ebroder: it 's there : http://rafb.net/p/E7rYxK29.html
[19:21] <AnAnt> crimsun: hijra
[19:21] <ebroder> isle85: Does your debian/manpages file have one manpage per line?
[19:21] <isle85> yeap
[19:21] <jpds> AnAnt: Let me take a look.
[19:21] <AnAnt> crimsun: I wrongly uploaded it to revu instead of my PPA :)
[19:22] <ebroder> isle85: Does it have a more specific error, or does it just say that it's aborting?
[19:22] <isle85> ebroder: just it aborts
[19:23] <ebroder> isle85: What happens if you run `dh_installman -pgenj-arvernes` by hand?
[19:24] <jpds> AnAnt: OK; archived.
[19:24] <AnAnt> jpds: thanks
[19:31] <maxb> I've been looking at outdated packages, and cmucl has not built from source since hoary (!) There's bug 31098 open about this, but it has no activity since February.  Is there some way in which the package should be flagged as broken/orphaned and in need of attention?
[19:32] <loic-m> isle85: I'm confused by your rules files, but I'm no expert. Can you get anything done without targets and such? For man pages, you'd need to at least invoke dh_installman
[19:32] <ebroder> loic-m: https://wiki.ubuntu.com/PackagingGuide/Howtos/CDBS
[19:33] <loic-m> ebroder: thanks
[19:35] <ebroder> maxb: Have you looked into a more complex manual bootstrapping process? That would be a much better solution than manually installing the package on the buildds
[19:36] <AdamDH> do you have to have an unpack: i see some rules files dont use one
[19:51] <AdamDH> read 6 diffrent rules files, and the debian and ubuntu maintainers guides, some say you need unpack: some its commented out, there is packages with unpack: so is it required or not? as a new packager there is allot of conflicting information
[19:56] <crimsun> AdamDH: nothing is _required_ beyond calling dpkg-buildpackage in some fashion.
[19:56] <crimsun> AdamDH: now whether a nice abstraction like cdbs does that for you is another matter
[19:56] <AdamDH> upto now I have been creating everything by hanf
[19:56] <AdamDH> *hand
[19:57] <AdamDH> my source is tar.gz
[19:58] <AdamDH> so what is the correct way to create the rules file?
[20:02] <crimsun> AdamDH: there is no "correct way". there is "whatever works for the maintainer and abides by Policy".
[20:02] <crimsun> AdamDH: hence the confusion
[20:02] <jmarsden> AdamDH: There is no one correct way, but you should read about debhelper and dh_make to get you started, I suspect
[20:02] <crimsun> AdamDH: some maintainers prefer cdbs, others swear it's the second coming of ultrix and vms's lovechild
[20:03] <AdamDH> as I new maintainer I am really lost, I am a long term linux user / programmer but with debian packages I have spent the day banging my head off a desk to try and get something to work
[20:03] <ebroder> AdamDH: You should really try looking at cdbs. I think it makes your life a lot easier as a new packager
[20:03] <crimsun> i definitely recommend at least sticking with debhelper in some fashion, be it through a higher abstraction like cdbs, or just using debhelper directly
[20:04] <crimsun> dh7 has a lot of cdbs niceties anyhow
[20:04] <loic-m> AdamDH: it hurt less after a while. Either the desk gives up, or your head. Or both.
[20:04] <jmarsden> AdamDH: And read and try to understand https://wiki.ubuntu.com/PackagingGuide/Complete asnd work through some examples?
[20:05] <AdamDH> I have been reading https://wiki.ubuntu.com/PackagingGuide/Complete before I can into IRC for help, in my case I am packaging for a cross compiler
[20:05] <AdamDH> I came from Gentoo and there ebuilds system just works no headaches
[20:06] <AdamDH> But most of the user base is ubuntu based so I set about creating packages for ubuntu
[20:07] <AdamDH> *Ubuntu
[20:09] <jmarsden> AdamDH: Starting out by packaging a new piece of software, never mind a cross-compiler, may be expecting a lot of your brain... start by fixing bugs in a few existing packages and creating debdiffs?  You'll learn more that way, I suspect.
[20:16] <AdamDH> rules is just a makefile, I have written quite a few make files from scratch, but each rules file I look at seems to handle something diffrentley like unpack. I have packaged this for other package management system, this is the first time I have done it for Debian/Ubuntu
[20:16] <AdamDH> *systems
[20:16] <AdamDH> and my first package for Debian/Ubuntu
[20:18] <jcastro> what I do is find a similar package to what I am packaging and then base my packaging off of that
[20:18] <jcastro> so if it's a python program I find another python one, or mono or whatever.
[20:19] <AdamDH> thats where I started but there are 3 older packages not maintained any more but each one does something diffrent in rules for the same programme hence the confusion
[20:19] <AdamDH> there does not seem to be a correct way
[20:19] <ebroder> AdamDH: There's more than one way to do it. Pick the one you like best. What matters is that the package builds
[20:20] <AdamDH> i tried dh_make it wont work with my sources
[20:27] <maxb> ebroder: No, I'm not very interested in Lisp myself. Personally I'd opt for just removing the package, if no one has been sufficiently interested to make it buildable since hoary
[20:28] <maxb> AdamDH: The Debian Policy Manual specifies the few targets which are actually *required* for a rules file. All others are simply implementation details
[20:30] <AdamDH> maxb thanks, I will take a read seems to show what is needed gives me something to work to
[20:30] <maxb> Why won't dh_make work, ooi?
[20:31] <ebroder> maxb: If you don't have any interest in keeping the package around, pushing for its removal is probably reasonable, but I don't know what that process looks like. Maybe someone else can advice?
[20:31] <ebroder> *advise
[20:32] <maxb> Yup. Basically, after discovering that Ubuntu releases could actually contain outdated binaries, I'm on a spring-cleaning kick to get rid of them where possible
[20:40] <AdamDH> right I am getting closer, but running dpkg-buildpackage -S -rfakeroot i get:
[20:40] <AdamDH> parsechangelog/debian: warning:     debian/changelog(l6): badly formatted heading line
[20:40] <AdamDH> LINE: -- Adam Horden adamhorden@adamhorden.net  Sat, 27 Dec 2008 20:38:21 +0000
[20:40] <AdamDH> any ideas?
[20:41] <ebroder> Your e-mail address needs to be in <>
[20:41] <AdamDH> thanks will change that did not spot it
[20:41] <ebroder> The easiest way to get the changelog right is to either use the dch command or use dpkg-dev-el, if you're an emacs user
[20:43] <AdamDH> changed it but I get the same error
[20:43] <AdamDH> rsechangelog/debian: warning:     debian/changelog(l6): badly formatted heading line
[20:43] <AdamDH> LINE: -- Adam Horden <adamhorden@adamhorden.net>  Sat, 27 Dec 2008 20:42:45 +0000
[20:43] <AdamDH> parsechangelog/debian: warning:     debian/changelog(l6): found eof where expected more change data or trailer
[20:43] <AdamDH> sorry did not mean to paste all that
[23:32] <AdamDH> i have a few questions regarding the best way to package a cross compiler, my folder when I am working in has a debain folder and a tar.gz of the upstream source, so I need a unpack: to unpack it then apply the patch inside the unpacked source? is this the best way to apply my patch?