=== effie_jayx_ is now known as effie_jayx === test is now known as _iron === _iron is now known as ___iron [01:19] Hi. Could anyone tell me why git-buildpackage does not produce a orig.tar.gz? === lukjad007 is now known as ShadowChild [03:15] Im not unable to subscribe u-u-s. Anyone else having that issue? [04:04] directhex: just filter that guy out. That'll save you a lot more headaches. [04:04] (but yeah. agh, not again) === nhandler_ is now known as nhandler [05:27] Hello [06:42] is it possible to build binary packages for hardy, intrepid and jaunty? easily? [06:42] I have a source package that builds for each one, but so far I have had to copy it to 3 different machines to build the binary. [06:47] This is pretty easy to do with pbuilder. === bluesmoke_ is now known as Amaranth === fenris- is now known as e-jat === ShadowChild is now known as lukjad007 === jcfp is now known as Guest41522 === Guest41522 is now known as jcfp` === jcfp` is now known as jcfp [11:39] Could someone answer the following question - I have the sourcecode of an application without any build files - for the debian package I added autotools build to the app. Now when I generate the source package (and orig.tar.gz), what should it contain: 1. the original application sourcecode 2. the full debianized sourcecode [11:39] ) [11:39] ? [11:41] a) you shouldn't be generating the orig.tar.gz; that should come from the upstream. [11:41] b) the diff, naturally, should contain all changes you have made, in some form. [11:45] I have a git branch where the original sourcecode resides - and another one where the changes are done - but it just can't get the source package to be generated [12:02] LCID_Fire: are you the upstream developer? [12:03] Laney: nope - I'm the idiot who tried to build a debian package [12:03] ok so you shouldn't modify their releases [12:03] Laney: clarify "modify their releases" [12:03] the unmodified upstream source should be in the orig [12:04] and your changes in the diff [12:05] that's pretty much how the branches are setup in my git repo - but git-buildpackage keeps screwing it... [12:06] you should have a master and an upstream branch [12:06] upstream is just the unpacked tarball [12:06] and master is that + debian/ + your changes [12:06] master is merged from upstream [12:07] yep - it seems to me like git-buildpackage does not now what to use as orig source [12:07] maybe you need pristine-tar too? [12:07] hyperair knows more about this than me, he can probably help better [12:07] ? [12:08] hyperair always helps :) [12:08] LCID_Fire: this has _nothing to do with branches_ [12:08] he is the master of git [12:08] LCID_Fire: the upstream *tarball* is what matters. [12:08] LCID_Fire: as for git specific stuff, I can't help sorry. [12:08] lifeless: the tarball does not matter if you build from scm [12:08] LCID_Fire: for debian and ubuntu packages, it does. [12:09] LCID_Fire: paste the output of git-buildpackage -S [12:10] Orig tarball 'agda_2.2.2.orig.tar.gz' not found at '../tarballs/' [12:10] pristine-tar: successfully generated /home/laney/dev/debian/packaging/build-area/agda_2.2.2.orig.tar.gz [12:10] that's what happens with one of my git packages [12:11] lifeless: the point is that orig.tar.gz is to be GENERATED out of git - but it isn't :( [12:11] where did the upstream sources come from in the first place? [12:11] LCID_Fire: if you're not using pristine_tar, it cannot be created from git. [12:11] Im not unable to subscribe u-u-s. Anyone else having that issue? [12:11] is there a release at all? [12:11] LCID_Fire: or any other VCS [12:12] Laney: sourceforge - http://sourceforge.net/project/showfiles.php?group_id=171505 [12:12] lifeless: I don't even know what pristine_tar is [12:12] LCID_Fire: then just download the original tarball, name it correctly, and away you go. [12:13] lifeless: it's zip ;) [12:13] LCID_Fire: ugh. Well you'll need to repack it, but do that once. [12:15] uscan can do this with --repack (I think for .zip) [12:15] lifeless: but to maintain it - I need it to be generated - I'm not in the mood to manually create the orig.tar.gz every time there is a release [12:15] LCID_Fire: please stop that huge paste if you can [12:15] :((( [12:15] Laney: done [12:15] thanks [12:15] pastebin would be easier to read [12:16] Laney: on my xchat it's pretty good to read [12:16] LCID_Fire: then don't maintain this package, or get upstream to start generating tarballs. [12:16] so, what you want to write is a watch file [12:16] and then a get-orig-source file which calls uscan --repack [12:16] *someone* somewhere has to put the orig source into a tarball for ubuntu packages. [12:17] lifeless: that's the point of git-buildpackage - it SHOULD do the work (at least it is advertised) [12:17] no [12:17] Laney: I have no idea what you are talking about, sorry [12:18] LCID_Fire: thats not the point of git-buildpackage [12:18] LCID_Fire: then you should find out [12:18] yes it is: please read "man git-buildpackage" [12:19] LCID_Fire: its point, like that of svn-buildpackage, bzr-buildpackage etc etc is to allow better granularity in maintaining the delta that makes up the packaging data & bugfixes that are needed to package the software [12:19] lifeless: you're right - but the manpage also says: "Build an orig.tar.gz if it doesn't exist." [12:19] pristine-tar does allow putting *an existing* orig.tar.gz into a VCS and reconstructing it later. [12:20] lifeless: I did this with git-import-orig [12:20] actually gbp does let you do this without pristine-tar, but it isn't idempotetnt [12:21] agda_2.2.2.orig.tar.gz does not exist, creating from 'upstream/2.2.2' [12:21] right, which makes it unsuitable for collaborative maintenance [12:21] for whatever reason this does not work for me [12:22] lifeless: why? [12:22] because SHA1 [12:22] shouldn't it work when everyone is using git? [12:23] no [12:23] as Laney says its not idempotent [12:23] he means it generates a different tarball each time it's run [12:23] this is the problem that pristine-tar fixes [12:23] besides which, many people use other VCS's than git [12:24] Laney: LCID_Fire you called? [12:24] it's alright [12:24] but, good morning! [12:24] hi [12:25] so the way gbp works is actually a bug? [12:27] btw: just found http://juliank.wordpress.com/2008/02/04/experiences-with-git-and-pristine-tar/ [12:28] this is pretty much what we said [12:29] the interesting thing is - the patch was submitted - but pristine is not a dependency of git-buildpackage... [12:30] it's only optional [12:34] I still don't get why it isn't generating orig.tar.gz [12:34] if you pasted the output that I asked for we could take a look [12:34] to a pastebin(!) [12:35] np - you just have to wait till I google pastebin [12:35] www.pastebin.com [12:38] interesting - it's on http://pastebin.com/d4617b699 [12:41] this isn't the whole output [12:42] it is the output of "git-buildpackage -S -sa --git-pristine-tar > ../build.txt" [12:42] remove those other options [12:43] so just using -S? [12:43] you're telling it explicitly to use git-pristine-tar there [12:43] ep [12:43] yep [12:43] ok [12:46] updated: http://pastebin.com/d1848a594 [12:48] oh [12:48] you've made a native package [12:48] you need to make the version 7.1.2-0ubuntu1 [12:49] how do these last 2 statements link? [12:50] http://people.debian.org/~mpalmer/debian-mentors_FAQ.html [12:50] check the FAQ about native packages [12:51] and why isn't it telling me this conclusion when I'm building? [12:52] because it doesn't know that this isn't what you want [12:52] but it should at least tell me what it does and what it thinks that I want [12:53] # [12:53] dpkg-buildpackage: source only upload: Debian-native package [12:54] Laney: this line is as good as saying nothing - it just helps if you already know what you have to do - which is what debian packaging seems to be aimed at [12:57] right, these are tools for developers to use in their daily work [12:57] documentation and help forums such as this are for learning how they work [12:58] In former times I wondered why so much software is not packaged for debian - now I know [12:59] it's really not bad if you read some documentation [13:00] I read a LOT - but you can't read everything there is to packaging - they hardly make a clear point [13:00] complaining to me isn't going to help anything [13:00] you have this place to ask specific questions [13:00] and then you can help to improve the documentation [13:00] I know - but I have to get all the anger out of my system ;) [13:02] besides I'm now stuck with "dpkg-source: unrepresentable changes to source" (seems to be related to autotools) - I'm getting further in babysteps [13:02] but for now - thanks a lot - would have never figured these things out without you guys === lukjad007 is now known as ShadowChild [15:17] Hello, I'm working on https://bugs.edge.launchpad.net/hundredpapercuts/+milestone/round-1 [15:17] I fixed a bug now, but how & where do I upload it ? [15:23] dupondje: which bug is it? [15:24] https://bugs.edge.launchpad.net/bugs/57210 [15:24] Launchpad bug 57210 in nautilus "Search button does not toggle search field" [Wishlist,Triaged] [15:25] dupondje: In this case it'd be best to get the fix directly into GNOME. [15:26] RainCT: but isn't it to late then to get it into Karmic ? [15:26] dupondje: but it seems like someone has already provided a patch there [15:26] yea, not working + outdated [15:27] dupondje: No, not if it gets into GNOME in time. Karmic will ship with the next GNOME release. [15:27] ok [15:38] hello [15:39] how do I request that a program be packaged? [15:39] masterkernel.. you the one packaging kernelcheck? [15:39] yes [15:39] anyway you file a needs-packaging bug in ubuntu [15:40] the problem is that I want to remain anonymous [15:40] yes, i noticed. [15:40] you could use a false alias ;) [15:40] a real sounding false alias [15:40] John Smith [15:40] heheh [15:40] don't quote me on that [15:40] i wont [15:40] some people will grill me i'm sure [15:41] the channel's logged anyway, so whoops =p [15:41] and keep lurkers ;-) [15:41] i attempted to try to get other people to do it for me but no one's picked it up thus far [15:41] *package it [15:42] RainCT: I just saw your pull-revu-source request. I have been thinking about that for a while. Instead of allowing users to pull from different versions of Ubuntu/Debian, they could pull different uploads of that package by specifying a date/upload id [15:42] masterkernel: poke around in #ubuntu-kernel, maybe someone will be interested enough. [15:42] good call [15:43] =) [15:43] i'm past my kernel compiling days, or so i'd like to say [15:43] because the kernel just works for me, and my notebook overheats and shuts down if i compile something that big [15:44] otherwise i'd package it [15:44] i think it's a good idea to get it into debian and let it get synced into ubuntu though [15:44] that way more people benefit from the package [15:44] * hyperair pokes masterkernel [15:44] I would ask the co-author to do it but i don' [15:44] what's kernelcheck? [15:45] t think he knows much about packaging [15:45] http://kcheck.sourceforge.net/ [15:45] yeah, i'm looking at the page [15:45] ah... found it [15:45] i think it's something that downloads the up to date kernel sources [15:45] and compiles it [15:45] after applying the ubuntu patch [15:45] basically a GUI for it [15:46] I should update the description on the homepage -- not very informative [15:46] urgh... === freeflyi1g is now known as freeflying [15:46] hmm come to think of it, there was someone who posted those awesome guides on ubuntuforums by the name Master Kernel. is that you? [15:46] yeah [15:46] masterkernel: it's not easy to find, actually :) [15:46] masterkernel: how come you didn't just call the project kernelcheck? [15:46] masterkernel: like kernelcheck.sf.net instead of kcheck [15:46] so, it breaks all tools that dpends on specific version of modules? [15:47] I'm not really sure [15:47] that would be logical [15:47] nhandler: I don't use those tools so I have no comment on that (the request was from porthose, I only marked ubuntu-dev-tools as affected because he filed it against REVU). [15:47] ivoks: ? [15:48] masterkernel: there are tools in linux distributions that depend on specific versions of modules [15:48] what tools? [15:48] i'm just trying to figure out what this kernelcheck actually is :) [15:49] drbd, kvm... [15:49] mostly kernel stuff [15:49] errr... server :) [15:49] I haven't seen any breakages in my compilations - and with dkms they seem to compile right with every new kernel [15:49] apart from nvidia/ait [15:49] *ati [15:50] right, dkms would help [15:50] RainCT: I added patch to the Gnome bug, what should I do with the launchpad bug ? [15:53] doesn't nvidia use dkms too? [15:53] they do [15:53] and should work [15:53] it's broken other than ubuntu-specific kernels [15:54] problems with nvidia-common [15:54] so I always have to use the binary package [15:56] * RoAkSoAx says hello [15:57] dupondje: just leave a note saying that there's a patch in bugzilla [15:57] ok [15:57] dupondje: maybe you can get someone to look at it on #gnome-love (server irc.gnome.org) [15:58] done :D [15:58] thx [15:59] ubuntu-kernel seems inactive [16:03] ivoks, heya master how's it going [16:03] ok [16:03] you? [16:03] ivoks, tired :) just woke up xD [16:04] ivoks, do you have little time to help me out with something? [16:04] sure [16:05] ivoks, ok, I've worked with: https://bugs.launchpad.net/ubuntu/+source/passenger/+bug/382539 and I have some doubts on the lintian warnings that are listed there in the comment [16:05] Launchpad bug 382539 in passenger "Please upgrade passenger from 2.0.3 to 2.2.2" [Undecided,Incomplete] [16:06] ok [16:06] ivoks, the first warning is related to that ${misc:Depends} is not use. I was wondering. what is ${misc:Depends} used for, and if it's necessary in my case?? [16:09] It is used by miscellaneous components of debhelper to insert various boilerplate dependencies [16:10] sorry, wasn't here for a moment [16:10] It simply means you need to include ${misc:Depends} in your package's Depends: line. [16:11] right, misc:Depends is needed so that package pulls some packages it needs [16:11] man debhelper [16:11] It's pretty minor, only very few debhelper commands insert anything there [16:11] Automatic generation of miscellaneous dependencies. [16:12] RoAkSoAx: what comaptibility is that? (debian/compat) [16:12] ivoks, 6 [16:12] since 4, there should be ${misc:Depends} [16:14] just put it :D [16:14] ivoks, oh i see. what about this warning: passenger source: maintainer-script-lacks-debhelper-token debian/postinst. Does that mean in debian/libapache2-mod-passenger.postinst ¿? because if it's so, the token is there [16:15] #DEBHELPER# [16:15] you should have that at the end of the file [16:16] debian/postinst [16:16] and debian/prerm [16:17] ivoks, like this: http://pastebin.ubuntu.com/200119/ ? [16:17] just at the end of the file [16:18] ivoks, this changes should be in the changelog right? [16:19] all changes have to be in changelog - that's why it's called changelog [16:19] ivoks, and what about the last warning. Should I bump Standards Version ? [16:20] sure [16:24] ivoks, done. So, why is lintian still showing the warnings after the changes have been made? [16:25] the same warning? [16:27] ivoks, i know what's worng. never mind... btw.. if in debian contrl i have a package-doc whicuh install the documentation. should it also have the Depends?? it should right? [16:27] I mean, it shouldn't since it's just documentation [16:28] popey, didn't you know "doing something I didn't ask for" is the same thing as "ticking a box in a dialog box to explicitly do something"? [16:28] NB you only bump Standards-Version because the package isn't in Debian at all [16:29] directhex: :) [16:29] RoAkSoAx: does it depend on anything? [16:29] popey, i like how a Certain Blog is accusing keybuk of orchestrating a whisper campaign [16:29] ivoks, no, so it should not be used [16:29] oh dear [16:30] ivoks, btw.. the #DEBHELPER# token should be *only* in debian/postinst debian/prerm or in libapache2-mod-passenger.prerm libapache2-mod-passenger.postinst aswell ? [16:30] popey, due to his response in that thread, where he implies an endless source translation might get boring for its developer at some point [16:30] RoAkSoAx: in all *inst and *rm scripts [16:30] ivoks, ok cool [16:31] RoAkSoAx: you should have misc:Depends for -doc === effie_jayx_ is now known as effie_jayx [16:32] directhex: I tire immensely of the whole m ono thing, you must be made of sterner stuff [16:33] popey, i was genuinely distraught last weekend at some of the hate against me on linuxtoday [16:33] ivoks, ok this is -doc package: http://pastebin.ubuntu.com/200125/ [16:33] directhex: :( Sorry to hear that. We (Linux community) are our own worst enemy sometimes. It's so destructive. [16:34] RoAkSoAx: you should have misc:Depends for -doc [16:34] ivoks, just misc:Depends ? [16:34] directhex: Just remember there's a boatload of people out here who really appreciate the good work you do. [16:34] RoAkSoAx: Depends: ${misc:Depends} [16:35] popey, my spirits were lifted enormously by a blog post from David Schlesinger, the guy on u-d-d who had his bos contacted in an effort to have him fired === effie_jayx is now known as keffie_jayx [16:35] ivoks, i meant, just misc:Depends and not shlibs:Depends. And, why should it be there ? [16:35] directhex: url? not seen it. [16:35] popey, it'd be nice not to have people like [REDACTED] comparing my work to cancer. that'd be a good start [16:35] popey, http://opensourcetogo.blogspot.com/2009/06/when-zeal-becomes-zealotry-tawdry-tale.html [16:35] popey, it gets extra epic in the comments [16:35] RoAkSoAx: read man page; i'm not going to repeat the stuff i said 5 minutes ago [16:36] I am off out for the night, bookmarked for bedtime reading ;) [16:37] ivoks, ok sorry [16:39] ivoks, thanks for your help. [16:40] sure [16:48] so should I just file a bug under needs-packaging and hope someone picks it up? [16:57] masterkernel, unless it's an app made from awesome and win, requiring little work, the chances of someone doing it for you are not huge [16:57] masterkernel, but you never know [16:59] even if I have all the debian/ files ready? [16:59] in that case, you don't file a needs-packaging bug, you upload the source package to REVU [17:08] directhex, from my reading of the new package wiki you always need a needs-packaging bug, that's the one you close on the changelog [17:09] directhex: the issue is that masterkernel wants to remain anonymous. [17:09] hyperair: looks like it's possible - http://lists.debian.org/debian-devel/2009/06/msg00601.html [17:10] hi all [17:10] hyperair: it's getting the sponsor to accept responsibility thats going to be tough [17:10] heh [17:15] odd request [17:20] masterkernel, what app is it ? [17:21] joaopinto: kernelcheck, i'll give you the link to the deb source in a sec [17:22] Hi - the bugger is back again ;) [17:22] joaopinto: http://mentors.debian.net/debian/pool/main/k/kernelcheck [17:22] masterkernel, if I am not mistaken there is already a ppa to get the latest upstream kernel, I don't see much value on such app for ubuntu [17:24] check out the doc link - it shows screenshots of the program: http://kcheck.sourceforge.net/pool/Documentation-Lumen.pdf [17:24] and kernelcheck lets you customize the kernel - it's not just some generic kernel you can download [17:25] it helps with hardware incompatible with the generic kernel, or modding the bootscreen, speeding up boot time and such [17:26] ok [17:26] when dpkg-source complains it means the difference between the orig.tar.gz and the debian changes, right? [17:26] masterkernel, looks good :) [17:30] LCID_Fire: depends on what it complains about really [17:30] hyperair: error: cannot represent change to some.png: binary file contents changed [17:31] heheh [17:31] right [17:31] yes [17:31] difference between orig.tar.gz and debian changes [17:31] question. some.png is inside or outside of debian/? [17:31] outside [17:31] then don't change it! [17:31] just leave it as it is! [17:32] I pretty much cannot - the original directory structure is pretty messed up [17:32] LCID_Fire, you are not expected to cleanup original directory structure as part of the package building :P [17:32] joaopinto: it's a dirty job, but someone has to do it ;) [17:33] why not send that to upstream and request a new clean orig ? === WelshDragon is now known as YDdraigGoch [17:34] joaopinto: because the developer is not too much into contribution - besides he doesn't care too much because he doesn't have to on windows [17:35] all: basically in order to get debian to work I have to leave every file in it's place? [17:36] LCID_Fire, or you repack the original tarball, which is not very common [17:36] oh boy [17:36] and needs a strong reason [17:37] ok, I'll look into whether restructuring again might be an option [17:38] btw: how should one properly handle the deletion of a file being present in the orig.tar.gz? [17:39] LCID_Fire, you should not delete files from .orig.tar.gz [17:40] joaopinto: e.g. a compile script that I don't use!? [17:40] just don't install them, or remove from the installation target [17:40] and I do this by??? [17:40] LCID_Fire, let me try to be very clear, .orig = original source [17:41] joaopinto: so you mean keep it in the sources but ignore!? [17:41] just because you don't need it or dont use it, it is still part of the original source [17:41] yes [17:41] ok - that will be one messy source package [17:41] if you need to "fix" the script, use a patch, if you don't just leave it there [17:42] so - a lot of work ahead - but thanks for now guys :) [17:48] how should /etc/modprobe.d/dkms.conf be utilized? [17:48] superm1: here? [18:23] Hello everybody [18:23] Heya guys can someone still work with FTBFS and missing dependencies after the Debian Import Freeze? [18:24] RoAkSoAx: of course [18:24] RoAkSoAx: development doesn't stop with dif [18:25] RoAkSoAx: The only thing that really happens after DIF is the auto-syncs from Debian stop [18:25] my question is: Where to put arch dependent libs best, if I don't want to package them themselves, their part of an application [18:25] nhandler, what about merging and syncing new upstream versions? [18:28] RoAkSoAx: Those can continue [18:28] nhandler, till when? [18:29] I filed a needs-packaging bug on launchpad: 389946 and uploaded the package to revu. now I need 2 Ubuntu developers to sign & review it, correct? [18:29] RoAkSoAx: It isn't really until FF where you need to start worrying about getting exceptions and stuff like that [18:30] nhandler, which is on August 27th? [18:31] Yes RoAkSoAx [18:31] nhandler, and after FF people start concentrating on bug fixing right? [18:32] RoAkSoAx: Correct. Bug fixes, important changes, and stuff that brings us closer to releasing a great Ubuntu ;) [18:33] nhandler, ok cool :) that cleared my doubts [18:33] thanks for your help [18:34] *push*: Where to put arch dependent libs best, if I don't want to package them themselves, their part of an application [18:34] You're welcome RoAkSoAx [18:36] or the other way around, am I allowed to copy libs to /usr/lib or /usr/lib64 in my package wich is not a lib...-package? [18:39] hello when i try to bzr push it give me the error: "bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Emythbuntu-documentation/mythbuntu/documentation/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()" i have run "bzr launchpad-login callum1234moo-live"(my launch pad name(user name is hansolo669)) and it looks like it workd but then still give the error. i have [18:43] changed launch pad name to hansolo669 [19:10] nobody online who knows where to put it and whether I am allowed? [19:20] any motu want to mentor me for a few minutes on building a nautilus package from a nautilus branch in git? I have the branch checked out, and the apt-get source of nautilus, I'm just not sure how to merge them [19:24] mrooney: here's a MOTU video which details upgrading packages http://www.youtube.com/watch?v=JJzM2LNOtWU [19:25] nellery: ahh thanks that sounds functionally equivalent perhaps [19:26] mrooney: and words to go along with it https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate === ShadowChild is now known as lukjad007 === emgent_ is now known as emgent [20:47] I filed a needs-packaging bug on launchpad: 389946 and uploaded the package to revu. now I need 2 Ubuntu developers to sign & review it, correct? [20:48] directhex: Hey. Can you take a look at bug #350203? Seems like it needs /usr/lib/libgdk-x11-2.0.so from libgtk2.0-dev to run, but that doesn't seem right? [20:48] Launchpad bug 350203 in youtranslate "crash on starting on intrepid" [Low,Confirmed] https://launchpad.net/bugs/350203 [20:49] masterkernel: Yes. Your best chance to get it reviewed quickly is asking here from time to time (but not too often as that would have the opposite effect ;)). Especially on Fridays as then it's "REVU Day". [20:49] RainCT: thanks. will you do it? :) [20:50] RainCT, your assessment seems correct. sounds like incorrect use of p/invoke to me [20:51] yTTrayLib.cs: [DllImport ("gdk-x11-2.0")] [20:51] masterkernel: As a start, look at the Warnings REVU gives you on http://revu.ubuntuwire.com/p/kernelcheck; also please limit the description of the package to a technical (but understandable) description: it's not the right place to mention whether it's based upon a forum thread or who the authors of the original app are (this later information could go into debian/copyright) [20:52] RainCT: thanks, will do [20:54] RainCT, i'll pastebin a fix. too busy to upload myself [20:54] directhex: great, thanks [20:55] http://paste.ubuntu.com/200266/ [20:56] directhex: Oh, so easy? Thanks! [20:57] RainCT, mono tries a few values for remapping when given a dllimport - but it does NOT try adding a SONAME version [20:57] RainCT, which is why it resolves "gdk-x11-2.0" to "libgdk-x11-2.0.so" but not to "libgdk-x11-2.0.so.0" [20:58] basically "foo" is assumed to be interchangeable with "foo.dll" as per the spec, and mono remaps "foo.dll" to "libfoo.so" automatically [21:09] superm1: apologies for the delay in answering your e-mail; i'll address some points tomorrow [21:50] What is the preferred format for ubuntu packages - debhelper or cdbs? [21:50] vadi2: That depends who you ask. [21:51] IOW, there is no One Strict Way regardless what anyone tells you. [21:51] Yeah, that's what has been confusing me. Alright. [21:57] vadi2, rumors thought have it that dh 7 is the cdbs killer :) just rumors.. [21:58] Where can I find more information about dh 7? [22:00] dh 7 = debianhelper version 7, don't know where to find docs about it :( [22:00] debhelper* version 7 [22:00] /usr/share/doc/debhelper [22:00] man dh [22:00] : [22:00] :) [22:15] I am looking for a reviewer for my 'cadabra' package currently on REVU. It's a computer algebra system in C++, including a graphical notebook frontend with mathematics typesetting. [22:15] Any takers? [22:21] quiet night... [22:29] I am in need a reviewer for 'kernelcheck', a GUI that can auto-build any 2.6 kernel from the upstream source with custom patches, and install it as a deb file. [22:29] http://revu.ubuntuwire.com/p/kernelcheck [22:29]