[00:00] so pbuilder is more in-line with dpkg-buildpackage [00:00] Neurostu: yes, only it does in in a chroot enviroment [00:01] Neurostu: ... after downloading and installing all Build-depends packages [00:01] and the chroot environment allows you to build packages for a specific architecture even if your machine is a different architecture [00:01] ? [00:02] Neurostu: uhm, only if you have an amd64 [00:02] usually only in the case of building i386 packages on amd64 [00:02] Neurostu: then you can build for i386 arch too [00:02] ajmitch beat me to it :-) [00:03] ok so do you guys prefer the pbuilder route over dpkg-buildpackage? [00:04] Neurostu: depends. But it's good because you don't need to pollute your machine with a whole bunch of -dev packages [00:04] Pbuilder is useful in that it is closer to how your packages are built on the buildd. It'll catch failure to build due to insufficient build-dependencies, for example. [00:09] so I've been trying to read the debian library packaging guide... but I'm not sure what changes I need to make to the rules file [00:13] I wasn't sure if I need to run dh_makeshlibs instead of dh_make, when I try dh_makeshlibs i get "find: debian/libsomanetwork: No such file or directory" [00:14] Neurostu: These two tools may be named similarly, but they do entirely different things. [00:15] dh-make creates a debian/ directory contianing useful templates for a new source package. [00:15] right... I've been using it to do that for a while [00:15] dh_makeshlibs is normally run from debian/rules, and creates a package.shlibs file that provides dpkg-shlibdeps with informaiton about library dependencies. [00:16] I'm guessing that I need to add dh_makeshlibs to a specific place in the rules file [00:17] Yes; it'd be in the binary: rule, IIRC. [00:17] But this is not a simple proposition; library packaging is a complex beast, with all sorts of crazy pitfalls. [00:19] right that's what they said above. So i found the dh_makeshlibs in the rules file generated by dh_make, I just uncommented it and I'll see if that works [00:20] RAOF: quoting me now? [00:20] ajmitch: Am I? Only unintentionally? :) [00:20] 10:48 < ajmitch> library packaging is a complex beast, full of pitfalls [00:21] * RAOF is much less original than he thinks. [00:25] ok so the 2nd package built and installed. It just looks like I'm having problems with glade now... [00:30] so the src/ directory has the .glade file, and when I run dpkg --contents it isn't included in the package, where would I go about getting it included in the .deb [00:35] Neurostu: Is it installed as a part of the build process? [00:36] Heh, try out this coolness: http://goosh.org/ [00:37] hmm... let me check [00:41] So when I run make install it gives me the same error [00:41] so its a problem I will have to work on with the developer [00:42] thanks for your help [00:55] RAOF: cryptomnesia! [01:00] Neurostu: You can work around it by force-installing the missing glade files with dh_install [01:12] dh_install is that a command I run or do I add that line to rules? [01:12] Neurostu: dh_install goes in debian/rules. Read the man page to determine how to get your files installed. [01:12] It's a command you run from rules. 'man' is your friend. [01:13] man --> is a great friend sometimes I forget that... [01:13] * persia curses RAOF's cogent concise commentary [01:13] * RAOF find's it a pity 'RAOF' doesn't start with 'c'. Alliteration FTW! [01:14] Right. Should have used a given name :) [01:14] * RAOF is indicted for cruely to the common appostrophe. [01:15] sorry for my pedantic questions, but what man entry am I looking at (dh_make?) [01:15] dh_install. [01:15] Also, debhelper. 'man debhelper' will give you an overview of the dh_* helpers. [01:17] Aha! I think I've caught a fundamental disconnect. The debian/rules file is just a makefile. As such, all of the tab-indented lines are just passed to a shell to be run. [01:17] RAOF: Well, passed to a series of shells. Don't try any fancy shell scripting... [01:18] Oh, yeah. One shell per line. [02:12] Heya gang [02:13] boo [02:14] Howdie bddebian. [02:14] * RoAkSoAx giving a talk about merging xD [02:15] Hi RAOF [02:30] persia: konban-wa [02:34] anyone know why i cant install a pbuilder for intrepid? [02:34] it shows me this: E: No such script: /usr/share/debootstrap/scripts/intrepid [02:35] Oh, because you haven't upgraded your debootstrap to the version in hardy-proposed or hardy-backports, I forget which. [02:35] oh right, cool thnaks, forgot to enable backports :) === asac_ is now known as asac === RoAk is now known as RoAkSoAx [04:35] hello everyone. I have just signed up to launchpad, and signed a code of conduct so i could get started helping to ubuntu. But i dont know where can i start. I have readen a little but i think i would lear faster if i actually did something. [04:35] can someone give me a clue how to start? [04:35] soonick_cancun: Well, this channel is mostly about contributing to development. [04:36] im fine about it [04:36] We tend to review the open bugs, and close them, with a bit of updating to new versions as well. [04:36] so how can i get a bug to fix? [04:36] I'd recommend taking a look at https://wiki.ubuntu.com/MOTU/Contributing, picking a bug that annoys you, and fixing up the package as much as you can. [04:37] One source of bugs people consider easy is to look at https://launchpad.net/ubuntu/+bugs and select the "bitesize" tag on the left (I forget the real URL). [04:37] should i join bugsquad? [04:38] soonick_cancun: Depends on your interest. My experience was that working with bugsquad gave me a lot of confidence with the processes, and helped me find packages I could help fix. [04:39] well i need confidence with the process, so i think ill do it :P [04:39] soonick_cancun: Most of the bugsquad coordination is on #ubuntu-bugs. Here we tend to focus on the code changes related to the bugfixes. [04:40] do i need to join bugsquad to fix a bitesize bug? [04:40] should i go to that channel to get help with the process? [04:40] soonick_cancun: Nope. Anyone can fix bugs. [04:41] bugsquad tends to look at bugs, and try to make sure they are well-understood. [04:41] That way developers (who may also be bugsquad) can use that understanding to prepare a patch, and get it to users. [04:43] ah, that seems helpful. So i can find a bitesize bug i am interested, go to bugsquad to find a deep explanation about it, fix it and then come here for help to upload it? [04:44] soonick_cancun: the deep explanation ought be in the bug. The bugsquad team tries to help get it there. Unfortunately, they only process 2500-3000 bugs a week, so not every bug is as complete as would be easy for a new developer. [04:46] so i should get one, fix it and they should help me upload the solution? [04:46] soonick_cancun: If you pick one, and fix it, and prepare a patch, the relevant sponsors will upload it. See https://wiki,ubuntu.com/MOTU/Contributing [04:48] ok, then i guess ill try that [04:49] should my next doubts be directed to bugsquad? [04:51] soonick_cancun: Depends on the doubt. If it's about bug management, bugsquad are the group to ask. If it's about development participation, this is the place to ask. [04:54] ok, ill go to bugsquad then to get some help to get started. Thank you very much for the orientation persia [04:54] soonick_cancun: Thanks for helping with Ubuntu [04:55] to soon to say that, but i hope i get there :P [07:24] hi [07:24] i want to package bzr 1.6beta1 for our ppa [07:25] is 1.6~beta1-1~ppa1 an appropriate name/ [07:26] poolie: That suggests that its got a Debian revision. [07:26] If it were me, I'd probably stick "0ubuntu" in there, too, and get 1.6~beta1-0ubuntu1~ppa1 [07:26] _Exactly_ what I was going to suggest ;) [07:26] :) [07:27] hm interesting [07:27] so it seems like people should be doing that for most ppa packages? [07:27] Unless, of course, that it is based on the 1.6~beta1-1 debian package :) [07:27] poolie: Mostly, yes. [07:29] poolie: That format should be followed if the package is intended to be a temporary upgrade for an installed Ubuntu system. If you have other intentions, other version formats may be suitable, but we can't really help so much. [07:29] it's not a temporary fix, i guess it's closest to being a backport [07:29] in that i'm packaging it for dapper..hardy [07:30] poolie: Let's call that temporary, under the assumption there may be an official backport later :) [07:30] then i'd suggest something other than ~ppa1 [07:30] something alphabetically earlier than the letter "d" [07:31] directhex: Good point! [07:32] since official backports get a ~distro extension, so a "ppa1" package would not be replaced by an official dapper, edgy, etc [07:37] like "b"? :-) [07:38] oh sorry, i mistyped before, it's actually ~bazaar1 [07:42] That would work ;) [07:58] good morning [07:58] hello dholbach [07:59] hi poolie [08:01] hey dholbach [08:01] hi ajmitch, hi slomo_ [09:09] morning everyone [09:10] morning huats :) [09:10] Hi, I was trying to build a package for hardy (blender 2.46) using pbuilder and the stuff from debian experimental [09:10] Balachmar: Did it work? [09:11] It fails, because it doesn't find the libftgl-dev. But it is in the repo, but as ftgl-dev (so without the lib) [09:11] How could I make this build ok, can I somehow create a symlink kind of link to that package? [09:13] Balachmar: just change the dependency in debian/control file, add a changelog entry documenting the change. [09:14] slytherin: I'll have a look [09:15] Because I was using the dsc file, So I guess I'll have to change something in the tar.gz file as well [09:19] ok, made the change in the diff file. See what it does [09:20] the ftgl-dev should be deprecated in interpid, according to the diff file (at least it is deprecated in debian) [09:20] Balachmar: I've got a working Blender 2.46 in my PPA. [09:20] I just backported ftgl. [09:20] Balachmar: It's best to never change the tar.gz file. This is the entire purpose of the diff.gz file. [09:20] https://launchpad.net/~wgrant/+archive [09:20] Balachmar: It doesn't work by simply altering the dependency. [09:20] @persia: I kind of got that [09:21] @wgrant: ok, so you have already backported blender 2.46 to hardy! Great! [09:21] Then I might try something else, to be useful [09:22] wgrant: What did it take to create the package? [09:23] Balachmar: I simply took blender and ftgl from experimental and uploaded them to my PPA, with a new changelog entry. [09:24] wgrant: That was ofcourse my nest step, to take ftgl as well :) [09:26] wgrant: So you first created the ftgl package and uploaded it to your ppa, then you could build the blender package as well, since it was able to find the ftgl and then you uploaded it to your ppa as well. Am I right? [09:27] Balachmar: Correct. But you need not bother yourself with that - just grab them from my PPA. [09:28] wgrant: already doing that :) Just curious if I was right on how you did it :) [09:28] So that I can help out with packaging in the future. [09:35] wgrant: i can't fully understand your comment.... ( about the patch system... i used the one in the package... or there's something wrong? [09:42] Hello, is there a tool that can be used to get fresh sources using the debian/watch file ? [09:43] nicolasvw: "uscan" [09:46] james_w: thankx ! === emgent_ is now known as emgent [09:50] gaspa: Ooops, indeed, I was looking through it too quickly and automatically mentally stripped out the leading +. Ignore me. [09:51] wgrant: fine. ;) thanks. === tb1 is now known as tbf [10:04] wgrant: feisty done. for intrepid perhaps i could drop some ubuntu deltas, so it takes a little more. :) [10:10] hi folks [10:13] lo [10:20] greetings and salutations [10:20] hiya sistpoty|work, hi norsetto [10:20] hey Daviey [10:20] hi dholbach [10:21] hi norsetto [10:21] hey dholbach! [10:21] morning dholbach [10:21] how are you guys doing? :) [10:21] * norsetto is surviving [10:21] * Daviey is GOOD [10:21] norsetto: is it that bad? [10:22] dholbach: survival is good, its extintion which is bad :-) [10:23] norsetto: right... but if "survival" is everything or your only pressing concern.... :-) [10:23] * laga ponders going for MOTU [10:23] so i'll have to do some merges, i guess [10:25] laga: there's a lot of stuff on http://wiki.ubuntu.com/MOTU/TODO - you could pick some bitesize bugs or something from http://daniel.holba.ch/really-fix-it [10:25] thanks, bookmarked. [10:25] * Daviey didn't know about really-fix-it [10:27] Daviey: It's the ultimate source of prepared fixes just waiting for someone to snipe them :) [10:35] Hi * [10:38] heya geser === ogra_ is now known as ogra [11:09] wgrant: it's enough sending the diff also for intrepid, or should i file another bug, for merge? [11:21] does https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions also apply to universe/multiverse? [11:22] we're missing lots of upstream fixes for MythTV in hardy - and there's no way i'll do an SRU for 20 patches :) [11:24] gaspa: Don't bother filing another bug. [11:24] cool. :D all done, then. [11:26] gaspa: Danke. [11:26] :) [11:28] wgrant: uops. No, wrong diff. just a minute. [11:30] laga: The rules apply. On the other hand, those are general exceptions. Any given upload is considered by the SRU team. Note that except in special circumstances, it's unlikely to be accepted as just a new upstream. [11:31] persia: sad. [11:32] laga: Why? Stability is key. What's bad about a single SRU with 20 patches? [11:32] maintainer time [11:32] i'd love to pull in a new snapshot from their release-0-21-fixes branch, get some testing done (maybe 10 positive comments instead of the usual 2) and be done. [11:32] persia: because SRUs are supposed to be non-invasive. [11:32] laga: be happy that you don't need to do a SRU for each patch :) [11:33] laga: You could ask the SRU team. Note that if the release-0-21-fixes branch is all bugfixes, and you document the bugs & fixes, there's a good chance it would be approved. [11:34] It's mostly about documentation and testing, rather than hard & fast rules. As long as it's transparent to the user, and doesn't break anything, and doesn't change the feature set, it is likely fine. [11:34] laga, question is, has the protocol version been bumped at all since 0.21? === cprov is now known as cprov-lunch [11:34] directhex: no [11:34] they didn't do it this time :) [11:35] persia: i'll talk to motu-sru then. thanks [11:35] laga, well, that makes it easier to argue that an update is non-invasive, since it (shouldn't) break mixed setups [11:35] doing a backport would be much easier, but hardy-backports isn't enabled by default :( [11:35] laga, personally i want the update, for greyfoxx's upnp fixes [11:36] directhex: you can always use the weekly fixes builds.. i still need to push them, though ;) [11:36] laga: Also, the policy is that backports aren't permitted as a bugfix channel. [11:36] persia: indeed. [11:37] laga, can't you enable backports by default in mythbuntu? [11:37] directhex: we (accidentally) did that for 7.10. [11:37] then 0.21 came out [11:37] it was a terrible mess :( [11:37] laga, oh. oops. [11:38] laga, shove one of the mythbuntu ppa repos in, then? [11:38] there have been at least 60 commits to the release-0-21-fixes branch since the last mythtv upload to hardy. too lazy to count properly now. [11:39] directhex: we're already doing that for the weekly builds, but we usually want to stay as close to the ubuntu archives as possible [11:41] persia: does motu-sru have a dedicated mailing list? [11:41] * directhex wonders what the chances would be for putting backports of mono on hardy. the mono developers are... unkind... about ubuntu's neolithic versions, and the problems it causes them for support [11:41] laga: Nope. Coordination is on the ubuntu-motu@ list. There is often a representative here, but they've all been hiding recently. [11:42] directhex: They could adopt a less ridiculous attitude. [11:42] directhex: Distributions won't upgrade stable releases at upstream's whim. [11:42] directhex: If the intrepid mono compiles and works on hardy, and you can organise a few testers, getting them into -backports might be possible (although the rdepends list is *vast*) [11:42] They need to realise that, if they don't already. [11:44] wgrant, remind me of ubuntu's approach to firefox versions [11:45] directhex: That's because Mozilla upstream is insane, and unlikely to change. [11:45] directhex: That's the other option: upsteam gets deeply involved in Ubuntu integration, and petitions the Technical board. [11:46] * persia notes that this tends to make upstream match Ubuntu schedule rather than the other way around, so isn't a good solution for those wishing to maintain their own schedule) [11:47] the whole "upstream's schedule should be linked to ubuntu's" is insane anyways. [11:47] i can't see them changing their releases to match. if anything motivates them, it'll be SLES timescales [11:47] but in SLES world, updates DO happen to stable releases [11:48] laga: Personally, I don't see any reason for upstream to match Ubuntu, but not matching comes with the consequence that Ubuntu shipped versions may not match latest upstream. [11:48] of course. that's not a bad thing. [11:48] Exactly. The point is that no upstream can have it both ways. [11:49] (except Mozilla, and we'd rather not do that, except that it can't be called Mozilla if we extract and ship security patches, because upstream is, as noted, insane) === fta_ is now known as fta [11:56] note to self: don't try ctrl-alt-backspace in a vm, if the keyboard is not grabbed *G* [11:57] gg [11:57] :) [11:57] sistpoty|work: Even then... ? [11:57] sistpoty|work: I thought you couldn't work around ctrl-alt-backspace being sent to your own X serveR? [11:58] soren: no idea actually [11:58] Regardless of keyboard grab, focus or whatnot.. [11:58] sistpoty|work: Otherwise, it would fail to be the final resort kind of way of killing your X server if your input goes bonkers. [11:59] in vmware, you do ctrl-alt-space, then let go of space, and do backspace/f1/whatever whilst keeping ctrl-alt going [11:59] it seems to behave [11:59] soren: *nod*, that makes sense [11:59] directhex: I wonder how they pull that off.. [11:59] *shrug* [12:00] magicks, of the dark variety [12:01] :( [12:05] persia: ping [12:06] soren: Yes, I have too much RAM. Sorry :( [12:06] persia: I have an alternate patch here.. [12:06] pasties? [12:07] moment.. [12:08] Gah.. I accidentally pushed it to launchpad. [12:08] * soren kicks bound branches. [12:09] Heh. [12:09] This is part of why I like CVS. You do your work locally with quilt or the like, and then push the patches on purpose :) [12:09] persia: http://bazaar.launchpad.net/~ubuntu-virt/ubuntu-jeos/trunk/revision/69 [12:09] You /like/ CVS? [12:14] soren: Well, I like that I never commit by accident. it's the not committing by accident that tends to be an issue. [12:14] lol [12:15] Anyway, about this patch: are you sure `rm -rf root` won't delete target when INSTALL_IN_PLACE is "YEAH"? [12:16] persia: Reasonably. [12:17] soren: OK. I recently had a bad experience with rm -rf and symlinks, but it wasn't Ubuntu, so it may be safe. [12:17] persia: Now I'm completely sure. Just tested it. [12:17] persia: Could you take it for spin real quick? [12:17] soren: Excellent. The rest looks good, although I'd still like the tmpfs option for those making images that can fit in tmpfs, but it's likely a personal preference :) [12:18] persia: That's what "-d /dev/shm" is for :) [12:18] real quick? No. I'll start a run, but it takes a while. [12:18] I do it all the time on my workstation. [12:18] soren: Ah. right :) [12:27] soren: all the different ways I try to run that fail with debootstrap: ... Permission denied :( [12:28] :$ [12:28] Er.. [12:28] Ok. === ember_ is now known as ember [12:30] soren: Mind you, I just pulled the script from bzr, and am running it in a local directory. Might that be breaking some assumption? [12:31] persia: No, that should be fine. I think I know what's wrong. [12:37] persia: *headdesk* === cprov-lunch is now known as cprov [12:42] persia: Grab from the bzr tree again, and try again, please. [12:44] Hey, just found this bug: https://bugs.launchpad.net/ubuntu/+source/blender/+bug/235424 And I know that wgrant actually already has packages for blender 2.46 for hardy. So what should be done for this bug to be squashed? [12:44] Launchpad bug 235424 in hardy-backports "Update package from upstream to version 2.46" [Undecided,Confirmed] [12:46] Balachmar, well, just wait until its built in intrepid and ask for a backport :) [12:47] ogra: OK, I was just checking of maybe I could do something to help :) And I tend to prefer to look at packages I know/use [12:48] Balachmar, well, laga seems to be responsible for getting it from experimental into ubuntu according to http://merges.ubuntu.com/universe.html [12:48] i'm sure he appreciates help [12:48] oh, err [12:48] not laga, sorry [12:49] you mean Daniel Hahler [12:50] yeah [12:50] I'll send the guy an e-mail then. [12:50] right, ask him if you can help :) [12:52] persia: Any better? [12:52] soren: Sorry. As is so often the case, today is the scullery maid's night off. Just pulling now... [12:53] persia: O_o [12:53] Heh [12:58] soren: At least it is running debootstrap, which isn't usually possible on my system. Things are looking good. [12:58] persia: Coolness. [12:58] soren: Is this targeted as a replacement in -updates, or for intrepid? [13:03] persia: The former. [13:10] soren: it ate my workstation :( [13:10] persia_ume: You are kidding of course? [13:11] Not really. I'm currently at stage 1/5, 741/1906 of a fdisk recovery [13:11] Whuh... [13:12] s/fdisk/fsck/ (my brain is apparently also affected) [13:12] I'm not sure either. Everything looked good, and then the screen went black and the BIOS started [13:13] Heh... I somehow doubt that could be my fault. :) [13:13] persia_ume: Although. [13:13] .... [13:13] What happens if you fill your /tmp up completely? [13:14] I wasn't really doing much else: I was I/O bound hard enough to block most other activities. [13:14] But I was using --in-place, which should use the local image, rather than /tmp, right? [13:15] No, it still puts the stuff in /tmp, but loop mounts the final images instead of using a temporary directory to build the system. [13:15] Ah, and my /tmp was full of random stuff (some of which was large) [13:16] Well, if your system misbehaves if your tmpfs fills up with stuff, that's a bug elsewhere :) [13:16] (And I don't have very much more than 2x RAM) [13:16] soren: Yes, but the --tmpfs flag worked for me... [13:17] (as did the crude hack that broke it for everyone else) [13:17] I suppose the correct answer is that people who want to mount things like me ought mount something else and use -d [13:17] Well, it worked fine for me, too. I just stumbled when I was running ubuntu-vm-builder inside a vm with 96 MB ram,. [13:17] Boom! [13:18] heh [13:18] Why this https://wiki.ubuntu.com/PackagingGuide/Complete is required to follow? It is quite complicated. This one http://www.ibm.com/developerworks/linux/library/l-debpkg.html looks very simple and easy. [13:19] persia_ume: Well, with --in-place we support a nosuid and nodev /tmp. That something else doesn't support a tmpfs filling up is not really in scope for me :) [13:19] amikrop: There are no restrictions on which packaging guide you use, so long as the resulting package complies with the policy defined in the debian-policy package on the current development release. [13:20] soren: Makes sense. I suspect the set of people who have /tmp on /tmpfs and the set of people who have /tmp nodev,nosuid has a small intersection. === persia_ is now known as persia [13:23] persia_ume: I find https://wiki.ubuntu.com/PackagingGuide/Complete complex. Are there any other more simple guides that lead to hardy-debian-compliant packages? [13:23] persia: I find https://wiki.ubuntu.com/PackagingGuide/Complete complex. Are there any other more simple guides that lead to hardy-debian-compliant packages? [13:24] amikrop: no need to repeat yourself :) [13:24] Anyway, there's the Debian packaging guide. There are also lots around the net. [13:24] The debhelper 7 guide is interesting, as is the CDBS documentation. [13:24] You can check yourself against most of policy by running lintian against your packages (both source and binary) [13:25] My personal recommendation is to take a source package, create a debian directory, add copyright and control to match other packages you've seen (and the source on which your package is based) [13:25] Use dch --create to create debian/changelog [13:25] amikrop: forget the ibm guide as fast as you can, with this guide you won't get any package into Debian or Ubuntu [13:25] And start a debian/rules based on what you like. [13:26] geser: OK :-/ [13:26] persia: So, what guide do you suggest? [13:27] geser: Can't I create compliant packages as simply as with the ibm guide? [13:27] "the ibm guide"? [13:28] amikrop: I typically suggest the Ubuntu one, but no guide can be both simple and complete: there are too many ways to create a valid package. [13:28] Or, much more simply than the Ubuntu Packaging Complete Guide? [13:28] persia: Which is the simplest? [13:28] soren: http://www.ibm.com/developerworks/linux/library/l-debpkg.html [13:28] amikrop: I've not made a comparison, but I'm guessing it's wrong :) [13:29] Based on what I see from that URL, I'm guessing the IBM guide is the simplest, but it misses the point of a source package entirely. [13:30] As a result, the package cannot be easily modified or distributed, and won't work on multiple architectures. [13:30] persia: So, should I follow the Ubuntu one? It is complicated in the way that it uses many tools, and says too much about the rules file and stuff. The thing is that I don't want to compile stuff. My package has some basg scripts, some Python scripts, and some object code. I also want to be able to write some simple postinst and postrm files. [13:31] amikrop: OK. You can't package object code without compiling it: that won't work on multiple platforms. [13:31] s/basg/bash [13:31] That said, for the rest, just put everything you want in a directory structure that makes it easy to understand. [13:31] Make sure you have a license in COPYING in the root directory. [13:31] persia: The object code is not open source. [13:32] amikrop: That's OK. This is your package, for your use. [13:32] amikrop: the guide tries to be general, if you don't have nothing to compile, you can skip this step [13:32] (The object code is not mine.) [13:32] amikrop: Do you have the source? [13:32] amikrop: how is it licensed? [13:32] persia: no [13:33] freeware [13:33] It is not a common license. [13:33] It is theirs. A custom license. [13:33] It allows distribution. [13:33] amikrop: OK. You won't be able to make a compliant package. Go back to the IBM guide, but be warned that this can't easily be distributed. [13:33] geser: But it says too much about many tools, like dh_* and many many other stuff. It makes thing really complicated. [13:34] well, the guide probably tries to be complete. [13:34] laga: And useful. [13:34] I find it confusing. [13:34] making binary-only packages isn't exactly a common use case in the FLOSS world. [13:34] amikrop: it can be easy and it can be hard, depending on the source [13:34] laga: It is not my choice. [13:35] amikrop: To ask a different question: who is the target audience for the package? [13:35] persia: end-users [13:35] amikrop: Surely, but what sort? Internal, Customers, The World? [13:36] Just users that want to connect to the Internet easily with a usb modem. [13:37] geser: Is this section https://wiki.ubuntu.com/PackagingGuide/Complete#head-b1e654041de2f572282304b43e4b5191866afe46 enough to package some simple stuff? [13:39] amikrop: There are a few different open-source packages out there for that purpose. You say "It's not my choice". Why do you want to package these specific objects? [13:39] amikrop: "Packaging From Scratch" is the hardest way to package :) [13:40] but it's easier to use than cdbs if you source isn't like cdbs expects it [13:41] True, but debhelper is typically easier still. Anyway, for just images, python, glade, bash, etc. I find CDBS + debian/install painless. [13:41] (that's python *scripts*, not modules) [13:43] Look. I want to install some Python scripts, some Bash scripts, and some Object code (architecture-independent). Also, I want to write a minimalistic postinst and postrm. Just that. [13:44] What is the most simple way to do this? [13:45] persia: The conclusion was that the patch was good, right? [13:46] soren: The conclusion was that the patch was likely to work for people not me, and that I should complain to someone else :) [13:46] persia: :) gotcha [13:47] santiago-ve: were you the one looking at kguitar on the weekend? [13:49] * Hobbsee merges spamprobe. [13:49] is it a better idea to start with packaging on a "real" machine or should i setup a vm instead? [13:49] So, what should I read in order to accomplish that simply? [13:58] schmiedc: Either works. If you go for the real machine, either have a test machine for using the development release or create some chroots for testing. [14:00] ok [14:00] thx [14:16] How can I do what I need, then? What do I need to read? [14:24] Any suggestions? [14:31] persia, geser: Excuse me, but I didn't understand the conclusion. What guide/section should I read to cover my needs? [14:41] amikrop: I don't really understand your needs, and don't tend to recommend guides anyway. [14:42] persia: OK. I want my package to install some Python scripts, some Bash scripts and some Object code. I also want to write a simple postinst and a simple postrm script. What should I read? [14:44] amikrop: See, I'm really not sure that's what you want. I think you likely either want to work with upstream to have their source (even if you don't distribute it) or want to select a different upstream. [14:44] Packaging object code is fraught with difficulty, and even the best packagers routinely make significant mistakes. [14:45] Further, I'm fairly certain nobody has written a guide that lets you do that successfully and reliably. [14:45] And you are unlikely to find guidance for packaging severely non-free software here. [14:46] amikrop: one question: what kind of object code is it if it's arch-independent? [14:46] OK. Let's forget about object code. How can I package some simple python/bash scripts? [14:46] amikrop: That's easy. I listed it all earlier. [14:46] geser: It is related to the ueagle-atm kernel module. [14:46] amikrop: I'd suggest something with debhelper like described in the "Packaging from Scratch" section [14:46] persia: You mean the Complete Ubuntu Packaging Guide? [14:47] amikrop: does it get upload to the modem? i.e. is it a firmware? [14:47] geser: Yes. [14:47] amikrop: No, I mean the step-by-step instructions on creating an orig.tar.gz from your scripts, and which files to create in debian/ to generate a source package. [14:47] persia: Which URL is this? [14:48] http://irclogs.ubuntu.com/2008/06/03/%23ubuntu-motu.html [14:50] amikrop: Sorry. That's won't be up to date for another 15 minutes, but it will be from 14:27 [14:50] heya [14:51] Or is it. I'm lost. [14:51] geser: So, "Packaging from Scratch" is it? [14:52] amikrop: that would be my suggestion [14:52] Anyway, to summarise. Put everything in a directory to make it easy to modify. Put the license in COPYING. Use that to make orig.tar.gz. Unpack again. Add debian/copyright and debian/control. Use dch --create for debian/copyright. Use the 1-line debian/rules from the CDBS documentation. Indicate your installation in debian/install. [14:52] geser: OK. Thanks. [14:53] persia: I will try. Thanks. [14:54] Hobbsee, yes i was working with kguitar [14:56] nicolasvw: gdecrypt download link updated, thanks for the hint [14:57]