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