| <micahcowan> お休み | |
| <Knightlust> hey jucato | |
| <Jucato> Knightlust: ehehe | |
| <Knightlust> ang aga ah, kala ko mamaya ka pa papasok | |
| <Jucato> just checking in :-D | |
| <Knightlust> aight | |
| <Jucato> still reading feeds and stuff :-D | |
| <Knightlust> hehehe, rss addict! | |
| <Knightlust> hehehe | |
| <Knightlust> aight, gotta go get some breakfast, laterz! | |
| <Jucato> ehehe! yeah! RSS roks! :-p | |
| <tomveens> hi | |
| <LaserJock> hello | |
| <tomveens> is lesson coming or am I not reading the right time? | |
| <LaserJock> in about 15 min. | |
| <tomveens> okay cool, then my time quality's are not to bad | |
| <tomveens> hey I'm doing that pbuilder thing, you know what's it for? | |
| <tomveens> https://wiki.ubuntu.com/MOTU/School/PackagingBasics (that thing) | |
| <LaserJock> yeah, it's for building .debs in a clean environment | |
| <micahcowan> to verify that such things as dependencies and such are accurate, yes? | |
| <LaserJock> yep | |
| <LaserJock> and to not mess up your system and source package | |
| <LaserJock> but I'm getting ahead of myself ;-) | |
| <tomveens> sorry, friend called that a had to watch a thing on his computer | |
| <tomveens> but I'm not really getting | |
| <tomveens> I know what you are saying | |
| <tomveens> can not really refrace it then what is does? | |
| <tomveens> is it making it's own debs environment? | |
| <LaserJock> tomveens: are you going to hang of for the whole session? I'll talk about it later on :-) | |
| <tomveens> LaserJock, I'll keep watching | |
| <nixternal> whoa | |
| <nixternal> i almost misesed this | |
| <LaserJock> nixternal: what, you were going to miss the raging Ubuntu-holic MOTU?!? ;-) | |
| <Jucato> umm... is can anyone who's interested (but not a packager... yet) sit in the class? | |
| <LaserJock> yes, that's the idea | |
| <LaserJock> :-) | |
| <LaserJock> everybody is welcome! | |
| <Jucato> cool! thanks! | |
| <yoshiznit123> will you talk about the process of getting your package into universe or just building the package itself? | |
| <nixternal> i didn't mean to | |
| <jsgotangco> HEY | |
| <nixternal> i so need to learn packaging better | |
| <nixternal> hiya jsgotangco ;) | |
| * jsgotangco flicks paper plane at LaserJock | |
| <Jucato> lol | |
| <LaserJock> yoshiznit123: well, I can kinda talk about whatever people want. I'll start of with some building the package stuff | |
| <Jucato> jsgotangco: loves to flick paper planes :-D | |
| <nixternal> ubotu needs some brains..he knows nothing about motu-school ;( | |
| * jsgotangco bullies nixternal | |
| <nixternal> always ;) | |
| <nixternal> kubuntu dapper and xubuntu dapper translations are 100% complete ;) now i can do some packaging ;) | |
| <nixternal> doc wise that is | |
| * LaserJock is going to have to get out his ruler | |
| <micahcowan> make that a yardstick | |
| <nixternal> is it getting that deep LaserJock? | |
| <nixternal> gahaha | |
| <LaserJock> oh my | |
| <jsgotangco> bah | |
| * jsgotangco uses a laser pointer at LaserJock | |
| <tomveens> it's time! | |
| <yoshiznit123> hey, i've always wondered this, how do you guys do the "***thisperson is doing something"? :-) | |
| <tomveens> on my cpu-clock | |
| <yoshiznit123> ok nvm ;-P | |
| <micahcowan> use /me, yoshiznit123 | |
| <Jucato> yoshiznit123: /me <text> | |
| * yoshiznit123 tries it out | |
| <yoshiznit123> haha cool | |
| * tomveens doing /me | |
| <LaserJock> ok, I need everybody to quiet it down now | |
| * yoshiznit123 will definetly start overusing this | |
| <yoshiznit123> kk | |
| <nixternal> +m | |
| <jsgotangco> can anyone +m the channel | |
| <micahcowan> not if he wants to encourage participation... which he might | |
| <jsgotangco> we can remove moderation after discussion | |
| <yoshiznit123> ahh my pbuilders still going :-) | |
| <LaserJock> I just need people to be quiet while I"m talking OK? | |
| <jsgotangco> or have some people with voice accept questions | |
| <LaserJock> I've got a ton of material and we need to get through it quickly so we can do more Q&A stuff | |
| <jsgotangco> LaserJock: its your call | |
| <LaserJock> ############ Class is Starting ################ | |
| <LaserJock> Ok, so has everybody seen https://wiki.ubuntu.com/MOTU/School/PackagingBasics ? | |
| <LaserJock> I wrote down a list of packages you will need | |
| <LaserJock> and then I put down some instructions for building a pbuilder, which can take some time | |
| <LaserJock> if you don't have time to do the pbuilder, that's ok | |
| <LaserJock> Welcome to the MOTU School. These sessions are presented by the Universe development community (MOTU) as a way of | |
| <LaserJock> helping Ubuntu users to get involved with Ubuntu development. See http://wiki.ubuntu.com/MOTU for more info. | |
| <LaserJock> Today what I will be presenting is not in any way a comprehensive reference to packaging. What I want you to get o | |
| <LaserJock> ut of this is some understanding of the tools and techniques that people use to make and maintain source packages. | |
| <LaserJock> A source package is actually made up of 3 different files: | |
| <LaserJock> 1) .dsc (description) file that holds md5sums of the other files | |
| <LaserJock> 2) .orig.tar.gz which is the source tarball as you would download it from the program's homepage | |
| <LaserJock> 3) .diff.gz that holds any changes we make to the .orig.tar.gz | |
| <LaserJock> OK, let me know if I'm going too fast or too slow here | |
| <LaserJock> First off, lets look at an existing package | |
| <LaserJock> plotdrop | |
| <LaserJock> first lets make a temp directory to work in and grab the source: | |
| <LaserJock> mkdir -p ~/motuschool/plotdrop | |
| <LaserJock> cd ~/motuschool/plotdrop | |
| <LaserJock> apt-get source plotdrop | |
| <LaserJock> Note 1: you need to have the source repo's (deb-src) enabled in your /etc/apt/sources.list | |
| <LaserJock> Note 2: unlike apt-get install, you should not run apt-get source via sudo | |
| <micahcowan> is it okay if we're getting the dapper one? | |
| <LaserJock> yeah | |
| <LaserJock> in this case the dapper and edgy packages are the same (because I'm lazy and haven't updated them ;-) ) | |
| <LaserJock> OK, now you have 3 files (the source package) and a directory (which is the unpacked source package) | |
| <LaserJock> lets have a look around: | |
| <LaserJock> ls plotdrop-0.5/ | |
| <LaserJock> and we see that this a small C program with typical files (COPYING, Makefile, Changelog, etc.) | |
| <LaserJock> in fact, if we were to extract the tarball from the plotdrop homepage the only difference we would find is that debian directory | |
| <LaserJock> if you want you can look at the diff to the source tarball by: | |
| <LaserJock> zless plotdrop_0.5-0ubuntu1.diff.gz | |
| <LaserJock> OK, any questions so far? | |
| <LaserJock> does everybody get what a source package is? | |
| <poningru> yeppers | |
| * bddebian thinks so :-) | |
| <cstudent> yep | |
| <LaserJock> ok, I just want to make sure everybody is on the same page, so be patient if I'm boring you ;-) | |
| <tomveens> what is zless for a command/program? | |
| <micahcowan> it decompresses, and then views, the given file | |
| <poningru> Zless is a filter which allows examination of compressed or plain text | |
| <poningru> files one screenful at a time on a soft-copy terminal. | |
| <TheMuso> zless unzips the file, and displays the contents of the file allowing you to scroll up and down. | |
| <LaserJock> yeah, there is also zgrep | |
| <tomveens> ownly for the tar.gz? | |
| <jsgotangco> LaserJock: so your recommendation is zless? | |
| <micahcowan> no, the diff.gz | |
| <tomveens> okay | |
| <LaserJock> yeah z* is great for these | |
| <LaserJock> because you don't have to decompress them first | |
| <nixternal> +1 | |
| * TheMuso is glad he joined. He just learnt something new. :) | |
| * poningru too | |
| <LaserJock> Now, lets actually dig into that debian/ directory and see what's going on: | |
| <LaserJock> cd plotdrop-0.5/debian/ | |
| <LaserJock> ls | |
| <LaserJock> We see several files and a patches directory. All of the packaging info and patches to the source need to produce a good quality .deb are in here | |
| <LaserJock> What we need to do know is go through what the files are for. Lets start with changelog | |
| <LaserJock> less changelog | |
| <LaserJock> The first thing to note is that the format of the changelog is particular. dch is a program (found in the devscripts packages) that helps you with the formating. | |
| <LaserJock> normally you run it like dch -i | |
| <LaserJock> and it fires up your editor with a template | |
| <LaserJock> One the first line you will find the package name, version, and release. Each time a new source package is uploaded to the Ubuntu build machines it should have a higher version than \ | |
| <LaserJock> the previous one. | |
| <LaserJock> hehe, the old cut-n-paste from emacs isn't working so well ;-) | |
| <LaserJock> The version goes like this: <programversion>-<debianrevision>ubuntu<bunturevision> | |
| <LaserJock> In this case the program's version is 0.5, the Debian revision is 0 because at the time it wasn't in Debian, and the Ubuntu revision is 1 | |
| <LaserJock> Next we see various notes as to what was changed from one version to the next and finally a "who done it" line that shows who made the changes and at what time. | |
| <LaserJock> welshbyte: ^^ answers your question :-) | |
| <welshbyte> :) | |
| <nixternal> ubuntu revision is 1 if we are doing edgy? | |
| <LaserJock> it is the first revision of that package | |
| <LaserJock> so each time the debian revision gets bumped, the Ubuntu revision counter is reset | |
| <LaserJock> and the same thing with the upstream (origingal) version and Debian | |
| <yoshiznit123> sorry, could you explain that a little more? | |
| <LaserJock> yeah | |
| <LaserJock> ok, so say we have 0.5-0ubuntu1 | |
| <LaserJock> that means nobody has packaged it for Debian (the Debian revision is 0 ) | |
| <LaserJock> but when the package is in debian, it's version will be 0.5-1 | |
| <LaserJock> now say in the mean time we fixed a bug and uploaded 0.5-0uuntu2 | |
| <LaserJock> when that debian package gets to Ubuntu it will go to 0.5-0ubuntu1 | |
| <LaserJock> or if that bug fix is also included in the debian package it will got to 0.5-1 | |
| <micahcowan> 1ubuntu1? | |
| <LaserJock> sorry, that previous would should be 0.5-1ubuntu1 | |
| <yoshiznit123> ok, gotcha | |
| <LaserJock> thanks micahcowan | |
| <LaserJock> so basically Ubuntu is the lowest on the food chain here :-) | |
| <LaserJock> at least when it comes to versioning | |
| <micahcowan> and so, if ubuntu makes no changes, the ubuntu1 bit doesn't get tacked on? | |
| <LaserJock> right | |
| <LaserJock> because if we don't need anything Ubuntu specific we actually grab the Debian source package | |
| <LaserJock> which doesn't have the ubuntu1 | |
| <LaserJock> that's what is called a sync | |
| <yoshiznit123> and if the upstream source is already packaged for debian, it doesnt get the -1? | |
| <yoshiznit123> as in it already contains the debian directory | |
| <LaserJock> if it already is in Debian, but we need to make changes, it would be 0.5-1ubuntu1 | |
| <LaserJock> basically we take the Debian package, and if we need to make modifications we tack on ubuntu1 on the end | |
| <yoshiznit123> ok fair enough | |
| <tomveens> (debian version)ubuntu(ubuntu version)? | |
| <micahcowan> I believe it does get the -1, regardless. | |
| <LaserJock> tomveens: right | |
| <LaserJock> so total we have, (program version)-(debian version)ubuntu(ubuntu version) | |
| <tomveens> okay | |
| <LaserJock> it's a bit complicated but in the end it makes it much easier for apt-get and other tools | |
| <LaserJock> let's move on, shall we? | |
| <LaserJock> Ok, next is the control file: | |
| <LaserJock> less control | |
| <LaserJock> The control file holds a lot of information about the source package and it's resulting binary package (.deb). It is arranged in field: value form and most of the fields are fairly | |
| <LaserJock> self-explanitory but the values are, as you will see, more difficult to determine | |
| <LaserJock> For the source package there is: | |
| <LaserJock> Source: the source package name | |
| <LaserJock> Section: what section of the repository does the program belong in | |
| <LaserJock> Priority: is the program essential for a properly running Linux system? | |
| <LaserJock> Maintainer: who is taking on the responsiblity, mostly for Debian | |
| <LaserJock> Build-Depends: the packages that must be installed for the source package to be able to build the .deb | |
| <LaserJock> Standards-Version: which version of the Debian Policy does this package adhere to | |
| <poningru> ask a quick question? | |
| <LaserJock> sure | |
| <poningru> the priority stuff | |
| <poningru> is there a set options, or can we put whatever we want | |
| <poningru> like low, optional etc. | |
| <LaserJock> there are set optionis | |
| <poningru> cool | |
| <LaserJock> that can be found in the Debian Policy | |
| <poningru> ah ok | |
| <poningru> thnx | |
| <LaserJock> especially: http://www.debian.org/doc/debian-policy/ch-source.html and http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles | |
| * poningru adds to bkmrks | |
| <LaserJock> For the binary package there is: | |
| <LaserJock> Package: binary package name, you can have more than 1 per source package so you need to specify | |
| <LaserJock> Architecture: what architecture the binary will build on. "any" means it should build on all archs and "all" means it doesn't have any arch dependent files (i.e. a program written in an interpreted language like python) | |
| <LaserJock> Depends: the packages that the binary package depends on | |
| <LaserJock> Description: First line holds the short description | |
| <LaserJock> Subsequent lines hold the long description. Be careful of the first space in each line, it is important. | |
| <micahcowan> denoting continuation of the current field, right? | |
| <LaserJock> micahcowan: right | |
| <LaserJock> ok, notice that there is a build dependency on debhelper in the source section | |
| <LaserJock> debhelper is a build helper program | |
| <LaserJock> we will see it later | |
| <LaserJock> but that version (>= 4.0.0) is important because it also has to do with the next fil | |
| <LaserJock> *file | |
| <LaserJock> compat | |
| <LaserJock> compat just holds and integer that corresponds to the debhelper version we are using | |
| <LaserJock> so in this case, 4 | |
| <poningru> ah | |
| <poningru> err sorry | |
| <LaserJock> always make sure that compat and the build dependecy in control match | |
| <LaserJock> On to the copyright file. This file is very important to us, as a open source distro, because it holds the copyright and license information for all the files in the source package. The important things to have are: | |
| <LaserJock> 1) where you got the source tarball | |
| <LaserJock> 2) document who the source tarball copyright holder is (an include a year) | |
| <LaserJock> 3) the License under which we are allowed to distribute the code | |
| <LaserJock> For common licenses like the GPL you can put the preample and then a notice that has the location of the full copyright in /usr/share/common-licenses . If the license is *not* one of those in /usr/share/common-licenses then you will need to inclued *all* the text of the license. | |
| <LaserJock> A common mistake is for the packager to just take the word of the program's homepage for the license. The packager need to make sure that the source code has licensing information and that all the files in the source package are accounted for. | |
| <LaserJock> People often forget artwork and documentation (which is often under a difference license than the code itself) | |
| <LaserJock> Questions about copyright? | |
| <LaserJock> problems with licensing and the copyright file is one of the more common reasons a package is rejected the first time | |
| <welshbyte> so if a package is covered by >1 licenses, we put them all in there? | |
| <LaserJock> yep | |
| <LaserJock> and you need to say which license belongs to which files | |
| <welshbyte> ok | |
| <LaserJock> it can seem quite tedious and a bit overkill | |
| <micahcowan> I understand that one exception is, alternative licenses, where at least one license would not apply to Debian/Ubuntu (non-free) | |
| <LaserJock> makes sense | |
| <LaserJock> sometimes people even strip out "bad" parts of a source tarball to make them "free" | |
| <LaserJock> we try to avoid that | |
| <LaserJock> but sometimes it needs to be done | |
| <micahcowan> in that case, I suppose you'd need to be careful to do that in the orig.tar.gz, and not the diff? | |
| <LaserJock> usually you do it in the orig.tar.gz but explain somewhere what you did | |
| <LaserJock> and often times you put dfsg in the version to denote that | |
| <welshbyte> "dfsg" ? | |
| <micahcowan> ooc, could you give an example version, showing where "dfsg" would go? | |
| <LaserJock> dfsg = Debian Free Software Guidline | |
| <LaserJock> Guideline | |
| <_RocH> o/ | |
| <LaserJock> that is the document that describes what is "free" and what is not "free" to Debian | |
| <LaserJock> look at the version of Firefox for example | |
| <_RocH> non free , as codecs and propertary drivers | |
| * poningru looks | |
| <LaserJock> non free can mean different things really | |
| <_RocH> true | |
| <LaserJock> there are many programs out there that many people would consider free, but DFSG don't agree | |
| <LaserJock> *doesn't* | |
| <poningru> so what would be the prob in ff? | |
| <poningru> the license of the artwork? | |
| <LaserJock> anyway, if you have a doubt about a license and it's freeness, it's best to look at the debian-legal archives | |
| <LaserJock> or send an email asking about it | |
| <LaserJock> poningru: I can't remember exactly | |
| <micahcowan> I think the Mozilla Pub license may have had some issues, perhaps... but I dunno | |
| <poningru> its trilicensed under GPL and LGPL as well | |
| <poningru> but the artwork isnt | |
| <LaserJock> anyway, we should probably move on | |
| <poningru> right sorry | |
| <LaserJock> Next lets tackle the real meat of the source package, the rules file. | |
| <LaserJock> less rules | |
| <LaserJock> The rules file is a Makefile that is run by dpkg-buildpackage to build the .deb | |
| <LaserJock> I'm not going to go into a lot of detail here because we don't have time, but notice the various rules (clean, build, install, etc.) and also notice that we aren't installing relative to / but instead to $(CURDIR)/debian/plotdrop/ . | |
| <LaserJock> This can cause a lot of problems for people at the beginning. | |
| <LaserJock> All of the dh_* are scripts that are a part of the debhelper build helper (remember we had a dependecy on that in control). | |
| <LaserJock> Each one has a specific task (usually you can get an idea from the name) and they have good manpages so it is a good idea to man each one to see what it does. | |
| <welshbyte> do they basically test something each and then error out if the test fails? | |
| <LaserJock> any questions here? I know there is a lot of stuff there | |
| <LaserJock> no, they do work :-) | |
| <welshbyte> oh ok... i was looking at dh_testroot as an example | |
| <LaserJock> yeah | |
| <LaserJock> like dh_install installs a file | |
| <LaserJock> dh_strip strips the debugging symbols | |
| <yoshiznit123> another quick question, the rules file is run from the root of the tree with make -C debian/rules? | |
| <LaserJock> yeah | |
| <LaserJock> basically | |
| <micahcowan> make -f debian/rules, or just "debian/rules" | |
| <yoshiznit123> oh yea, -f | |
| <LaserJock> -f perhaps | |
| <LaserJock> but I'm not positive on that | |
| <LaserJock> you can actually runs stuff like make -f debian/rules clean | |
| <LaserJock> to test | |
| <micahcowan> it's chmod +x with a #! line, so you can also just run it directly as "debian/rules" | |
| <LaserJock> hehe, Mr. Picky ;-) | |
| <LaserJock> but in the end we don't do any of those things :-) | |
| <LaserJock> we use tools that put all this together | |
| <LaserJock> any other questions? | |
| <welshbyte> so the rules file contains "rules to transform the source package into the binary package" ? | |
| <LaserJock> yes | |
| <welshbyte> ok, so where does it get run? | |
| <welshbyte> or when | |
| <LaserJock> when you build the .deb | |
| <LaserJock> which we will get to shortly :-) | |
| <welshbyte> ok :) | |
| <LaserJock> ok, those are the main files | |
| <LaserJock> lets quickly look at the others | |
| <LaserJock> plotdrop.1 is a man page | |
| <LaserJock> the rule of thumb is anything that goes in /usr/bin should have a man page | |
| <LaserJock> even if it's a GUI | |
| <LaserJock> in this case I had to make one because the author didn't do it for me | |
| <LaserJock> plotdrop.manpages tells dh_installman (in rules) what man file to install | |
| <LaserJock> plotdrop.menu is a Debian menu file | |
| <LaserJock> they aren't used in Ubuntu very much | |
| <tomveens> what is thumb? | |
| <LaserJock> tomveens: where do you see that? | |
| <imbrandon> LaserJock: he means " rule of thumb " | |
| <tomveens> yes | |
| <imbrandon> ;) | |
| <LaserJock> tomveens: oh sorry, that's an English phrase. It means a general rule | |
| <tomveens> okay | |
| <LaserJock> sorry | |
| <LaserJock> ok | |
| <tomveens> Dutch! :) | |
| <tomveens> learning english too! that's good! | |
| <LaserJock> so dirs holds the list of directories that we need made that aren't made by the programs Makefile | |
| <LaserJock> tomveens: excellent | |
| <LaserJock> ok, the last thing is the patches directory | |
| <LaserJock> if we need to modify the source code, it is best to do that via a patch that we apply at build time | |
| <LaserJock> rather than modifying the file directly | |
| <zul> what if there is no patch system in place? | |
| <LaserJock> you can apply your patch in rules | |
| <LaserJock> in this case I used a patch helper program called dpatch | |
| <LaserJock> pitti did an excellent MOTU School session a while back on patch systems | |
| <LaserJock> so I'll let you read that for more detail | |
| <LaserJock> any questions here? | |
| <LaserJock> OK, so now I want everybody to run dch -i and write a changelog file | |
| <welshbyte> -i increments the version, right? | |
| <LaserJock> yep | |
| <LaserJock> there are a few different options, but I generally use -i | |
| <cstudent> from inside the deb directory? | |
| <LaserJock> yes | |
| <LaserJock> mine looks like: | |
| <LaserJock> plotdrop (0.5-0ubuntu2) dapper; urgency=low | |
| <LaserJock> * Blah blah blah | |
| <LaserJock> -- Jordan Mantha <mantha@ubuntu.com> Thu, 10 Aug 2006 18:54:14 -0700 | |
| <LaserJock> notice that the version is now ubuntu2 | |
| <micahcowan> Is there an env var that sets your email address? | |
| <LaserJock> yeah | |
| <LaserJock> DEBEMAIL | |
| <LaserJock> and DEBFULLNAME | |
| <LaserJock> so you can set those in .bashrc or your equivalent | |
| <cstudent> I have those set, but it didn't pick it up | |
| <LaserJock> hmm | |
| <micahcowan> cstudent, are they exported? | |
| <cstudent> i believe so | |
| <yoshiznit123> echo $DEBEMAIL | |
| <LaserJock> it should work | |
| <micahcowan> better yet, env | grep DEBEMAIL | |
| <poningru> regarding the email | |
| <poningru> should I set something that I know will last? | |
| <LaserJock> well, it isn't a big deal if it changes | |
| <poningru> hmm ok | |
| <LaserJock> but what is important, if you want to get it uploaded, is that the email address is the same that you use for your gpg | |
| <poningru> oh hmm | |
| <LaserJock> so I switched email when I became an Ubuntu member and got the @ubuntu address | |
| <LaserJock> so all I did was added that address to my gpg key | |
| <LaserJock> ok so lets go up a dir | |
| <LaserJock> ../ | |
| <LaserJock> and now we are ready to build the new source package (with the new changelog entry ;-) ) | |
| <LaserJock> you can used dpkg-buildpackage -S -rfakeroot | |
| <LaserJock> or more compactly | |
| <LaserJock> debuild -S | |
| <cstudent> as root? | |
| <LaserJock> no | |
| <LaserJock> basically you should never use sudo when dealing with a source package | |
| <LaserJock> ok, so what debuild -S is doing is: | |
| <LaserJock> running the clean rule to make sure the source dir is cleaned up | |
| <micahcowan> dpatch wasn't on the list of requisite packages. | |
| <LaserJock> creating a diff.gz that represents the changes we've made to the .orig.tar.gz | |
| <LaserJock> micahcowan: doh, sorry | |
| <LaserJock> yeah, install dpatch | |
| <LaserJock> as the clean rule uses it | |
| <yoshiznit123> and i got a fatal error about not having gpg or pgp...? | |
| <LaserJock> right | |
| <poningru> us uc | |
| <LaserJock> yoshiznit123: use debuild -S -us -uc | |
| <LaserJock> after it builds the source package, it digitally signs it | |
| <LaserJock> if you don't have a gpg key set up it will complain :-) | |
| <tomveens> that worked! | |
| <poningru> woah thats so cool | |
| <LaserJock> but -us -uc tells it to not sign anything | |
| <yoshiznit123> do you need a gpg key to become a motu? | |
| <LaserJock> yoshiznit123: | |
| <cstudent> cool. mine got signed :) | |
| <LaserJock> yes | |
| <LaserJock> the digital signiture is what lets users of Ubuntu know that people are messing around with their system | |
| <tomveens> where do you get a gpg? | |
| <yoshiznit123> ok | |
| <poningru> !gpg | |
| <poningru> err | |
| <tomveens> no bot? | |
| <LaserJock> just a sec | |
| <cstudent> http://subkeys.pgp.net/ | |
| <poningru> https://help.ubuntu.com/community/GnuPrivacyGuardHowto | |
| <LaserJock> https://help.ubuntu.com/community/GnuPrivacyGuardHowto | |
| <LaserJock> ah stink, he beat me to it ;-) | |
| <LaserJock> ok anyway | |
| <poningru> :) | |
| <LaserJock> you eventually want to get a gpg key | |
| <LaserJock> because that is how we keep track of people | |
| <LaserJock> remember, when you build a package, you are installing apps on thousands of people's computers and they are allowing you root access | |
| <LaserJock> that is not something to take lightly | |
| <LaserJock> ok so now lets go up a dir again | |
| <LaserJock> now you will see a new source package | |
| <LaserJock> now that is what we would want to give to MOTU's to look at | |
| <LaserJock> .debs do us no good | |
| <poningru> you mean for r? | |
| <poningru> err review | |
| <LaserJock> well, period | |
| <poningru> oh | |
| <LaserJock> we can't upload .debs | |
| <LaserJock> we can't review | |
| <LaserJock> we can't test | |
| <LaserJock> because we need to see "how" the package is built | |
| <yoshiznit123> by source package, you mean the .dsc and the .diff.gz? | |
| <LaserJock> not just that you got a .deb and it didn't eat your system :-) | |
| <LaserJock> yoshiznit123: that and the .orig.tar.gz | |
| <poningru> hmm ic | |
| <LaserJock> those 3 files together are the source package | |
| <yoshiznit123> why do you need the .orig.tar.gz again? | |
| <LaserJock> ok, one thing I forgot to mention that debuild -S did was it runs litian | |
| <yoshiznit123> sorry, go on :-) | |
| <LaserJock> yoshiznit123: because the .diff.gz only holds the diff to the .orig.tar.gz, you have to have the original to make it complete | |
| <LaserJock> lintian is a cool program that checks source packages (and binaries) for common mistakes | |
| <LaserJock> run lintian -i plotdrop_0.5-0ubuntu2.dsc | |
| <LaserJock> we see that we have a couple warnings | |
| <LaserJock> both of which concern NMUs | |
| <LaserJock> which stands for Non Maintainer Upload | |
| <LaserJock> and is specific to Debian | |
| <LaserJock> so we can ignore it here | |
| <LaserJock> ok, so now we want to build the .deb so we can see the final product | |
| <LaserJock> this is where pbuilder comes in | |
| <LaserJock> pbuilder is a program that creates a chroot environment that is a minimal Ubuntu install | |
| <LaserJock> in fact it has the same packages as what the Ubuntu build machines have | |
| <LaserJock> so if a source package builds in a pbuilder, it should also build on the Ubuntu build machines | |
| <LaserJock> it also is a good way to check to make sure your dependencies are correct | |
| <tomveens> cool | |
| <poningru> woah | |
| <LaserJock> because it starts with almost nothing | |
| <LaserJock> so it has to grab all the dependecies | |
| <LaserJock> now obviously this will take more time and hard drive space | |
| <LaserJock> but it is really worth it | |
| <LaserJock> because it keeps your working area clean and you can be sure it will build on the build machines | |
| <LaserJock> also, it allows you to build .debs for other releases | |
| <LaserJock> for instance, I have a pbuilder set up for edgy, dapper, breezy, Debian unstable, and Debian stable | |
| <yoshiznit123> haha wow | |
| <LaserJock> so I can build .debs for all of those from my one machine | |
| <poningru> woah | |
| <LaserJock> ok, so if you followed https://wiki.ubuntu.com/MOTU/School/PackagingBasics I showed how to create a pbuilder | |
| <LaserJock> now if you want to build the .deb run sudo pbuilder build plotdrop_0.5-0ubuntu2.dsc | |
| <LaserJock> and it will go through and unpack the chroot environment and build the .deb inside of it | |
| <LaserJock> and spit out the resulting .deb to /var/cache/pbuilder/result | |
| <LaserJock> any questions? | |
| <yoshiznit123> does this need to be as root or can it be fakeroot? | |
| <LaserJock> I think you need to use root on this one | |
| <cstudent> to clean pbuilder back to original state you run sudo pbuilder clean? | |
| <LaserJock> nope | |
| <LaserJock> it does that automatically | |
| <LaserJock> at the end of the build | |
| <tomveens> when you transform the source to binarie, in what step is this done? | |
| <tomveens> pbuilder? | |
| <LaserJock> yes | |
| <cstudent> when would you use pbuilder clean? | |
| <yoshiznit123> so each time you build, it downloads all of the build dependencies? | |
| <tomveens> so it's a full full program, because it's now downloading dependencies! | |
| <LaserJock> yes | |
| <LaserJock> but it has an apt-cache | |
| <LaserJock> outside the chroot | |
| <yoshiznit123> phew* :-) | |
| <LaserJock> hehe, yeah | |
| <LaserJock> now, if you didn't want to use pbuilder you could run debuild instead of debuild -S in the source dir | |
| <LaserJock> but you have to have all the build dependencies installed | |
| <LaserJock> and it can be a little messy | |
| <LaserJock> so it is recommended to use pbuilder | |
| <LaserJock> ok, so anybody get a .deb out of that? | |
| <cstudent> not yet | |
| <micahcowan> yup | |
| <Jucato> not yet... | |
| <tomveens> I have got a base.tgz? | |
| <poningru> sure | |
| <LaserJock> if you built a pbuilder beforehand you should | |
| <poningru> query | |
| <Jucato> question about creating a pbuilder: could I create pbuilder using "--distribution dapper" instead of edgy? | |
| <poningru> how do you change the puilder env? | |
| <poningru> err pbuilder env | |
| <LaserJock> Jucato: you will want to use edgy if you plan on getting the package into Ubuntu, dapper is already released so we are only doing security updates, etc. | |
| <LaserJock> but you could make a dapper pbuilder to do backports | |
| <poningru> as in is there any other way to do it apart from the original setup? | |
| <Jucato> oh ok... just asking if it was possible :-D | |
| <LaserJock> you can modify /etc/pbuilderrc | |
| <LaserJock> sure, you can do breezy, hoary, warty even ;-) | |
| <welshbyte> or ~/.pbuilderrc? | |
| <LaserJock> yeah | |
| <LaserJock> or whatever file you want to if you give it --config-file | |
| <poningru> so just change the DISTRIBUTION? | |
| * welshbyte nods | |
| <LaserJock> yes | |
| <LaserJock> and then run pbuilder update --override-config | |
| <poningru> oh | |
| <LaserJock> --override-config is used when you need update the chroot's apt | |
| <Jucato> rawr! I should have created a pbuilder before hand... :-( (not doing my homework...) | |
| <LaserJock> that's ok | |
| * micahcowan 's DISTRIBUTION says dapper... | |
| <LaserJock> lets assume we built the .deb :-) | |
| <LaserJock> micahcowan: did you build a dapper builder? | |
| <micahcowan> I ran the command on the wiki... | |
| <micahcowan> I didn't specifically build a dapper builder... | |
| <poningru> what'd you put for <distro>? | |
| <LaserJock> pbuilder create --distribution edgy | |
| <micahcowan> yes | |
| <Jucato> LaserJock: last question about pbuilder: do we need to do "pbuilder create" everytime we're building a .deb, or just once per distribution? | |
| <LaserJock> ok, lets move on, you can troubleshoot pbuilder in #ubuntu-motu when we're done | |
| <LaserJock> Jucato: just once to create the environment | |
| *** Susana_ is now known as Susana | |
| <Jucato> oh ok thanks! moving on... | |
| <LaserJock> ok, if you didn't get the .deb to build grab it from http://packages.ubuntu.com/dapper/math/plotdrop | |
| <LaserJock> now you can also run lintian on the .deb if you like | |
| <LaserJock> ok, the biggest thing to do with the .deb is to make sure that the files are going where you want them to and that it installs ok | |
| <LaserJock> to check what files are being installed | |
| <LaserJock> us dpkg -c | |
| <LaserJock> use | |
| <LaserJock> then use dpkg -i to install the .deb | |
| <LaserJock> now if you are creating a .deb for edgy but you are running dapper, then it becomes hard to test | |
| <LaserJock> so I usually set up a chroot | |
| <LaserJock> you can use dchroot | |
| <LaserJock> https://wiki.ubuntu.com/DebootstrapChroot has info on how to set this up | |
| <LaserJock> that way you keep your working install clean | |
| <LaserJock> and you can run edgy on dapper | |
| <LaserJock> ok, so this has gone almost 2 hrs | |
| <LaserJock> so I'd like to wrap up a bit | |
| <LaserJock> if you want to learn more: | |
| <LaserJock> the Ubuntu Packaging Guide is a good resource | |
| <LaserJock> you can find it in System -> Help -> System Documentation on your dapper box | |
| <LaserJock> or at help.ubuntu.com | |
| <LaserJock> also check out http://www.debian.org/devel/ | |
| <LaserJock> there you will find the Debian Policy | |
| <LaserJock> New Maintainer's Guide | |
| <LaserJock> and other Policy docs, like Emacs Policy, Python Policy, etc. | |
| <LaserJock> If you want to help contribute to Ubuntu packaging (bug fixes, new packages, etc.) | |
| <LaserJock> but dont' know where to start | |
| <LaserJock> I would recommend the MOTU Mentors program | |
| <LaserJock> http://wiki.ubuntu.com/MOTU/Mentors | |
| <LaserJock> and packaging questions are always welcome at #ubuntu-motu | |
| <LaserJock> so with that I'd like to open it up for any last questions | |
| <nixternal> good job LaserJock!!! can you repeat everything you just said? | |
| <nixternal> ;) | |
| <Jucato> lol | |
| <LaserJock> in 16 hrs ;-) | |
| <nixternal> thanks alot for this class, i actually learned some stuff ;) | |
| <tomveens> thanks | |
| <LaserJock> or 14 rather | |
| <yoshiznit123> yup thanks alot :-) | |
| <cstudent> yes, this was excellent | |
| <tomveens> teach more! Great help! | |
| <Jucato> thanks!!! | |
| <Jucato> (my pbuilder still isn't done... :-() | |
| <Kilz> There is a repete of this class? | |
| <LaserJock> and remember, we will be doing more MOTU sessions, so keep an eye out | |
| <LaserJock> Kilz: yeah, I'm going to try to do it again at 17:00 UTC | |
| <yoshiznit123> question: i'm writing my own small program, is there a way i can make it easier for the devs to include into the repository? | |
| <Kilz> ty, i mised the first 20 mins | |
| <LaserJock> for the Europeans ;-) | |
| * jsgotangco starts using Laser pointer at LaserJock | |
| <Jucato> rofl | |
| <welshbyte> LaserJock: that was great, thanks a lot :) | |
| <cstudent> yeah! my deb got built | |
| <LaserJock> yoshiznit123: yes, make your licensing clear and make sure you don't hard code anything more than necessary | |
| <yoshiznit123> should i add the debian dir, build source packages, and all that? or can i just say, here's my tarball, can you include it? | |
| <LaserJock> because we actually install into <source dir>/debian/<packagename> it can sometimes get nasty if the author has hard coded something | |
| <tomveens> where should the .deb after the pbuilder be? | |
| <LaserJock> yoshiznit123: no, in fact it is better to seperate the debian/ from the tarball | |
| <LaserJock> tomveens: /var/cache/pbulder/result | |
| <cstudent> /var/cache/pbuilder/result | |
| <yoshiznit123> ok | |
| <tomveens> thnx | |
| <LaserJock> yoshiznit123: but that doesn't mean you can't do the packaging | |
| <LaserJock> yoshiznit123: it's great when the software authors also have an idea of what it takes to package | |
| <LaserJock> so go for it!!!! | |
| <tomveens> it worked, thanks! | |
| <welshbyte> i'm thinking of .deb packaging my housemate's SoC project from last year which is a python/glade app... are there python package specifics i need to know? | |
| <LaserJock> welshbyte: look over the Python Policy carefully | |
| <welshbyte> ok | |
| <LaserJock> things have changed recently so if you read outdated stuff you might get a little stuck | |
| <welshbyte> great :) | |
| <LaserJock> and if you have problems as -motu | |
| <LaserJock> OH, ONE LAST THING! | |
| <LaserJock> sorry for the shouting | |
| <LaserJock> ;-) | |
| * poningru awaits | |
| <Jucato> :-D | |
| <LaserJock> If you want to actually get a package into Ubuntu Universe, the MOTU use a review system called REVU | |
| <LaserJock> it's a server where you can upload your source package | |
| <LaserJock> and we can make comments and approve your package | |
| <poningru> hmm | |
| <welshbyte> cool | |
| <LaserJock> if you get 2 votes then the package can get uploaded | |
| <LaserJock> the server is revu.tauware.de | |
| <poningru> who runs that? | |
| <LaserJock> and info on it is at http://wiki.ubuntu.com/REVU | |
| <LaserJock> it's a Canoncial sponsored machine | |
| <poningru> ah ok | |
| <LaserJock> that is run by the MOTU | |
| <LaserJock> and the REVU system was written in Python by the MOTU | |
| <LaserJock> specifically siretart and sistpoty | |
| <LaserJock> anyway, I hope you guys have enough to get going on | |
| <jsgotangco> 2 hours wow | |
| <LaserJock> and I'll close the session now | |
| <poningru> time flies when you are having fun | |
| <cstudent> thanks again LaserJock | |
| <LaserJock> ;-) | |
| <poningru> thanks dude | |
| <tomveens> really helpfull | |
| <yoshiznit123> thanks | |
| <Jucato> thank you! | |
| <micahcowan> thanks, LaserJock | |
| <tomveens> My First Deb! :) | |
| <LaserJock> thanks for coming, I hope you put it to good use, I look forward to review some packages ;-) | |
| <cstudent> good nite all | |
| <poningru> night | |
| <poningru> whens the next one? | |
| <poningru> friday at 1300UTC? | |
| <bddebian> Nice LaserJock, good work :-) | |
| <poningru> or 0100? | |
| <LaserJock> 1700UTC | |
| * Jucato claps for LaserJock | |
| <poningru> oh | |
| <poningru> can you put that in the topic por favor? | |
| <poningru> err fix | |
| <LaserJock> poningru: actually, I don't know that I can, I think I need ops | |
| <poningru> oh wait I can do it | |
| *** poningru changes topic to "- read more about it on http://wiki.ubuntu.com/MOTU/School -- Next lesson: "Packaging Basics" Friday 17:00 UTC" | |
| <poningru> its not +t | |
| <poningru> so anyone can do it | |
| <poningru> and it is tommorow | |
| <LaserJock> ah, thanks | |
| <poningru> right? | |
| <Jucato> better just put the exact date rather than the day | |
| *** poningru changes topic to "- read more about it on http://wiki.ubuntu.com/MOTU/School -- Next lesson: "Packaging Basics" 20060811 17:00 UTC" | |
| <poningru> err is that format ok? | |
| <Jucato> Aug 11, 2006 ? | |
| *** poningru changes topic to "- read more about it on http://wiki.ubuntu.com/MOTU/School -- Next lesson: "Packaging Basics" Aug 11, 200617:00 UTC" | |
| *** poningru changes topic to "- read more about it on http://wiki.ubuntu.com/MOTU/School -- Next lesson: "Packaging Basics" Aug 11, 2006 17:00 UTC" | |
| <Jucato> I think that's better | |
| <LaserJock> hmm, did anybody come from the forums? | |
| <Jucato> LaserJock: ubuntuforums.org? | |
| <LaserJock> yeah | |
| <LaserJock> I put a sticky up on the devel subforum | |
| <LaserJock> I was hoping some people would show | |
| <Jucato> I did | |
| <Jucato> but | |
| <Jucato> I got my info from Planet Ubuntu :-D | |
| <LaserJock> ah | |
| <LaserJock> cool | |
| <Jucato> I think cstudent (he's gone) is also from the forums. I see him around | |
| <Jucato> Oh, I see your sticky. :D | |
| <LaserJock> cool | |
| * poningru got it from when you just announced it on irc somewhere | |
| <LaserJock> it was sort of a test | |
| <poningru> also couple of things for whoever is doing it tommorow | |
| <poningru> can we have ubotu in here? | |
| <LaserJock> I'd like to place a permanent MOTU School sticky on the forums | |
| <poningru> and can the teacher/another person have ops just incase | |
| <LaserJock> ask Seveas, we haven't used the channel for a while | |
| <poningru> hmm k | |
| <LaserJock> yeah | |
| <poningru> cafuego owns him so I think I will go ping him as well | |
| <Jucato> yay! pbuilder is downloading packages... | |
| <LaserJock> :-) | |
| *** zul_ is now known as zul | |
| <Jucato> err... next step.. setting up chroot | |
| <poningru> it does it for you | |
| <nixternal> gpg: skipped "Richard A. Johnson <nixternal@ubuntu.com>": secret key not available | |
| <LaserJock> tsk tsk | |
| <nixternal> debuild -S | |
| <nixternal> but... | |
| <Jucato> poningru: no, to test it with dpkg -c | |
| <poningru> ah gotcha | |
| <LaserJock> Jucato: you can do dpkg -c on the deb | |
| <nixternal> dpkg-buildpackage -S -sa -rfakeroot -k2E2C0124 | |
| <nixternal> that works | |
| <LaserJock> yeah | |
| <LaserJock> some people get that | |
| <LaserJock> I haven't figured out what the problem is | |
| <LaserJock> gpg has *always* worked fine for me | |
| <LaserJock> but some people have to always use -k | |
| <Jucato> LaserJock: if I do dpkg -c on the deb, I don't need to setup chroot? | |
| <nixternal> i need to build a pbuild env on this machine | |
| <LaserJock> Jucato: no | |
| <Jucato> oh cool :-D | |
| <LaserJock> Jucato: you would need it if you wanted to actually install it | |
| <LaserJock> and even then you don't *have* to | |
| <LaserJock> it's just cleaner | |
| <LaserJock> and healthier for your system | |
| <micahcowan> you'd probably have to if it's a different release... | |
| <Jucato> but I'm running Dapper, and the build is for Edgy... | |
| <micahcowan> (for example, I couldn't install my .deb, since I'm running dapper and didn't have chroot) | |
| <Jucato> the pbuilder I made was for Edgy, I mean | |
| <micahcowan> yeah, what Jucato said., | |
| <Jucato> :-D | |
| <LaserJock> right | |
| <LaserJock> that's the other case when a chroot is nice | |
| <LaserJock> so I can more or less be running dapper | |
| <LaserJock> and then jump into a edgy chroot | |
| <LaserJock> or a Debian unstable | |
| <LaserJock> and run anything I want | |
| <Jucato> ehehe | |
| <LaserJock> in the past I've installed ubuntu-desktop in a chroot | |
| <Jucato> @_@ | |
| <LaserJock> and pretty much had a fully working Edgy install | |
| <LaserJock> running in dapper | |
| <LaserJock> it's a little more complicated than just that | |
| <LaserJock> you can't test kernels | |
| <LaserJock> but it works pretty well | |
| <Jucato> cool | |
| <Jucato> er gotta go. I'm starving!! (almost lunch time over here) | |
| <Jucato> LaserJock: thanks again!! | |
| <Jucato> I'm now one step closer to world domination!! | |
| <Jucato> rofl | |
| <LaserJock> hehe | |
| <LaserJock> thanks for coming Jucato | |
| <poningru> Jucato: bye dude | |
| <jsgotangco> the world is bigger than you think ;) | |
| <Jucato> bye poningru! | |
| <Jucato> hehe! I just said one step.. I need more than a billion! :-D | |
| <Knightlust> ha! ha! im back | |
| <Knightlust> oop, sorry | |
| <Knightlust> too bad, it's done, will | |
| <otep> help | |
| <otep> shess | |
| <otep> wrong window | |
| *** sick is now known as tensor | |
| * Akane`Mahoru is away: miam | |
| <Akane`Mahoru> ittadakimasu | |
| <kmilo> Hi | |
| <ranf> hi | |
| <oly> has it started / have i missed much | |
| <oly> hello ? | |
| <kmilo> oly, 17:00 UTC | |
| <oly> i thought that was now | |
| <oly> gmt is same as utc is it not | |
| <llutz> oly: daylight savings | |
| <oly> oh is it in 30 mins then :p | |
| <kmilo> oly, in https://wiki.ubuntu.com/MOTU/School is a link to see the UTC hour http://www.timeanddate.com/worldclock/fixedtime.html?year=2006&month=8&day=11&hour=17&min=0&sec=0 | |
| <oly> yeah i did not think about daylight saving :p | |
| <oly> i thought i was gona miss it because of traffic | |
| <oly> oh damn :p | |
| <oly> an hour ahead | |
| <oly> oh well go see if i can find the log | |
| <axisys> i like date -u | |
| <axisys> it tells me whats the utc time.. | |
| <oly> aha thats a neat one :p | |
| <oly> well i was stuck in traffic at that time anyway | |
| <kmilo> axisys, Cool :) 16:27:42 UTC 2006 | |
| <axisys> kmilo: yeap | |
| <llutz> Fr 11 Aug 16:41:35 UTC 2006 | |
| <oly> has the log been posted any where yet ? | |
| <kmilo> oly, AFAIK no | |
| <oly> okay | |
| <LaserJock> no | |
| <LaserJock> because I wanted to wait until both sessions were done | |
| <oly> okay is the second session not done then now ? | |
| <LaserJock> no, it starts in about 15 min | |
| <oly> oh right, thats just confusing timezones are confusing | |
| <LaserJock> yeah | |
| <oly> but great as a thought i had missed it completely | |
| <oly> by 2 hours :p | |
| <oly> daylight saving does not help over here | |
| <LaserJock> yeah | |
| <LaserJock> well, I've gotten used to being UTC-7 | |
| <oly> well i know gmt and utc are basically the same, just forgot about daylight saving | |
| <matid> Hi everyone | |
| <oly> hi matid, | |
| <redguy> hi | |
| <Amaranth> 9 minutes | |
| <redguy> darn, I won't have my pbuilder prepared in time | |
| <matid> redguy: I created my pbuilder environment few hours ago to avoid this problem ;) | |
| <LaserJock> it's ok if you don't have one | |
| <LaserJock> we'll work around it | |
| <oly> what is the pbuild enviroment, is it just for packaging ? | |
| <Amaranth> oly: it's a chroot for building packages | |
| <oly> okay just had not come accross it till now | |
| <redguy> yeah, is there a difference between pbuilder and a regular chroot? | |
| <Amaranth> oly: mostly used so you know you have the right build-depends | |
| <Amaranth> redguy: pbuilder does all the work for you | |
| <LaserJock> Amaranth: don't be spilling the beans too much ;-) | |
| <Amaranth> the "keeping the chroot clean" work | |
| <Chons> good evening | |
| <Amaranth> LaserJock: I'll be the kid of the back correcting the teacher. ;) | |
| <Amaranth> err, in the back | |
| <LaserJock> Amaranth: please do | |
| <seaLne> Amaranth: the annoying kid at the back? :P | |
| <ubuntu_demon> hi | |
| <matid> seaLne: Yes, that one ;) | |
| <Amaranth> yay for cable, i might get my pbuilder setup before we start needing it | |
| <LaserJock> ubuntu_demon: heah, you mad it! | |
| <LaserJock> *made | |
| <ubuntu_demon> I made it :) | |
| <Amaranth> it's the one things i forget after a reinstall | |
| <Amaranth> ubuntu_demon: :) | |
| <oly> i set mine up on two laptops this morning before i had to drive :p | |
| <oly> so i have a backup | |
| <LaserJock> Ok, lets get quieted down so we can start | |
| <ubuntu_demon> Can you provide us with a list of packages to install ? | |
| <axisys> hmm.. can i make the pbuilder now :P ? | |
| <matid> ubuntu_demon: https://wiki.ubuntu.com/MOTU/School/PackagingBasics | |
| <LaserJock> ubuntu_demon: it's on http://wiki.ubuntu.com/MOTU/School/PackagingBasics | |
| <matid> ;) | |
| <ubuntu_demon> thanks | |
| <ubuntu_demon> I had no time yet to look it up ;) | |
| <Amaranth> LaserJock: I got lots of forums people here. :) | |
| <adamant1988> shameless advertising Amaranth | |
| <gapz> hello ! | |
| <yuriy> hmm i'll brb with edgy | |
| * quidam- Buon giorno tutto | |
| <LaserJock> OK, how many people from the forums today? | |
| <quidam-> LaserJock, :-D | |
| <ubuntu_demon> I'm from the forums :-p | |
| <axisys> just installed pbuilder.. sudo apt-get install pbuilder | |
| <oly> well i am on the forum | |
| <byen> I am too | |
| <ubuntu_demon> I suppose we need a working Edgy chroot ? (currently upgrading it) | |
| * FLeiXiuS used to be from the forums ;-) | |
| <heras> me too | |
| <ubuntu_demon> hey FLeiXiuS :) | |
| <byen> btw hello ubuntu_demon never seen you on irc... | |
| * axisys just installed pbuilder | |
| <FLeiXiuS> Hey ubuntu_demon long time! | |
| <LaserJock> ok, ok, we need it quiet | |
| <ubuntu_demon> FLeiXiuS: long time no see indeed :) | |
| <ubuntu_demon> byen: I'm not that much online at irc :) | |
| <matid> LaserJock: Is it ok to ask questions during your talk or do you prefer them to be asked after you finish? | |
| <ubuntu_demon> I was present at UDS though :-D | |
| <ubuntu_demon> or PM you during your talk ? instead of typing it here ? | |
| <LaserJock> matid: I'll ask for questions | |
| <LaserJock> ok, let's get started | |
| <LaserJock> Welcome to the MOTU School. These sessions are presented by the Universe development community (MOTU) as a way of helping Ubuntu users to get involved with Ubuntu development. See http://wiki.ubuntu.com/MOTU for more info. | |
| <ubuntu_demon> ok :) | |
| <LaserJock> Today what I will be presenting is not in any way a comprehensive reference to packaging. What I want you to get out of this is some understanding of the tools and techniques that people use to make and maintain source packages. | |
| <LaserJock> First of all, we need to know what a source package is | |
| <LaserJock> A source package is actually made up of 3 different files: | |
| <LaserJock> 1) .dsc (description) file that holds md5sums of the other files | |
| <LaserJock> 2) .orig.tar.gz which is the source tarball as you would download it from the program's homepage | |
| <LaserJock> 3) .diff.gz that holds any changes we make to the .orig.tar.gz | |
| <LaserJock> ok, now today we are going to look at a particular source package, plotdrop | |
| <LaserJock> it's a fairly easy package, and was my first package from scratch | |
| <LaserJock> Ok, for our first package (plotdrop) let's make a temp directory where we can work in: | |
| <LaserJock> mkdir -p ~/motuschool/plotdrop | |
| <LaserJock> cd ~/motuschool/plotdrop | |
| <LaserJock> apt-get source plotdrop | |
| <LaserJock> Note 1: you need to have the source repo's (deb-src) enabled in your /etc/apt/sources.list | |
| <LaserJock> Note 2: unlike apt-get install, you should not run apt-get source via sudo | |
| <ranf> done | |
| <LaserJock> OK, now you have 3 files (the source package) and a directory (which is the unpacked source package) | |
| <LaserJock> lets have a look around: | |
| <LaserJock> ls plotdrop-0.5/ | |
| <LaserJock> and we see that this a small C program with typical files (COPYING, Makefile, Changelog, etc.) | |
| <LaserJock> in fact, if we were to extract the tarball from the plotdrop homepage the only difference we would find is that debian directory | |
| <LaserJock> if you want you can look at the diff to the source tarball by: | |
| <LaserJock> zless plotdrop_0.5-0ubuntu1.diff.gz | |
| <LaserJock> OK, questions so far? | |
| <ubuntu_demon> one question | |
| <ubuntu_demon> the diff is between upstream and ubuntu ? or between debian and ubuntu ? | |
| <LaserJock> between upstream (what you get from the app's homepage) and Ubuntu | |
| <ubuntu_demon> great thnx | |
| <LaserJock> or between upstream and Debian if you are packaging from debian | |
| <Amaranth> (which includes changes from debian if we got the package from them) | |
| <LaserJock> right | |
| <ubuntu_demon> I understand. | |
| <LaserJock> Now, lets actually dig into that debian/ directory and see what's going on: | |
| <LaserJock> cd plotdrop-0.5/debian/ | |
| <LaserJock> ls | |
| <LaserJock> We see several files and a patches directory. All of the packaging info and patches to the source need to produce a good quality .deb are in here | |
| <LaserJock> What we need to do know is go through what the files are for. Lets start with changelog | |
| <LaserJock> less changelog | |
| <LaserJock> What we need to do know is go through what the files are for. Lets start with changelog | |
| <LaserJock> less changelog | |
| <LaserJock> yikes, sorry about that | |
| <LaserJock> The first thing to note is that the format of the changelog is particular. dch is a program (found in the devscripts packages) that helps you with the formating. | |
| <LaserJock> One the first line you will find the package name, version, and release. Each time a new source package is uploaded to the Ubuntu build machines it should have a higher version than the previous one. | |
| <LaserJock> The version goes like this: <programversion>-<debianrevision>ubuntu<bunturevision> | |
| <LaserJock> In this case the program's version is 0.5, the Debian revision is 0 because at the time it wasn't in Debian, and the Ubuntu revision is 1 | |
| <LaserJock> anybody have questions about versioning? | |
| <FLeiXiuS> It's not automated by DCH right? | |
| <redguy> what happens whe a package get included in debian? | |
| <gnube> LaserJock, that is a typo there correct? => ubuntu<bunturevision> | |
| <neutrinomass> LaserJock: The current kdeadmin source package version is "4:3.5.4-0ubuntu2 " . What does the '4:' mean ? | |
| <LaserJock> FLeiXiuS: dch creates a template | |
| <ubuntu_demon> I assume you are you going to tell us more about dch later. So no questions for me. | |
| <LaserJock> redguy: the debian revision goes to 1 as in 0.5-1 | |
| <matid> LaserJock: Is it possible to append to a current changelog with dch? | |
| <LaserJock> gnube: that's correct | |
| <LaserJock> matid: yes | |
| <LaserJock> neutrinomass: that is called an epoch, it's for more complicated versioning | |
| <neutrinomass> LaserJock: Ok, I'll google for it :-) Thanks | |
| <LaserJock> neutrinomass: better than google would be to check out the Debian Policy | |
| <Amaranth> If the upstream version goes down instead of up for some reason you have to add an epoch | |
| <Amaranth> That's the only use for it that I know of. | |
| <LaserJock> http://www.debian.org/devel/ has lots of good stuff | |
| <redguy> so when a package gets included in debian, the ubuntu maintainer is supposed to increase the debian version even if he hasn't done any changes to the package? | |
| <LaserJock> redguy: no | |
| <matid> LaserJock: Do we have it in Ubuntu? | |
| <LaserJock> matid: have what? | |
| <matid> LaserJock: I mean the epochs. | |
| <LaserJock> yes | |
| *** kmilo_ is now known as kmilo | |
| <matid> LaserJock: So they aren't only 'leftovers' from Debian? | |
| <LaserJock> basically, Ubuntu follows Debian, we just add on an ubuntuX to the end if we need to change something | |
| <LaserJock> if a previous version needed to be changed, say we had 0.5-1ubuntu1 | |
| <neutrinomass> Ok, since I brought it up, here's the epoch explanation from the Debian Policy: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version | |
| <redguy> LaserJock: another situation: suppose that debian has 0.5-1, but ubuntu has a package made from 0.6 upstream. the ubuntu revision is 0.6-0ubuntu1, right? | |
| <LaserJock> but in the next Debian revision they included those changes then we could just get 0.5-2 from them | |
| <siretart> redguy: yes, thats current policy in ubuntu | |
| <LaserJock> redguy: right | |
| <Amaranth> If debian doesn't have a package with the upstream version that we do the debian version is 0 | |
| <LaserJock> yes | |
| <LaserJock> (upstream version)-(Debian revision)ubuntu(Ubuntu revision) | |
| <gnube> Are there packages in Ubuntu that aren't in debian? | |
| <redguy> ok, just wanted to make sure I got it ;-) | |
| <LaserJock> gnube: yes | |
| <LaserJock> if a package doesn't isn't in Debian then (Debian revision) = 0 | |
| <LaserJock> if the package doesn't need any changes (which is what we like) then we just keep the Debian versioning | |
| <LaserJock> we only change the version when we need to | |
| <LaserJock> ok, lets move on | |
| <LaserJock> Next we see various notes as to what was changed from one version to the next and finally a "who done it" line that shows who made the changes and at what time. | |
| <LaserJock> the things to note here are that the name and email address you use are important | |
| <LaserJock> and will be used to track who did what | |
| <LaserJock> and if you digitally sign the package you will need to make sure the email address is the same that is in your gpg key | |
| <LaserJock> but we'll get to that later | |
| <LaserJock> ok, on to the control file | |
| <LaserJock> less control | |
| <LaserJock> The control file holds a lot of information about the source package and it's resulting binary package (.deb). It is arranged in field: value form and most of the fields are fairly self-explanitory but the values are, as you will see, more difficult to determine | |
| <LaserJock> For the source package there is: | |
| <LaserJock> Source: the source package name | |
| <LaserJock> Section: what section of the repository does the program belong in | |
| <LaserJock> Priority: is the program essential for a properly running Linux system? | |
| <LaserJock> Maintainer: who is taking on the responsiblity, mostly for Debian | |
| <LaserJock> Build-Depends: the packages that must be installed for the source package to be able to build the .deb | |
| <LaserJock> Standards-Version: which version of the Debian Policy does this package adhere to | |
| <LaserJock> There are more fields available but these are found in most all packages. Check out the Debian Policy for more info: http://www.debian.org/doc/debian-policy/ch-source.html and http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles | |
| <LaserJock> note that Priority is not random, there are specific values you can have and they are explained in the Debian Policy and Ubuntu Packaging Guide | |
| <LaserJock> any questions? | |
| <gnube> An improperly formatted control file can cause problems, correct? | |
| <LaserJock> yes | |
| <Amaranth> it'll fail to build | |
| <rouzic> Hi | |
| <matid> LaserJock: That's probably the same with changelog, isn't it? | |
| <LaserJock> basically, debian-based package building is highly automated | |
| <rouzic> Hi novatillo | |
| <LaserJock> these files will be read by many scripts | |
| <LaserJock> so formatting is important | |
| <LaserJock> for them to be machine readable | |
| <gnube> But the changelog is more flexible that the control file no? | |
| <LaserJock> well, it depends | |
| <LaserJock> dch helps format the changelog | |
| <matid> gnube: Today my package failed to build because between the email and the date you need to have two spaces, not one ;) | |
| <LaserJock> but it's easier to mess up in control | |
| <gnube> I have had trouble with control files as well. | |
| <LaserJock> ok, does everybody understand what the Build-Depends line is for? | |
| <gnube> No, could you explain it again please? | |
| <gnube> Am I right in assuming it determines all the other packages that are required to build said package? | |
| <LaserJock> the Build-Depends line lists the binary packages (with version info if necessary) that are needed in order for the package to buiuld | |
| <LaserJock> yes | |
| <gnube> And there is an automated tool to determine this information? | |
| <gnube> And that is dch? | |
| <LaserJock> not dch | |
| <Amaranth> Let's say a program uses GTK, it needs to have libgtk2.0-dev in the Build-Depends in order to compile correctly | |
| <LaserJock> there are a few scripts that can give you an idea | |
| <gnube> ok | |
| <LaserJock> but you can look at the README file or the app's homepage | |
| <LaserJock> for what they list as requirements | |
| <gnube> I am in contact with the developer but he has no idea! | |
| <Amaranth> There really isn't a way to automate creation of the Build-Depends that I know of, you just have to figure out what the program needs to have installed in order to compile correctly and put those packages in the Build-Depends line | |
| <LaserJock> the developer should know what libraries, etc he needs to build his app | |
| <gnube> ok, cool. | |
| <gnube> LaserJock, He does to an extent, but it is a little hard to know. | |
| <LaserJock> yes | |
| <kmilo> LaserJock, maybe ldd ? | |
| <ubuntu_demon> what does ldd stand for ? | |
| <LaserJock> the build dependencies are one of the hardest parts to get right | |
| <gnube> I thought there was a tool that could determine automagically (through #includes or something) all the libraries needed. | |
| <LaserJock> that's why pbuilder is important because it will fail if you get the dependecies wrong | |
| <kmilo> ubuntu_demon, ldd - print shared library dependencies | |
| <matid> LaserJock: What about debuild? Will it fail? | |
| <LaserJock> plain debuild? | |
| <LaserJock> not necessarily | |
| <gnube> matid, no, debuild will work! | |
| <LaserJock> it will depend on what you have installed on your system | |
| <matid> LaserJock: That's what I thought | |
| <LaserJock> if you have all the deps on your system it will work | |
| <LaserJock> but when you go to upload it it might not | |
| <gnube> LaserJock, Yes, sorry I should have been more explicit. | |
| <matid> LaserJock: So you can build source packages with getting build-dependecies wrong, isn't it? | |
| <LaserJock> yes | |
| <gnube> When someone else tries to build the packages without the libraries, it will not work. | |
| <LaserJock> ok, moving on ... | |
| <LaserJock> For the binary package there is: | |
| <LaserJock> Package: binary package name, you can have more than 1 per source package so you need to specify | |
| <LaserJock> Architecture: what architecture the binary will build on. "any" means it should build on all archs and "all" means it doesn't have any arch dependent files (i.e. a program written in an interpreted language like python) | |
| <LaserJock> Depends: the packages that the binary package depends on | |
| <LaserJock> Description: First line holds the short description | |
| <LaserJock> this is again pretty self explainitory | |
| <LaserJock> Subsequent lines hold the long description. Be careful of the first space in each line, it is important. | |
| <LaserJock> OK, let's move on to compat real quick. The compat file just has an integer that corresponds to the version of debhelper (a package helper that we will talk about later). In this case since we had a Build-Depends on >= 4.0.0 , compat has 4 . | |
| <LaserJock> and ... | |
| <LaserJock> On to the copyright file. This file is very important to us, as a open source distro, because it holds the copyright and license information for all the files in the source package. The important things to have are: | |
| <LaserJock> 1) where you got the source tarball | |
| <LaserJock> 2) document who the source tarball copyright holder is (an include a year) | |
| <LaserJock> 3) the License under which we are allowed to distribute the code | |
| <LaserJock> For common licenses like the GPL you can put the preample and then a notice that has the location of the full copyright in /usr/share/common-licenses . If the license is *not* one of those in /usr/share/common-licenses then you will need to inclued *all* the text of the license. | |
| <LaserJock> A common mistake is for the packager to just take the word of the program's homepage for the license. The packager need to make sure that the source code has licensing information and that all the files in the source package are accounted for. People often forget artwork and documentation (which is often under a difference license than the code itself) | |
| <LaserJock> questions about copyright? | |
| <matid> What if different parts of the program we want to build are covered with different licences? | |
| <LaserJock> you list them all | |
| <LaserJock> what files belong to what license | |
| <LaserJock> and if one of the licenses isn't in the "common" list you have to include the full text | |
| <LaserJock> it's a bit tedious and seemingly unimportant | |
| <Toadstool> and you check if they're compatible when used together (example: GPL and OpenSSL licences) :) | |
| <Toadstool> (hi everybody) | |
| <LaserJock> but it is vital to Ubuntu that we are legally distributing code | |
| <LaserJock> there are thousands of packages in Debian/Ubuntu already | |
| *** carthik_zZz is now known as carthik | |
| <LaserJock> many times, people ask "why isn't XYZ in Ubuntu?" | |
| <LaserJock> and often times it is because of licensing problems | |
| <gnube> I though XYZ was under GPL? | |
| <LaserJock> XYZ = some random app | |
| <gnube> heh. sorry. | |
| <LaserJock> if you are uncertain about a license, do a search on the debian-legal mailing list archives | |
| <ubuntu_demon> Is there some recommended place to go for licensing questions ? | |
| <LaserJock> also check out the Debian Free Software Guidelines | |
| <ubuntu_demon> oops :) | |
| <LaserJock> np | |
| <LaserJock> Ubuntu doesn't have a legal team per se | |
| <ubuntu_demon> So if you still have questions you need to ask on debian-legal ? | |
| <LaserJock> we mostly rely on Debian Legal and our excellent archive admins | |
| <LaserJock> ubuntu_demon: yeah, but make sure to check the archives first, most everything has been discussed at some point | |
| <ubuntu_demon> okay clear :) | |
| <LaserJock> and it's good to encourage software authors to use a good license | |
| <LaserJock> sometimes just saying "Man, this software rocks, I'd like to get it into Ubuntu, but it can't because of the license" | |
| <LaserJock> is enough to get people to relicense | |
| <LaserJock> ok, lets move on | |
| <heras> How does this aply to backports? | |
| <LaserJock> the same as any other repo | |
| <ubuntu_demon> heras: no you don't need to change the license :) | |
| <heras> ok :) | |
| <LaserJock> backports is just taking packages from a newer release ( edgy for instance) and building it for an older release (dapper) | |
| <LaserJock> Next lets tackle the real meat of the source package, the rules file. | |
| <LaserJock> less rules | |
| <LaserJock> The rules file is a Makefile that is run by dpkg-buildpackage to build the .deb | |
| <LaserJock> I'm not going to go into a lot of detail here because we don't have time, but notice the various rules (clean, build, install, etc.) and also notice that we aren't installing relative to / but instead to $(CURDIR)/debian/plotdrop/ . This can cause a lot of problems for people at the beginning. | |
| <LaserJock> All of the dh_* are scripts that are a part of the debhelper build helper (remember we had a dependecy on that in control). Each one has a specific task (usually you can get an idea from the name) and they have good manpages so it is a good idea to man each one to see what it does. | |
| <LaserJock> One thing you will learn about packaging is that there is usually more than one way to do a task | |
| <LaserJock> Debian developers like to make scripts and automate things | |
| <LaserJock> so from debian/rules | |
| <LaserJock> *for | |
| <LaserJock> 1) we could not use and helper system at all and manually run all the commands like an ordinary Makefil | |
| <LaserJock> 2) we could use debhelper (as in this case) to provide automation of specific tasks (dh_install installes files) | |
| <LaserJock> 3) we couls use CDBS, which is an even more automatic system, and the resulting debian/rules file would only be a few lines long | |
| <LaserJock> it is generally a good thing to not use 1) because 2) and 3) work well | |
| <ubuntu_demon> using CDBS is easier than debhelper ? | |
| <LaserJock> but it is important to know what the automation in 2) and 3) are doing | |
| <LaserJock> ubuntu_demon: it can be | |
| <LaserJock> but not neccessarily | |
| <ubuntu_demon> ok. sorry for the interruption | |
| <LaserJock> some packagers avoid CDBS because it seem like a magical black box | |
| <LaserJock> but if you go through and really learn what it's doing, then it can greatly simplify debian/rules | |
| <LaserJock> I've literally seen some debian/rules files that were 1 line | |
| <ubuntu_demon> So you recommend first learning debhelper ? | |
| <LaserJock> yes | |
| <ubuntu_demon> ok thanks :) | |
| <LaserJock> because CDBS is more-or-less like automating debhelper | |
| <LaserJock> so as you learn more and more you can simplify more and more | |
| <matid> In what case it might be necessary to modify debian/rules by hand after running debhelper? | |
| <seaLne> patches | |
| <LaserJock> well, debhelper is just a collection of thos dh_* scripts | |
| <LaserJock> so for instance, dh_strip strips the debugging symbols from the binaryies | |
| <LaserJock> dh_installman installs man pages | |
| <LaserJock> dh_python adds to the postinst script items for byte compiling the code on the user's machine | |
| <LaserJock> that's why it's important to look at the man page of each one you are using | |
| <LaserJock> to 1) make sure you actually need it and 2) that you are using it correctly | |
| <matid> Ok, but dh_make creates rules file, doesn't it? | |
| <LaserJock> yes | |
| <LaserJock> a template rules file | |
| <LaserJock> dh_make is used to make a template debian/ dir | |
| <LaserJock> much of the stuff you don't need, particularlly the .ex files | |
| <matid> And that's were comes my question - when it is necessary to modify this autogenerated rules file | |
| <LaserJock> so there is a signicicant amout of scripting help (dh_make, dch, debhelper, etc.) | |
| <LaserJock> but in the end, *you* are responsible for making sure what is in debian/ is correct | |
| <LaserJock> dh_make can give a good guess and give you a template to fill out | |
| <LaserJock> but don't assume it put in all the correct answers for you ;-) | |
| <LaserJock> packaging is fairly complicated | |
| <LaserJock> but it can be learned with a little effort | |
| <oly> i am kinda getting that idea :p | |
| <LaserJock> and a little help from the MOTUs | |
| <LaserJock> once you get used to it it really isn't bad | |
| <LaserJock> there is just a lot of material to keep in mind | |
| <LaserJock> this is what makes Debian and Debian-based distros like Ubuntu so solid | |
| <matid> LaserJock: Ok, I just got confused by The Ubuntu Packaging guide. I don't recall anything about changing the rules file | |
| <LaserJock> yes, well that's a hard subject | |
| <LaserJock> because I can't just tell you a recipe for writing debian/rules | |
| <LaserJock> it's done by knowing what it takes to build the program you are packaging | |
| <LaserJock> for the most part if you program "plays nice" then the dh_make template is pretty close to the final rules file | |
| <matid> LaserJock: So we should modify it if something goes wrong ;) | |
| <LaserJock> but if you have to do a lot of tweaking to get it to build and compliy with Debian Policy then you might end up modifying it quite a bit | |
| <LaserJock> matid: yeah, and just think about what each line is doing in rules | |
| <LaserJock> for instance, do you need dh_strip if you have no binaries? | |
| <oly> can you build packages for programs that do not require building ? | |
| <redguy> what if upstream Makefile doesn't understand --prefix and installs compiled binaries into some hard-coded directory. Should the packager modify the upstream Makefile or use rules install target to install to debian/package_name? | |
| <oly> like shell scripts or javascript | |
| <LaserJock> oly: certainly | |
| <LaserJock> redguy: yes, you need to patch it | |
| <LaserJock> oly: we even package docs | |
| <LaserJock> with no code at all | |
| <oly> okay :) | |
| <LaserJock> you just leave the build: rule empty because there is nothing to build :-) | |
| <oly> all this talk on makefiles is making me think c coding thats all | |
| <LaserJock> yeah | |
| <ubuntu_demon> LaserJock: I'm sure packaging docs is very easy to do :) | |
| <oly> oh right | |
| <LaserJock> ubuntu_demon: take a look at the ubuntu-docs source package some time ;-) | |
| <ubuntu_demon> LaserJock: I will :p | |
| <ubuntu_demon> :-p | |
| <LaserJock> it's one of the more complicated packages I've seen | |
| <LaserJock> anyway, let's move on | |
| <LaserJock> ok, so we've seen most of the core of the packaging | |
| <LaserJock> if we look around we see plotdrop.1 which is a man page | |
| <LaserJock> I had to make the man page because the author didn't provide one | |
| <LaserJock> even though this is a GUI app, anything that goes in /usr/bin should have a man page | |
| <LaserJock> we see plotdrop.manpages | |
| <LaserJock> which is a file that tells dh_installman what man page to install | |
| <LaserJock> plotdrop.menu is a Debian menu file | |
| <LaserJock> Debian has it's own menu system (which Ubuntu doesn't use) but as I wanted this package to also go into Debian I added it | |
| <LaserJock> dirs is a file that has the directories that need to be created when running rules that aren't created by the program's Makefile | |
| <ubuntu_demon> LaserJock: (offtopic) Are you also a Debian maintainer then ? | |
| <LaserJock> no, I'm not | |
| <LaserJock> I have a Debian Developer that sponsors my uploads | |
| <LaserJock> he is also a MOTU so that's nice | |
| <ubuntu_demon> :) | |
| <matid> LaserJock: What about Ubuntu? Will plotdrop create a menu entry in Ubuntu? | |
| <LaserJock> the goal in Ubuntu should always be to push as much of our work upstream | |
| <LaserJock> matid: yes, it installs a .desktop file which is the freedesktop.org standard for menu files which Gnome and KDE adhere to | |
| <LaserJock> whenever you do work for Ubuntu think about whether the work is Ubuntu specific or not | |
| <matid> LaserJock: So it's possible to create a package that installs a menu entry in both debian and ubuntu, whichever it's installed in? | |
| <LaserJock> if it is not make sure to push that work on upstream (either to Debian if it is packaging, or the authors if it is bug fix code, etc.) | |
| <Gloubiboulga> (Xfce adheres to the standard too ;) ) | |
| <LaserJock> matid: well, it will actually go into both the Debian menu and the Gnome/KDE/XFCE/etc. menu | |
| <LaserJock> Gloubiboulga: thanks I couldn't remember exactly, I thought so | |
| <LaserJock> ok | |
| <LaserJock> let's look at the patches directory | |
| <LaserJock> 01_Makefile.dpatch | |
| <LaserJock> is a patch that I made to the programs Makefile | |
| <LaserJock> because it's PREFIX was hardocoded | |
| <LaserJock> and it didn't want to install to <source dir>/debian/plotdrop/ | |
| <LaserJock> what I did is rather than just modifying the Makefile and having it show up as a diff in the .diff.gz | |
| <LaserJock> I used a patch system call dpatch | |
| <LaserJock> it is called in the debian/rules file | |
| <LaserJock> and patches at build time | |
| <uel> 2/n | |
| <LaserJock> that way I can seperate patches by purpose | |
| <LaserJock> so if upstream "fixes" the problem that I need the patch for I can easily get rid of it | |
| <LaserJock> which has actually happened in this case | |
| <matid> LaserJock: Is it ok to use dpatch ever for, let's say - typos in the package's description? | |
| <LaserJock> there are a few different patch systems and ways to do patches | |
| <LaserJock> matid: it should be for things outside of debian/ | |
| <ubuntu_demon> LaserJock: why didn't you just ask for upstream to fix the manpage directly ? | |
| <LaserJock> ubuntu_demon: I did, and that was included in a later release | |
| <ubuntu_demon> LaserJock: ok | |
| <LaserJock> but in the mean time I added the patch to get the package done | |
| <LaserJock> sometimes upstreams aren't the fastest | |
| <LaserJock> :-) | |
| <ubuntu_demon> :) | |
| <LaserJock> if you want to learn more about patch systems I'll refer you to pitti's excellent MOTU School session a while back | |
| <LaserJock> you can find the transcript on the MOTU School wiki page | |
| <LaserJock> ok, now let's have some fun | |
| <LaserJock> I want all of you to create a new changlog entry | |
| <matid> LaserJock: Is it terribly wrong to create dpatch for bugs inside debian/ directory? I've recently created a debdiff for bug 55799 and I've used dpatch | |
| <LaserJock> go to the debian/ | |
| <LaserJock> matid: yeah, that's actually quite weird :-) | |
| <LaserJock> but that's ok | |
| <LaserJock> you should create a debdiff that just has the changes made | |
| <LaserJock> the patches are for patching the original source, so that it stays clean | |
| <matid> LaserJock: Ok, I'll just make sure not to do that again | |
| <LaserJock> debian/ is our domain were we get to mess around with stuff | |
| <kmilo> https://wiki.ubuntu.com/MOTU/School/PatchingSources | |
| <LaserJock> we shouldn't mess around with upstream's code unless we have a very good reason to | |
| <LaserJock> ok, so now everybody should be in debian/ | |
| <LaserJock> now run dch -i | |
| <LaserJock> it will start up you editor with a new template changelog entry at the top | |
| <matid> Great, I've been doing it manually up until now ;) | |
| <LaserJock> the thing to keep in mind is to make sure to check that the versioning is correct (it won't add the ubuntu versioning if it didn't exist already) | |
| <LaserJock> and make sure to check the release | |
| <gnube> dch: fatal error at line 323: | |
| <gnube> debian/changelog is not writable! | |
| <gnube> opps | |
| <gnube> or rather, oops. | |
| <ubuntu_demon> LaserJock: how do you change the name and e-mailadress for the template ? | |
| <LaserJock> did you run apt-get source as root | |
| <LaserJock> ubuntu_demon: you can set DEBFULLNAME and DEBEMAIL in .bashrc | |
| <ubuntu_demon> LaserJock: thnx | |
| <gnube> O, that is cool. What should DEBFULLNAME be, an avatar or real name? | |
| <LaserJock> real name | |
| <gnube> Thanks. | |
| <matid> And make sure to keep it the same as the name you have in your gpg key | |
| <LaserJock> it is important to our users that they can know *exactly* who has been touching the packages that they are installing | |
| <matid> That's a hint for those having non-english letters in their names | |
| <LaserJock> remember that when people install a package of your's they are basically letting you have root access to their machine | |
| <LaserJock> don't take that responsibility lightly | |
| <gnube> matid, So I should check with gpg first and make sure it is exactly the same? | |
| <LaserJock> matid: yes, thanks | |
| <matid> gnube: Yes | |
| <LaserJock> ok, now also make sure the release is right to | |
| <gnube> ok. | |
| <LaserJock> Edgy is the current development release | |
| <LaserJock> so you should be building package for edgy if you want it to go into Ubuntu | |
| <LaserJock> so my new changelog entry looks like: | |
| <LaserJock> plotdrop (0.5-0ubuntu2) edgy; urgency=low | |
| <LaserJock> * Blah blah blah | |
| <LaserJock> -- Jordan Mantha <mantha@ubuntu.com> Thu, 10 Aug 2006 18:54:14 -0700 | |
| <LaserJock> with a few empty lines in there ;-) | |
| <LaserJock> every body got a new changelog entry? | |
| <heras> I never use nano :'( | |
| <ubuntu_demon> I got it :) | |
| <oly> yep, | |
| <matid> heras: It should use your default editor (vim for me) | |
| <Chons> ^ stands for CTRL | |
| <LaserJock> heras: you can set EDITOR in your .bashrc or perhaps use update-alternatives to set it | |
| <heras> k, thnx :) | |
| <ubuntu_demon> matid: (offtopic) nano is mine :-p | |
| <LaserJock> ok so now go up to the source dir | |
| <LaserJock> cd .. | |
| <LaserJock> now we are going to build a new source package | |
| <LaserJock> since we made a change ;-) | |
| <LaserJock> run debuild -S | |
| <LaserJock> or if you don't have a gpg key run debuild -S -us -uc | |
| <LaserJock> and if you have a gpg key but debuild -S doesn't work use debuild -S -k<yourkeyid> | |
| <LaserJock> what this does is run the clean: rule in debian/rules | |
| <LaserJock> creates a new diff.gz with the changes you've made | |
| <LaserJock> runs lintian, which is a helper app that finds common mistakes | |
| <yuriy> make: *** No rule to make target `/usr/share/dpatch/dpatch.make'. Stop. | |
| <LaserJock> and creates the new .dsc and signs it if you have a gpg key | |
| <LaserJock> darn it, I keep forgetting that | |
| <LaserJock> you need to install dpatch | |
| <LaserJock> I forgot to include that on the list | |
| <ubuntu_demon> LaserJock: gpg is set to ubuntu-demon@ubuntu.com. But that ends up in ubuntu.demon@gmail.com so should I just use the ubuntu.demon@gmail.com address ? | |
| <L |