[00:58] <KurtKraut> I've created a shell script (http://code.google.com/p/pomamonitor/) and I want to distribute it in a .deb file. How can I learn how to create a package for Ubuntu?
[01:12] <tsimpson> !packaging | KurtKraut
[01:14] <KurtKraut> tsimpson, thanks.
[01:34] <KurtKraut> How do I specify the control file (containing dependencies, description etc.) in the dpkg --build command?
[01:39] <lfaraone> directhex: does the version of monodevelop in your PPA contain the python language bindings?
[02:50] <directhex> lfaraone, no. we haven't gotten around to it yet (it's a new package)
[02:51] <lfaraone> directhex: ah, okay. I'm not too experience with packaging of mono applications, would I be able to help?
[02:51] <directhex> lfaraone, just hasn't been done yet. would probably be a simple copypasta from monodevelop-vala's debian/ dir into the new dir, should build with little massaging
[02:51] <directhex> (at a guess)
[02:53] <lfaraone> directhex: mk.
[06:40] <eboysr> Is there a channel I can ask questions on how to make an Ubuntu package? I added some code to the gnome-control-center package, but I need to know how to compile it to test to see if my code works well.
[06:43] <randomaction> see https://wiki.ubuntu.com/Bugs/HowToFix
[06:45] <JanC> eboysr: asking here is okay, not sure how many paople are around on Saturday night (US) or Sunday morning (Europe) though  ;)
[06:45] <eboysr> lol yeah.. Here I bet most people are just pigging out on Halloween candy or something
[06:47] <eboysr> Weird how postfix gets installed along with devscripts
[06:47] <eboysr> Anyway I got it thanks randomaction and JanC
[10:24] <lars_> anybody here, who can assist me in my first steps of bugfixing ( https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825 )
[10:25] <lars_> (cute bot :) )
[10:26] <lars_> I have a fix for that, but I'm not really sure how to get it into a patch ( where to put upstart-files in debian/ ? )
[10:29] <eboyjr> lars_, https://wiki.ubuntu.com/Bugs/HowToFix I am programming a fix for something myself right now
[10:29] <eboyjr> lars_, https://wiki.ubuntu.com/PackagingGuide/PatchSystems Take a look at Example 1. too
[10:29] <lars_> oh, thanks eboyjr :) *reading*
[10:30] <eboyjr> And yeah that is a cool bot. bug 23425
[10:30] <eboyjr> i just put random numbers heh
[10:31] <lars_> :)
[10:32] <dupondje> I'm trying to find out how to debug nautilus :p
[10:32] <lars_> dupondje: sounds like biiiig fun :)
[10:33] <dupondje> want to fix some SynCE bugs :)
[10:35] <lars_> All I want is to get rid of /etc/init.d/aiccu in favour of a new /etc/init/aiccu.conf by me
[10:36] <lars_> And I cannot find any part in debian/* except a file debian/aiccu.init.d (which is never used in rules or control)
[10:37] <maxb> lars_: I'd guess you want to see 'man dh_installinit'
[10:37] <lars_> AH :)
[10:37] <lars_> thanks maxb :)
[10:40] <lars_> hmm referred in man is debian/package.init but in source is debian/package.init.d ... :) but it works, so i will delete package.init.d and put my file as package.upstart? right?
[12:41] <larsduesing> Hi :)
[12:41] <larsduesing> I uploaded a patch to https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825
[12:42] <larsduesing> being that my first patch, do I have to do anything else to get the patch sponsored by motu-team?
[13:59] <geser> larsduesing: is this also for a SRU for karmic or only for lucid? (didn't read all the bug comments?
[14:21] <larsduesing> geser: SRU?
[14:21] <larsduesing> *sorry* I'm new to all
[14:23] <geser> larsduesing: SRU = Stable Release Update, i.e. karmic-updates in the end
[14:24] <larsduesing> I think it could be SRU...
[14:24] <larsduesing> but I'm not really sure, as I don't know what impacts could be.
[14:25] <larsduesing> but people are waiting sind 2008-04-28 now for this update
[14:25] <larsduesing> since
[14:25] <larsduesing> -sind
[14:25] <larsduesing> :)
[14:26] <geser> larsduesing: your debdiff needs small corrections, the version needs to be bumped (you can't have twice 20070115-9) and the Maintainer field needs an update too
[14:26] <larsduesing> oh
[14:26] <geser> the Maintainer field can be easily updated with update-maintainer from ubuntu-dev-tools
[14:26] <larsduesing> Should I enter me as Maintainer?
[14:27] <larsduesing> (as in ubuntu only motu is as maintainer)
[14:27] <geser> and the version should be for an SRU: 20070115-9ubuntu0.1 targeting karmic-proposed (and not unstable)
[14:28] <larsduesing> ok
[14:28] <geser> the Maintainer would be Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> (if I remember the exact value correctly) but the update-maintainer script will do it for you
[14:28] <larsduesing> Resetting as: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[14:28] <geser> yep
[14:28] <larsduesing> fine
[14:29] <geser> and the upload later to lucid should be versioned 20070115-9ubuntu1 targeting lucid
[14:29] <larsduesing> aiccu (20070115-9ubuntu0.1) karmic; urgency=low
[14:29] <larsduesing> in changelog?
[14:29] <geser> s/karmic/karmic-proposed/
[14:29] <geser> but yes
[14:29] <larsduesing> aiccu (20070115-9ubuntu0.1) karmic-proposed; urgency=low
[14:30] <larsduesing> thank you :)
[14:30] <geser> and you need to get an ACK from motu-sru (just subscribe them to the bug and wait for an ACK)
[14:30] <geser> and  subscribe ubuntu-universe-sponsors to get your fix uploaded to lucid (once it's open)
[14:32] <geser> and the syntax for automatic bug close through debian/changelog is "LP: #xxx" (Closes: #xxx is used in Debian)
[14:36] <larsduesing> ok, corrected... updloading new patch :)
[14:37] <larsduesing> done. :)
[14:37] <larsduesing> thanks geser
[14:40] <larsduesing> subscribed both :)
[15:27] <Hrun> hi, i want to try some ubuntu software development, how do i get the source in such a way that i can make a diff which could be accepted?
[15:28] <Hrun> (and what is a nice small fail-proof package to start?)
[15:28] <maxb> I would advise working on packages which personally interest you is the best place to start
[15:31] <maxb> Hrun: Also, https://wiki.ubuntu.com/MOTU/Contributing is a good place to start reading stuff
[15:33] <nachiket> I need help with permissions issues when compiling a source package on Launchpad
[15:33] <Hrun> ok. i'll have a look.
[15:34] <maxb> nachiket: I may be on both channels, but others won't be, so re-state relevant facts here.
[15:35] <nachiket> Yes, certainly... I have a source package that builds fine locally on my machine.. I uploaded the package to Launchpad and the build system fails when trying to run "make install". The install step tries to copy over certain binaries into /usr/local which it is unable to do because of permissions
[15:36] <maxb> Right.... the fact that your package tries to write to /usr/*anything* directly is a bug. The build should fail for you locally too. (Unless you're running it as root, which is *very much not recommended*)
[15:36] <nachiket> I run it with sudo
[15:36] <maxb> don't
[15:36] <nachiket> Doesn't a deb install require sudo anyway?
[15:36] <joaopinto> you are not expected to install anything out of the build directory :)
[15:36] <joaopinto> nachiket, install yes, building no
[15:37] <nachiket> i dont understand...
[15:37] <nachiket> i am trying to write the compiled binaries into /usr/local/bin
[15:37] <nachiket> is that a bad pattern?
[15:38] <joaopinto> nachiket, https://wiki.ubuntu.com/PackagingGuide/Complete
[15:39] <nachiket> Thanks.. I guess I did read that guide and maybe I missed some step?
[15:39] <jdong> the guide should give you the understanding that files should be staged into $(DESTDIR)
[15:39] <joaopinto> as part of the building process you install files ate debian/tmp or debian/package-name, not on their expected target location
[15:40] <jdong> i.e. $(DESTDIR)/usr/bin
[15:41] <nachiket> I see.... But, there's no DESTDIR on that page..
[15:41] <jdong> ah they refer to it as $(CURDIR)/debian/$(package)/
[15:41] <nachiket> oh
[15:41] <nachiket> I see...
[15:41] <nachiket> ok thanks.. I think I understand..
[16:08] <nachiket> I have an unrelated question...
[16:08] <nachiket> How do I distribute a Java package as a Debian/Ubuntu deb file?
[16:09] <nachiket> Is there a similar packaging guide?
[16:11] <joaopinto> nachiket, you mean a java application ?
[16:11] <nachiket> From Java source
[16:11] <nachiket> yes
[16:15] <nachiket> I did find this -> http://pkg-java.alioth.debian.org/building.html
[16:16] <joaopinto> directhex, ping
[16:17] <joaopinto> directhex, is monodevelop expected to work out of the box :P ?
[16:20] <AnAnt> Hello, is it true that Ubuntu will by syncing from testing instead of unstable during Lucid cycle ?
[16:22] <joaopinto> AnAnt, I don't know for sure, but that is the docummented policy: https://wiki.ubuntu.com/LTS
[16:22] <AnAnt> oh, because its LTS !
[16:23] <joaopinto> it is :)
[16:29] <nachiket> any help on a packaging flow for java?
[16:33] <joaopinto> nachiket, just check the source for an existing java package
[16:33] <sebner> joaopinto: it should, why?
[16:33] <joaopinto> sebner, because it didn't, with a default VB project
[16:33] <joaopinto> it missing dependencies
[16:34] <joaopinto> it's
[16:34] <sebner> urgh
[16:34] <sebner> VB
[16:34] <sebner> ..
[16:34] <sebner> ^^
[16:34] <sebner> joaopinto: ok you better talk with directhex then
[16:35] <joaopinto> doesn't monodevelop provide an integrated gui editor ?
[16:35] <sebner> joaopinto: not for VB but GTK# (C#)
[16:35] <joaopinto> erm, the help button also crashes, I am already disapointed
[16:36] <joaopinto> ok, I thought it the gui editing would be language independent :P
[16:36] <sebner> nah
[16:37] <joaopinto> well, the Help crashes on the main window, this one is not VB specific :)
[16:38] <joaopinto> missing monodoc
[16:48] <joaopinto> argh, now the code editor complains that the file was changed outside, after using the design editor
[17:49] <iWolf> I would like to join the MOTU team
[18:56] <geser> iWolf: have you already read https://wiki.ubuntu.com/MOTU/Contributing?
[18:57] <iWolf> Ill think ill brush up on my linux skills before joining
[18:57] <iWolf> Used to linux, used Ubuntu for a while, Debian on another PC, And now going back to ubuntu
[19:12] <micahg> I wanted to run a packaging bug comment by a MOTU, is one available
[19:14] <micahg> nevermind, I'll just link to the upstream bug
[19:51] <azeem> does ubottu have a seen function?
[20:02] <Amaranth> azeem: No, that's what SeenServ is for
[20:06] <jpds> Amaranth: SeenServ is dead.
[21:53] <carresmd> Evening. Is it possible to build multiple debian packages, i.e. package, package-common, package-doc, using cdbs and distutils for python applications?
[21:58] <RAOF> carresmd: Yes, absolutely.
[21:58] <RAOF> carresmd: Just to check, you mean: "build multiple binary packages (foo, foo-common, foo-doc, foo-bar) from a single source package foo"?
[22:05] <carresmd> RAOF, correct. BUT what if a source package uses distutils (setup.py)?
[22:05] <RAOF> carresmd: Why would that make a difference?
[22:06] <RAOF> _No_ (upstream) build system does anything special for multiple binary packages.
[22:06] <RAOF> At least, none that I know of.
[22:06] <RAOF> They're all done at the packaging level, (almost always) _after_ the buildsystem has done whatever it'll do.
[22:08] <carresmd> RAOF, then how would I specify which files belong to package(-whatever)? I have to say, this is my first day trying to package something.. ^^
[22:08] <RAOF> I'd suggest looking at a multi-binary package as an example.  Let's see if I can find a simple one...
[22:09] <lifeless> RAOF: subunit
[22:09] <RAOF> lifeless: Thanks.
[22:09] <lifeless> RAOF: fairly small, but builds a lib, -dev, python module, apps package etc
[22:09] <RAOF> For some reason I can't help spelling that "subunity"
[22:09] <lifeless> and includes python
[22:10] <carresmd> I'll take a look :-)
[22:11] <RAOF> The most active ingredient is debian/*.install, which tells dh_install what files to move to which package (basically).
[22:12] <lifeless> don't forget debian/control :)
[22:13] <RAOF> Well, that too.
[22:14] <carresmd> so basically the *.install files specify what files belong to a specific package?
[22:14] <RAOF> But that declares what packages there are, wheras the install files more closely map to the actual question (how would I specify which files belong where).
[22:14] <RAOF> carresmd: Indeed.
[22:17] <carresmd> thus, cdbs (*.install files) comes in action between building and packaging right?
[22:18] <RAOF> Well... we don't use "packaging" in that sense.
[22:18] <RAOF> (We use it to describe the whole process of specifying how to turn a source tarball into one-or-more binary packages)
[22:19] <RAOF> But you're conceptually pretty much correct.
[22:19] <carresmd> is compiling > cdbs > building better?
[22:20] <RAOF> Not really, because CDBS orchestrates the compiling too. :)
[22:20] <carresmd> hmm
[22:20] <carresmd> well it doesn't matter right now ^^
[22:21] <RAOF> What's happening underneath is: CDBS implements the standard debian/rules interface (which you'll find in Debian policy, and it's worth a read).
[22:21] <RAOF> But for now, you've got an idea of what you need to do.
[22:22] <carresmd> Looking at the example package, subunit.install 'fetches' files in 'usr/bin' where 'usr/bin' is in the build directory right?
[22:23] <RAOF> For this, you'll want to read "man dh_install".
[22:25] <carresmd> Ah, that's what I needed :-)
[22:25] <RAOF> dh_install is the component that reads the *.install files and acts on them.  But, yes.  subunit.install specifies that the "usr/bin" heirachy should be copied into the the directory that the "subunit" package is being built in.
[22:26] <RAOF> You might also want to check out some of the other dh_* man pages.  Those are the utilities that CDBS calls to get the job done, and they act on various files in debian/
[22:29] <carresmd> how would I only compile the package so I can take a look in it's build/ directory?
[22:29] <carresmd> just make build?
[22:30] <RAOF> debian/rules build
[22:31] <RAOF> Would work (check out the targets that debian/rules has to have - Debian policy!).  Also, dpkg-buildpackage or debuild or your choice of package-building frontend will generally leave everything in place.
[22:31] <RAOF> Hm.  With the exception of everything moved by dh_install.
[22:40] <carresmd> RAOF, how would I set a prefix for debian/rules build? As subunit doesn't create a 'build/' dir or something alike
[22:41] <RAOF> carresmd: I'm not sure what you mean.  What are you doing, and what do you want to do?
[22:42] <carresmd> I'd like to see the files before that are split up with the debian/*.install files.
[22:43] <carresmd> So I get an idea how stuff actually works
[22:43] <carresmd> (with the subunit package)
[22:44] <RAOF> So, what _I_ would do is: unpack the subunit source (apt-get source subunit will do this for you), change to the subunit-0.0.2 directory, and run "debian/rules build".
[22:45] <carresmd> yes, done that. But they files are all scattered around in the tree.
[22:46] <RAOF> They'll all be in debian/tmp
[22:46] <carresmd> ?
[22:46] <RAOF> Oh, whoops.
[22:47] <RAOF> Sorry.
[22:48] <RAOF> debian/rules install will do a little more that you're after
[22:49] <carresmd> but it does keep debian/tmp intact as it seems :-)
[22:49] <RAOF> So, "debian/rules clean" followed by "debian/rules build" followed by "dh_auto_install" should get you into a state where everything's in debian/tmp, but before dh_install has copied or moved things around.
[22:49] <carresmd> ok
[22:49] <carresmd> I'll try
[22:51] <carresmd> that's what I was looking for.. Thanks
[22:53] <carresmd> what's ran after 'dh_auto_install'?
[22:54] <carresmd> I assume 'dh_auto_install' is part of 'dh_install' right?
[22:55] <carresmd> nevermind
[22:55] <carresmd> 'dh_install' is the script ran after 'dh_auto_install' :-)
[22:57] <DktrKranz> carresmd: this is the full sequence: http://pastebin.ubuntu.com/307050/plain/
[22:59] <lifeless> man debhelper
[23:01] <DktrKranz> err... too verbose, this is better: http://pastebin.ubuntu.com/307054/plain/
[23:05] <carresmd> thanks, that made it clear :-)
[23:06] <DktrKranz> you're welcome ;)
[23:07] <ari-tczew> when autosync will wake up to work?
[23:09] <DktrKranz> not before toolchain has landed
[23:15] <ari-tczew> so after 5th
[23:15] <ari-tczew> https://wiki.ubuntu.com/LucidReleaseSchedule
[23:18] <carresmd> RAOF, I have successfully build my very first multiple binary package (or whatever they are called).
[23:18] <ari-tczew> congratulations
[23:18] <carresmd> RAOF, Thank you for guiding me the right way! :-)
[23:18] <RAOF> No problem.
[23:20] <carresmd> I assumed it would be complicated because I was using distutils...
[23:20] <carresmd> “Assumption is the mother of the screw-up” -Angelo Donghia ^^
[23:21] <carresmd> anyway, goodnight!
[23:37] <mruiz> hi all
[23:45] <ari-tczew> hmmm is comming necessity to forward some packages into debian before DebianImportFreeze :P
[23:48] <ari-tczew> http://qa.ubuntuwire.org/multidistrotools/universe.html#outdatedinA
[23:49] <ajmitch> good to see *some* discussion about sync-from-testing for lucid
[23:49] <ajmitch> because it seems like it's surprising to quite a few people
[23:49] <geser> ari-tczew: this page need to be fixed to compare against testing instead of unstable (lucid will sync with testing and not unstable)
[23:51] <ari-tczew> ; O
[23:51] <ari-tczew> why testing in this development cycle?
[23:52] <ajmitch> because lucid is an LTS release
[23:52] <Pici> We won't be downgrading package versions though... will we?
[23:52] <ajmitch> no, we won't
[23:52] <ajmitch> because we can't
[23:52] <Pici> Just making sure.
[23:53]  * jdong loves that answer :)
[23:53] <geser> ajmitch: did we sync from testing for dapper and hardy too, or is this completely new?
[23:53] <ajmitch> geser: completely new
[23:53] <ari-tczew> ueee, so this release won't get many new upstream versions?
[23:53] <ajmitch> and from the responses from some canonical employees, not particularly well communicated
[23:54] <ajmitch> I wonder how feasible having universe autosync from debian, where possible
[23:54] <ajmitch> ie where all build-dependencies are satisfied
[23:56] <geser> ajmitch: please don't make it too complicated
[23:56] <wgrant> That has been suggested before.
[23:57] <wgrant> geser: I'll add testing versions of the mdt pages now.
[23:57] <geser> I'm currently thinking what's the best way to change the requestsync default. changing requestsync in lucid is easy, but I'm not sure if a backport or a sru is better for karmic and jaunty
[23:58] <ajmitch> geser: "too complicated" is bad, but we're going to have a lot of people wanting the newest stuff in universe again
[23:58] <ajmitch> I don't particularly like the idea of only being able to sync from testing
[23:59] <geser> I don't have an opinion on that right now, need to think more about it
[23:59] <lifeless> There doesn't seem to be consensus on ubuntu-devel about it yet