START-INFO-DIR-ENTRY
I'm trying to package "xparam". Upstream has an sgml documentation that they processed into an info page. When I try to install the package produced containing said info pages, I get: No `START-INFO-DIR-ENTRY' and no `This file documents'. install-info(/usr/share/info/xparam.info): unable to determine description for `dir' entry - giving up The sgml is in linuxdoc format. I have not managed to find any references to producing a "INFO-DIR-ENTRY" section. Is it at all possible to do using linuxdoc-tools? I really don't want to start translating the entire SGML into a different format. Is it acceptable to have debian/rules add the relevant entry directly into the generated info page? What should said entry look like, anyways? I have not been able to locate any documentation on what it's for, or how to use it. Thanks, Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: START-INFO-DIR-ENTRY
Justin Pryzby wrote: >On Tue, Oct 11, 2005 at 11:32:52PM +0200, Shachar Shemesh wrote: > > >>I'm trying to package "xparam". Upstream has an sgml documentation that >>they processed into an info page. When I try to install the package >>produced containing said info pages, I get: >> >> >Unfortunately, I don't know anything about info format .. I'd suggest >looking at existing info pages, especially those generated by sgml >(and the mechanisms used for doing so). > > Thing is, SGML is a wildcard tags based language. For example, HTML is also an SGML language. The exact semantics of the language is defined by a template, and that one is different according to the interpreter you use. I found info pages generated by sgmltexi, but that doesn't help me at all. I will need to find info pages generted by linuxdoc. >>I really don't want to start translating the entire SGML into a >>different format. >> >> >This certainly shouldn't be necessary.. > > > So I have to stick to something linuxdoc can produce, but... >>Is it acceptable to have debian/rules add the relevant entry >>directly into the generated info page? >> >> >Surely; sed is your friend .. > Of course it is. The thing is, I'm then post-processing a generated file. That's not something I'm keen on doing. Getting the context right, so that the added line stays at the right point, may require awk, which I'm far less familiar with. > If you can come up with a patch to the >upstream source, that is, of course, preferable, and you should >forward it upstream. > Part of the problem is that upstream knows nothing about this as well. >>What should said entry look like, anyways? I have not been able to >>locate any documentation on what it's for, or how to use it. >> >> >Sounds to me like its the part after the ':' in > > 10.1 `ls': List directory contents > > I meant the syntax of the info file. Something should say "these are the mandatory fields, and this is their format". Havn't been able to locate such a text. Thanks anyways, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: START-INFO-DIR-ENTRY
Justin Pryzby wrote: >I still don't know anything about info format, but I just looked at >/usr/share/info/cppinternals.info.gz, which has, on line 5: > > START-INFO-DIR-ENTRY > * cppinternals-4.0: (cppinternals-4.0). Cpplib internals. > END-INFO-DIR-ENTRY > >So, > > sed -e '5s/^/START-INFO-DIR-ENTRY\n* cppinternals-4.0: (cppinternals-4.0). >Cpplib internals.\nEND-INFO-DIR-ENTRY\n/' > > Oh, I know how to add a line using sed. I'm just afraid that something in this change, not being context aware, will break in some future pacakge (i.e. - 5 will sieze to be the correct line number to add the section at). In order to do context I need awk, and I don't know awk well enough. In any case, I believe I found a clean(er) solution. >Maybe this isn't the right solution .. but hopefully a start. > >Have you looked at the package: linuxdoc-tools-info? > > Yes. I even downloaded the source package and greped "START-INFO-DIR-ENTRY" over the entire thing. Nothing. I made a search over my installed system, looking for any info file generated using linux-doc. Nothing. It seems that upstream made an ... uncomfertable choice of SGML language. The solution is this (so that the web archives have it): The demand for the problematic line is by the postinst script, that tries to register the info files in the system. This is the "install-info" command. RTFM on install-info shows that it will look for the "START-INFO-DIR-ENTRY" in the file, and if not found, will look for "This file documents...". If neither is found, it is an error *unless* you specify the --description option. The "install-info" command, in turn, is generated by dh_installinfo. I (will - not done it yet) switch to "dh_installinfo -n", and put the command it generated manually into postinst and prerm. I will then add "--description" to install-info manually. Pros: This is insensitive to changes to upstream source. Even if the info file changes, I don't need to track it closely for this solution to remain correctly. Cons: I lose the automatic nature of debhelper. I think this is the best solution to this problem at this time. I will also try to get upstream to change the phrasing to "This page documents...", but that will take a little longer. Thanks for everyone's help, Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: uebimiau
Muammar Wadih El Khatib Rodriguez wrote: > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/u/uebimiau/uebimiau_2.7.10-1.dsc > Did you repackage the source tar ball? This is, generally speaking, considered a bad idea unless there is a really good reason to do so. Use the original tarball as downloaded from the web whenever possible. debian/changelog - the "Closes #" text needs to be on the same bullet as the description of what it closes. "dch" is a good helper tool for editing the changelog. You have a dependency on "misc:Depends", but you never set it. Just remove the dependency. When writing the "description" line, imagine that the sentence has a "packagename is a" at the beginning. In your case, the description would be "Universal webmail developed in PHP". Consider whether the PHP part is really relevant (it can go in the detailed description part). When writing the detailed description, the first paragraph should be a more detailed version of the subject line. I.e. - repeat what the package is and what it does. Personally, I would change the bullets to remove the "it's", but that really a style thing. Remove the disabled debhelper lines in debian/rules. I'm surprised lintian doesn't complain about that one. You are running dh_install, so why not use that to copy the php files over to the installation directories? RTFM on dh_install for how to do that at a centralized file. empty lines at end of debian/rules and debian/uebimiau.links (and several other files under debian/) README.Debian: Consider putting an apache conf (via alias) that points a given URL to the webmail. Check out how phpmyadmin does that for paths. /tmp gets erased once in a while. It is not wise to recommend to people to trust files or subdirs under /tmp. It is much better to create the directory yourself (say, /var/cache/uebimiau) and pre-patch the relevant configuration file. In short, I would try to change the package so that the first 3 bullets are unnecessary, and the fourth unnecessary for standard installs. The rest of the bullets need to be merely informational. You create files under /usr/share that are group writable by www-data. Quoting FHS: > > The /usr/share hierarchy is for all read-only architecture independent > data files. > The only reason I can see that lintain did not complain about this is because, due to the way fakeroot was used, which means that the chgrp and chmod commands in your debian/rules did not have any effect. You need to recheck your installed package to make sure that it is: 1. Useable after a simple "apt-get install" and 2. Has the permissions you expect it to have. On a personal note, unrelated to the debian packaging, I'm taking a wild guess based on your name that you know how this webmail handles right to left sent emails, and sending BiDi emails. Otherwise, I'll be glad to sponsor this package when it's ready. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: uebimiau
Muammar Wadih El Khatib Rodriguez wrote: > Dear Shachar, > > Yes, I did it because the package was in *.zip and in Debian is needed > in *.tar.gz I'm not sure what the general policy is for repackaging in such a case. I think you are right, and it is necessary to repackage. HOWEVER, you included "build-stamp" in the package, which means that you packaged a built tree. Please be sure that, if you repackage the files, only to include those file which truly came from upstream. > Russ Allbery answered it, and it was what I read, too. Now I'm > confused so what should I do, remove it or leave it? Leave it. > I'm working on it. Ok, let me know when you have another version for me to check. > I really have to say I didn't understand what did you mean on your > personal note. Never mind. > I'll appreciate your sponsorship. Thanks a lot Shachar. No problem. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gambas2 (updated packages)
José L. Redrejo Rodríguez wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.9.46-1 > of my package "gambas2". There is a previous version uploaded to experimental. > After the upstream author has frozen the gambas2 byte code and Debian has > frozen etch, > I think it's already time to upload gambas2 to sid. > I don't think now is a good time to upload anything new to sid at all. Etch has been frozen, and every attempt should be made to make sure that Sid remains in a state where updates can be pushed from it to Etch, if necessary. This means that Sid should only contains changes really relevant for Etch. This is particularly true of packages that provide infrastructure for other packages. This means that experimental is the RIGHT place for gambas2, IMHO. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: uebimiau
Muammar Wadih El Khatib Rodriguez wrote: > I have made another version for you to check [0]. I'd be glad if you > check it. > > Thanks, > > [0] http://mentors.debian.net/debian/pool/main/u/uebimiau/ Hi Muammar A few comments: * First, the tar.gz you use has changes from the zip that you can download from the site, including a file that is only generated during the Debian build process. The two should be identical. The best thing for you is to, first thing, grab the zip file, extract it, and create the tar.gz. Only then do any Debian related work on it. * In debian/apache.conf, you have slightly inconsistent indenting policy (not crucial, but if we're fixing stuff, let's fix this as well). * Your default apache config should be to have http://whatever/uebimiau. Ideally, many users should not have to touch anything in order to start using the package once installed. Ideally, make sure that your current "apache.conf" is simply installed to "/etc/apache2/conf.d/uebimiau.conf" * In "README.Debian" - Uebimiau's Configuration. This should not be something that the user need to do after install. This is something that the package should do during install. Create the relevant directories using dh_installdirs, set the variables in /etc, etc. * /etc/uebimiau seems to contain php files that answer the title "plugins" much more than they do the title "configuration". These should not be under /etc. I'm not talking about config.php and the other config*.php, but on class.phpmailer.php and friends. This may require some patching to the code (for example, change "./inc/config.php" to "./conf/config.php" in all relevant places), but that's what the diffs that come with Debian sources are for. In any case, do not be tempted to patch your "upstream". This is what I found. Let me know how things go. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suggests vs. Recommends
Benjamin Mesing wrote: > * a plugin architecture package (which provides merely the > framework for additional functionality) without any additional > is useless by itself so it requires at least one plugin. > According to the policy wording this should qualify for a > depend? > No. What this means is that the plugins depend on it. The description can have some text saying "installing this on its own is meaningless". At best, it should have "suggests" for the plugins. > * Each plugin provides a certain amount of functionality (usually > one or more features) > I am not sure if this qualifies for Suggests or Recommends > Each plugin should "depend" on the core infrastructure. If each package has just one plugin (ala the apache/php modules), then it should "depend" on apt-file and whatever else is needed for it to actually work. If you combine all plugins into one package (for example, if you want people to be able to add their own plugins without installing all of the built-in plugins), then it depends on the necessity of the plugin. If the plugin is really really likely to be used, make its dependency "recommends". Otherwise make it "suggests". I really think, though, that the only clean way to handle this case is to split the plugins to one plugin per package. Hope I've helped. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to start porting to a new ARCHITECTURE?
David Given wrote: > You've got two major tasks ahead of you: > > - - port gcc > > - - port the kernel > > - - cross-compile a basic userland > Nobody expects the Spanish inquisition. Actually, there is one more major headache, which is porting a boot loader. Probably uBoot or something similar. Memory needs to be set up so it can be accessed by the kernel, the kernel (and initrd) pulled from the flash, and flow passed into it. If the system uses hardware controllers that exist elsewhere, the kernel port may be easier than that. It may be that the system has an ethernet controller that is already supported under Linux. Of course, the startup code and everything else under the "arch" directory will still need to be handled, but at least as far as the drivers are concerned, some work may be saved. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: rsyncrypto - rsync friendly encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a request for a sponsor for a package. The package is lintian clean, and has gone through some testing already. Name: rsyncrypto License: GPL Short description: encrypt files in a method friendly to rsync. i.e. - local changes in plain text result in local changes in cypher text. Long description (from the package's source): Rsyncrypto allows you to encrypt a file or a directory structure, such that they can later be synchronized to another machine using rsync. This means that local changes to the plain text file result in local changes to the cipher text file. Install rsyncrypto if you need to synchronize (using rsync) changing encrypted files over the network. Rsync is capable of detecting, and transferring, only the changed area of a file, thus being network efficient. Without rsyncrypto, any change to the plain text file will make the entire cipher text file, from the point of the change to its end, change. This will eliminate the network efficiency of rsync. rsyncrypto compresses the plain text file prior to encrypting it. This requires gzip with the "rsyncable" patch applied. Homepage: http://sourceforge.net/projects/rsyncrypto The package can be obtained from http://www.lingnu.com/debian, either by browsing and downloading or by setting an apt source: deb http://www.lingnu.com/debian ./ deb-src http://www.lingnu.com/debian ./ Thanks, Shachar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCFaz8g8ByFc29vOIRAjBVAJ94tD3TDedDZaU4ahvgX1fqEws/1gCgrWUa fKRCFA/KxbEeKoulp0mbcsg= =c7Y3 -END PGP SIGNATURE----- -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for an advocate
Nico Golde wrote: [...] It seems that many people don't see this document. Maybe it would be a good choice to include it as a special part in the NMG? Regards Nico As someone who has only recently tried to scale the "new developer" documentation, I can tell you that there is room for improvement. I have been going over those docs several times in the past few days, and each time I find myself lost in front of a page full of links embedded inside text, looking for the right doc I know is there, because I read it in the past. The amount of pages one needs to read just in order to find out what it is you need to read is huge. While I am lucky to be fluent enough in English, despite it not being my native tongue, I doubt many non-native English speakers even manage to get to the other end of it to find the debian-mentors list. Personally, I think it's a shame. Then again, I have not (yet, I hope) earned for my key to be placed in the Debian key ring, so one may say I have not earned the right to complain. I will say this. From reading the email that started this thread, I believe Martin was looking for a sponsor, not an advocate. Basically, he sent the right email to the right list, but mistook one jargon word for another. Frankly, I can empathize with his mistake. After all, I clean forgot to to file an ITP in the BTS for wnpp for my package... Shachar P.S. For those so versed in the jargon soup that the last sentence did not sound strange to them, it was supposed to be ironic (despite being factually true). -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for an advocate
Steve Kemp wrote: If you have constructive comments on how the pages could be improved for new maintainers they would be greatfully received either here on on the mailing list for website development, debian-www. Hmm, that's tough. To this point, I'm not sure I know everything that is there. I think, for starters, that the http://www.nl.debian.org/devel/join/ could be made into bullets. That would make it easier for people to know what they have done already, and what not. Maybe just have a link to a different page, or bullets at the end of the page with link from the top, saying "If you want to become a Debian Developer (DD), this is what you should know". There is a document on the site, though I couldn't find it the last five times I looked for it, explaining a step-by-step in creating a deb. This one should be the first one up there. And if you find it, do send me a link. I don't think I need it any more (my package is in sid's main queue), but you never know. If I remember it correctly, it even explains the sponsors and debian-mentors process. If it does not, then a very short document should be written outlining the process one has to go through. It should be the first one of the list. It should explain what ITP, DD, Sponsor and Advocate are, but it can probably leave out the front desk, DPL, and the rest of them. These can wait until our victim^H^H^H^H^Hfresh meat^H^H^H^H^Hpoor chap^H^H^H^Happlicant gets over some of the culture shock. I can tell you that there is going to be one. I am a Debian user since the mid potato era, a Wine hacker, and started quite a few of my own free software tools. I am a co-founder of "Hamakor", which is an Israeli NPO for promoting FOSS. In other words, I am by no means a free software newbie. It was a culture shock to me. I remember a night, several years ago, when a bunch of friends had dinner with a very excited Moshe Zadka, who couldn't stop talking-while-bouncing about him finally getting his DD status. At the time I just figured it was Moshez' special way of doing thing. Looking at the road still ahead of me reminds me a little of my military basic training. I will probably be just as excited (though no one can be as bouncy) as he was. Don't get me wrong - having talked about Stallman's four rights, (of which your doc only mentions three) and Bruce's Open Source definition for two years of activity on Hamakor, I'm pretty confident I can pass the requirement to show I know what FOSS is all about. I am literally doing it in my sleep for quite some time. All I'm trying to say is that a few words for starters saying "We're not trying to lock anyone out of some elite group, just to make sure no one taints this beautiful thing we've worked hard to build" would go a long way. After those, the document saying how and what should be in a package should come second (it is not even linked to from this page at the moment). Things like "work-needing and prospective packages" should probably be a sub-bullet of one of the above. In short, I don't really know what to say. I guess the inter-mixing of the explanation text and the links makes reading everything very difficult for me. I don't know whether that is an indication of a real problem, or merely a specific problem with my focus. Maybe speaking only the jargon does help people understand the jargon. After all, if you've passed all that it takes, you'll know your way around it. Then again, what does it do to those people for whom English is not as native as for most on this list? Why make their lives even harder? Also, and I think this is the thing that most made my life more difficult, I think the process should allow people who just want to package to postpone worries about the other stuff. After all, I may just wish to package for my own use. Hoping this proves useful, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hello
Zak B. Elep wrote: hello, world englishparse ZakB.Elep ZakB.Elep:1: error: Unterminated sentence. Did you forget a terminating "."? Parse failed -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Open ITP without apparent work on it
Hi all, Bug #269329 is an ITP for Open Xchange - the Suse server gone GPL. It's open since 31 Aug 2004, with a couple of people asking whether the original submitter is intending to release, but without any actual work done. My question is this - if I package the software myself, can I just submit it and close the bug? Or is it considered rude to just close someone else's ITP? I don't mind working on it, with the full risk of the original packager submitting a package before I manage to find a sponsore to mine etc. What I don't want happening, though, is that I'll work on it, submit and package, and then be told that this package cannot go in because someone else owns the ITP. So what's the procedure? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Open ITP without apparent work on it
Frank Küster wrote: Isn't there an "owner" tag for WNPP bugs? Then Shachar could set himself as the owner. Regards, Frank Learning from past experience, I'll only do that when I actually have a package working. No need to set everyone's hopes high if it turns out that I'll also not go through with it. Once I'm at the "RFS" for this package, then I'll set myself as owner. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Open ITP without apparent work on it
Shaul Karl wrote: On Wed, Mar 16, 2005 at 12:53:15PM +0200, Shachar Shemesh wrote: I don't mind working on it, with the full risk of the original packager submitting a package before I manage to find a sponsore to mine etc. What I don't want happening, though, is that I'll work on it, submit and package, and then be told that this package cannot go in because someone else owns the ITP. Be aware that there are claims that the handling of the NEW queue is slow. Take a look at the thread of this message http://lists.debian.org/debian-devel/2005/03/msg00166.html and http://kitenet.net/~joey/blog/entry/random_idea_re_new_queue-2005-03-02-21-12.html Oh, I know that. I have had a package in there for almost three weeks now. I asked not because I have a package ready (hence my refusal to take ownership of the bug - I don't know whether I'll scale the odds), but because I don't want to do all this work if it can be for-concluded it's going to be in vain. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Open ITP without apparent work on it
Laszlo Boszormenyi wrote: Hi Shachar, Matthew, Riku, Daniel, On Wed, 2005-03-16 at 22:42 +1100, Matthew Palmer wrote: On Wed, Mar 16, 2005 at 12:53:15PM +0200, Shachar Shemesh wrote: Bug #269329 is an ITP for Open Xchange - the Suse server gone GPL. Yes, the Open-Xchage code is GPL, but last year there was a (small) chance as far as I can remember that it is going to be closed again, or at least have a non-DFSG compatible license. The thing that prompted me to ask was this. I was in a conference a couple of days ago (HP Linux roadshow), and Suse's CTO was there. When he was asked about an exchange replacement he mentioned this, as well as all sorts of other solutions. When I talked to him after the conference, he said that Netline's opening up the code was a result of pressure from Novell. Whether that actually changes anything or not - I don't know. Also, note that OX can not be compiled without non-free 'libs' (ie jars).Thus OX should be in contrib if it is packaged. Well, as I see source of JavaMail recently released under the Java Research License, so I should look into it if that helps in the case or not (ie compiling the source for ourself, do a package and use it). It seems upstream is not going to use free JavaMail implementations, see my mails and the replies in the past[1]. So a quick test with GNU JavaMail still gives a lot of compilation problems (just an example): [javac] /home/gcs/open-xchange-0.8.0-beta4/src/com/openexchange/webmail/folder/WebmailFolderUtilities.java:52: package com.sun.mail.imap does not exist [javac] import com.sun.mail.imap.IMAPFolder; [javac] ^ I'm afraid I created false expectations. That was not the intention. The order of things was "Hmm, let's see if it's in Debian", followed by "Maybe I can package it", followed by "It already has an ITP, but no >apparent< activity." I then wondered whether it's worth the time to look at it, or whether things were badly out of shape. I'm afraid that people, probably out of sheer desire to see this package in, assume I'm further along the road than I really am. I assure you, had there been a package ready, the title would have said "RFS". You are _almost_ right. Sorry about that. The subject of the thread better describes what I meant to say. On the other hand, I had a terrible car accident, was in hospital for months (my scull and some ribs broke, was in something like coma [deep sleeping as my doctors say]). I am still not fully healed, but much better by now. And may you have a complete and quick recovery. A friend of mine lost all short term memory after an accident for almost a month. Conversation would go "Where am I? In a hospital. What happened? You were in an accident. Can I have a mirror?", at which point the conversation would start over. After about a month of this, she said "This mirror looks familiar". She lost two semesters. One in which she didn't study because she was in the hospital, and another in which she did study, but was totally wiped from her memory. Her lesson - don't drive a motorcycle. Yes, you can, at least I permit it to any of you as I am the original bug submitter. Also, if the license issues can be solved (ie OX can be ported to any of the free JavaMail implementations; but then the one doing it should follow OX development and update the port on the long run), then I would even sponsor the upload, as I am a Debian Developer. I think I'll try to package it one was or the other. If it goes into contrib as a first stage, fine. If not, I'll put it on an unofficial site. All this assuming, of course, I scale the odds :-/ I do want the package in main, but I don't know how difficult it will be to: 1. Make sure it compiles with free build tools. 2. Get upstream to include this. I am free to give away it; and hope the noted things can be solved. At least OX remained open with the 0.8beta releases, but compilation issues with free tools still should be done. I was far to finish it, and the codebase changed a lot since then. :-| And you were further down along the road than I am now. Don't get your hopes too high. If I manage to get this rolling, I'll check in here again. Well, yes, it is something like an extended holiday. :( I am still on my way to get back my life straight (get back my workplace, restart studying for my second degree somewhen but more importantly to get healed fully) as well. Good luck with that. (In Hebrew, the parallel for "good luck" translates as "may you succeed", which I find more appropriate. Then again, I may have been conditioned). I don't mind working on it, with the full risk of the original packager submitting a package before I manage to find a sponsore to mine etc. We can stay in contact if yo
Re: Complex Depends
Nicolas Boullis wrote: Wow... It would really be nice to enhance the syntax for dependencies... An idea I have been harboring for quite some time, and which bears some (though not very much) relevance to this thread, is a reverse dependency. The idea is this: Package "wine" has wine. Package "kde" has kde. Package "wine-kde" has the wine integration into kde. This package reverse depends on "kde" and "wine", which means that if both "kde" and "Wine" are installed, then "wine-kde" is automatically installed too. The idea is that it is installing kde and wine that triggers the installation of "wine-kde". To understand why this is useful, consider webmin. If we could make webmin-samba reverse depend on samba and webmin, no one would ever have to figure out whether there are any more useful webmin modules they can install for their system. It would all be automatically done by aptitude. Merely installing samba on a system where webmin is installed will bring webmin-samba in as well, without making samba depend on webmin or vice versa. Obviously you can have reverse suggests and reverse recommends as well. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Create user during installation
Hi all, This question is about a package that will likely not make it into Debian (too specific). I even suspect this has some relevance. I would like to install a package that creates it's own special user and group during installation. I have utterly and totally failed to find a ready made package that does that, with the sole exception of qmail-src (from non-free) that creates them in the 655xx area. Not exactly what I would like to do. How do I create said user and group? How do I tell between useradd or adduser failing due to user already existing, and other unrelated reasons? Do I at all need to care about that? Help would be greatly appreciated. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Create user during installation
Tilman Koschnick wrote: On Thu, 2005-03-31 at 22:18 +0200, Shachar Shemesh wrote: Hi all, This question is about a package that will likely not make it into Debian (too specific). I even suspect this has some relevance. I would like to install a package that creates it's own special user and group during installation. I have utterly and totally failed to find a ready made package that does that, with the sole exception of qmail-src (from non-free) that creates them in the 655xx area. Not exactly what I would like to do. How do I create said user and group? How do I tell between useradd or adduser failing due to user already existing, and other unrelated reasons? Do I at all need to care about that? Hi, grep for 'adduser' in /var/lib/dpkg/info/*postinst to see some examples. You can use getent(1) to check for the existence of a user. Here is what I do (package gpsd): postinst: |# create user gpsd |getent passwd gpsd > /dev/null || \ |adduser --system \ |--home "/nonexistent" --no-create-home \ |--disabled-password --ingroup dialout \ |--gecos "GPS daemon user" gpsd postrm: | if [ "x$1" = "xpurge" ] ; then | getent passwd gpsd > /dev/null && deluser gpsd | fi Cheers, Til Ok, I'll explain a bit on what I'm trying to do. I have a web application which needs to perform actual tasks in the system. These tasks do not require root access, and so I would much rather not give it root access. I would also prefer not to give it access to everything that runs under the web server. The solution was to put up a helper program that asks for password and performs the actual operations. This program would be suid to a new user in the system dedicated to that task. Now here's the thing I'm trying to figure out. I need to create several files owned by this new user I'm creating, with one of them actually suid. In addition, I need to set the group of the suid file according to whatever group whichever process that runs my web server is running as. One way to do it would be to perform all permissions change in the postinst. I know that this is what ssh does with ssh-agent. Another package I looked at was qmail. It stores the file qmail-queue with full permissions inside the package, but it creates the users in qmail.preinst, and hardcodes the uids into it. I guess this is not an option. Now it may very well be that creating the file ownership and permission at postinst is the only way. If that's the case, I'll just do it. I just wanted to make sure. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A couple of questions
two questions: 1. My package has a password file. Where is the best place to store it? /etc/name/password? /var/lib/name/password? 2. I have placed some file names into debian/conffiles. It seems, however, that all files under /etc are logically added to it as well. Files under /etc that I explicitly list as conffiles are listed twice on /var/lib/dpkg/info/name.conffiles after installation. This is not good, especially if option #1 above is taken. Can anyone explain why/how to stop the scripts from marking all files under /etc as configuration files? thanks, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A couple of questions
Florent Rougon wrote:
Shachar Shemesh <[EMAIL PROTECTED]> wrote:
two questions:
1. My package has a password file. Where is the best place to store it?
/etc/name/password? /var/lib/name/password?
If the password file is a system configuration file (i.e., a file that
can be customized by the admin to modify the behavior of the program),
it belongs to /etc. Otherwise, it should be placed elsewhere. See the
FHS.
Well, you would need a helper program to actually change it, as the
password is encrypted. Otherwise, yes it's a configuration file.
2. I have placed some file names into debian/conffiles. It seems, however,
that all files under /etc are logically added to it as well.
This is a feature of dh_installdeb in debhelper compatibility levels 3
and above. cf. debhelper(1).
Saw it. Thanks.
Files under /etc
that I explicitly list as conffiles are listed twice on
/var/lib/dpkg/info/name.conffiles after installation. This is not good,
especially if option #1 above is taken. Can anyone explain why/how to stop the
scripts from marking all files under /etc as configuration files?
1. You are confusing conffiles and configuration files. These notions
are explained in the Debian Policy Manual.
I read the policy manual. I even reread it now. It says:
10.7.1 Definitions
The distinction between these two is important; they are not
interchangeable concepts. Almost all conffiles are configuration
files, but many configuration files are not conffiles.
Note that a script that embeds configuration information (such as most
of the files in |/etc/default| and |/etc/cron.{daily,weekly,monthly}|)
is de-facto a configuration file and should be treated as such.
10.7.2 Location
Any configuration files created or used by your package must reside in
|/etc|. If there are several, consider creating a subdirectory of
|/etc| named after your package.
Debhelper(1) says:
V3 This mode works like V2, with the following additions:
- Every file in etc/ is automatically flagged as a conffile by
dh_installdeb.
You are right, I am thoroughly confused. It seems to me that if I follow
the policy version 3 or above (and we all agree that I should), then
every configuration file (that must be placed under /etc according to
10.7.2) will also be a conffile, contradicting 10.7.1.
While I am confused, I have to say your explanation did not help me. The
way I see it, a password file is a configuration file, but not a
conffile. All configuration files, be them conffiles or not, should go
into /etc, but debhelper compatibility version 3 (and, by induction,
version 4) does not allow me to place a file there that is not a
conffile. It seems to me that the standard is self conflicting.
2. This is probably a bad idea, but I suppose that setting DH_COMPAT to
2 or below just for the dh_installdeb invocation would do the trick.
I agree. It is a bad idea. Give me another option.
I am either utterly and totally misunderstanding the standard here, or
the standard makes it impossible to create standard conforming
applications in some circumstances.
Help?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A couple of questions
Justin Pryzby wrote: If you want a non-conffile configuration file, then you must not provide the file in the package. Instead, create the file at install time (not compile time) with the maintainer scripts (postinst usually). If its a complicated file, store a template in /usr/share/pkgnamehere/... Justin Thanks. That did it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A couple of questions
Florent Rougon wrote:
In case Justin's mail didn't answer all your questions...
It did.
Shachar Shemesh <[EMAIL PROTECTED]> wrote:
Well, you would need a helper program to actually change it, as the
password is encrypted. Otherwise, yes it's a configuration file.
Well, the line is a bit blurry here, I admit. Note that passwords in
/etc/shadow are encrypted, but the admin can still modify the
(encrypted) passwords by hand in that file. This is not an argument
against placing the file under /etc.
IMHO, whether /etc or /var is more appropriate depends on whether you
consider the file as configuration data for the program, or not.
Specifically, do you expect an admin to simply copy that file to another
system if he wants the same passwords in the other system? If yes---and,
I am tempted to say, if the file is in text format, because seeing
binary stuff under /etc kinda hurts my eyes---, then I'd choose /etc. If
not (i.e., if you consider the file as simply storing a "state" for your
program), /var sounds more appropriate.
I think it's fairly clear, then, that /etc it is. The file is text
(crypt, mostly because I didn't find any immediate way of using more
sophisticated hashes from perl, and the information it protects is
available to you if you can read it anyways). It is maintained by the
package, but can be copied over to another machine if the same password
is required there.
The package is a wrapper around rsyncrypto that provides a web interface
for controlling a remote backup that my company is supplying (see my sig
for details). I have placed the files as follows:
Config files, including password and the ssh "known_hosts" for the
backup machine in /etc (the later is a conffile).
The rsyncrypto symmetric keys for the backed up files in /var/lib. They
are needed in order to perform hot restore and incremental backup.
The actual encrypted files in /var/spool.
The HTML files, and the suid script that allows the unprivileged web
server to perform cron and other tasks go in /usr/share/package with a
link from /var/www (same as bugzilla).
After your explanation, the only thing I still have doubts over is
whether the files should not go into /var/cache instead.
It does. Just don't ship it in the .deb, but as Justin said, have it
created by postinst, or by one of the programs shipped in the package,
for instance.
That's not a problem. The initial password is an empty file. Since it
has a different owner and non-standard permissions it's a bit of a
headache to create and remove properly in post{inst,rm}, but no big deal.
Thanks for your help,
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A couple of questions
Florent Rougon wrote: Shachar Shemesh <[EMAIL PROTECTED]> wrote: After your explanation, the only thing I still have doubts over is whether the files should not go into /var/cache instead. Erm, which files? During the process files are encrypted. Their key is stored under /var/lib/name, and the encrypted files themselves are stored under /var/spool/name. The key is used to perform repeatable encryption on the same files in the future, but the encrypted files are only used in order to rsync to another machine for backup. The save on performance, because if a file didn't change, it will not be re-encrypted, but they are, in theory, reproducible from the available data. The slight dilemma is whether /var/cache or /var/spool would be a better choice. I'm leaning towards spool, as they tend to be big, and it would really be better not to erase them. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Splitting package
Benjamin Cutler wrote: The debian/control file should look something like: Package: foo-common Conflicts: foo (<< 7.6.5-2) Replaces: foo (<< 7.6.5-2) Why the "Replaces"? I would have expected that would only be necessary if there was no longer any "foo" package. Whether you use <= or << is mostly a matter of taste, but make sure you understand the difference, of course. ;) Using << is good because it means we can post fixes to the old package (7.6.5-1.1), and it would still be in the correct rule. Why would I want to use <=? Shachar Who has nothing at all to do with either the original question or the problem, but is interested in the reasoning non the less. -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
should I talk to upstream?
I intend to package a project called "argtable", mostly because I want to use it in my own package, rsyncrypto, in order to make it less Linux specific. There are two issues that come to mind: 1. The source directory naming of upstream is "argtable2", instead of the expected "argtable-2.4". 2. The author seems to keep the "1" series version around, since version 2 introduced some incompatibilities. I intend to ignore the second problem, so that if it ever comes up we can call the other argtable "argtable1". What should I do about the first problem, though? Should I repackage the original source (and remove on of the examples compiled for FreeBSD left behind in it, while at it). Should I use the original source package as is? Should I contact upstream and ask him to change the way he names the directories? Any help would be greatly appreciated. A few URLs: Package homepage: http://argtable.sourceforge.net/ I'm still waiting for the ITP tracking number to come through. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should I talk to upstream?
Shachar Shemesh wrote: I'm still waiting for the ITP tracking number to come through. Shachar No sooner had I sent this, and the ITP came through. Bug #306755 Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian QA system lecture at Haifux - help needed
Hi all, Haifux and Telux are two LUGs in Israel that promote information sharing. In particular, we believe in making people learn new stuff by committing to lecture about them :-). I entered such a commitment to give a lecture called "The Debian QA system". The lecture's abstract follows: Debian is a community Linux distribution (and some say THE community Linux distribution). It is most unique in having tens of thousands of packages on one hand, and yet allowing a smooth end-user experience in which every Debian package is a single "apt-get install" away on the other. In order to achieve this goal, a complex set of strict QA and developer certification procedure exists, which tries to make sure, in as automatic a way as possible, that the debs packaged for Debian will work. This lecture will give an overview of debianizing an open source project. More importantly, it will talk about the process a package has to go through in order to be considered a part of Debian's "main" archive, with a special focus on software QA processes. (http://www.haifux.org) Subjects I'm going to cover are: 1. The basics of creating a deb 2. Standard package naming and file locations 3. The Debian human hierchy (from the sponsored maintainers to ftpmasters, possibly even up to DPL, if I'll think it's relevant). 4. The automatic QA tools (pbuilder, lintian, linda) 5. The tools that help keep it all together - dch, uscan, dupload, dpkg-buildpackage I'll also not lie, I'm doing this to help me learn the turf toward becoming a DD myself. Thing is, as mentioned above, I'm doing this in order to learn this. I'd love to hear from the mentors here about any other tools that may be worth looking into. Things I know I don't know include: someone mentioned a tool for tracking the Debian directory in CVS and SVN. There is an archive of all past Debian packages, which I can't seem to locate. Of course, there are also the things I don't know I don't know, and I would love to hear about those as well. Many thanks, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Changed upstream dependancy
Hi all, "rsyncrypto" is a package I'm maintainer for (using sponsored uploads). Upstream for the package (which is me) changed the package's dependency to include "argtable" (a library for gnu-like option processing). Argtable doesn't have a Debian package (yet - Bug#306755. I'm the proposed maintainer, but not upstream this time). Now here are the questions: 1. What is the correct order of things? Should I first upload a package for argtable, wait for it to pass ftpmasters, and only then upload the latest rsyncrypto version, or should I upload both, knowing that rsyncrypto will be uninstallable (and uncompilable) until argtable is accepted? 2. I cannot seem to get a response from my sponsor at the moment. I asked him whether he would like to sponsor argtable as well (being as it is that they are now related). If he turns out MIA, what is the procedure I need to follow? Reissue a RFS for both packages? Thanks, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian QA system lecture at Haifux - help needed
Shachar Shemesh wrote: Hi all, Debian is a community Linux distribution (and some say THE community Linux distribution). It is most unique in having tens of thousands of packages on one hand, and yet allowing a smooth end-user experience in which every Debian package is a single "apt-get install" away on the other. In order to achieve this goal, a complex set of strict QA and developer certification procedure exists, which tries to make sure, in as automatic a way as possible, that the debs packaged for Debian will work. This lecture will give an overview of debianizing an open source project. More importantly, it will talk about the process a package has to go through in order to be considered a part of Debian's "main" archive, with a special focus on software QA processes. Hi all, It's not ready yet (totally incomplete), but if anyone is interested in have a look at the unfinished work, it's available (in OpenOffice format) at http://www.lingnu.com/tmp/Debian%20QA.sxi. Any feedback would be welcome. I'll keep updating it during the day, as I further write the lecture. Thanks, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian QA system lecture at Haifux - help needed
Shachar Shemesh wrote: Hi all, Haifux and Telux are two LUGs in Israel that promote information sharing. In particular, we believe in making people learn new stuff by committing to lecture about them :-). I entered such a commitment to give a lecture called "The Debian QA system". The lecture's abstract follows: Debian is a community Linux distribution (and some say THE community Linux distribution). It is most unique in having tens of thousands of packages on one hand, and yet allowing a smooth end-user experience in which every Debian package is a single "apt-get install" away on the other. In order to achieve this goal, a complex set of strict QA and developer certification procedure exists, which tries to make sure, in as automatic a way as possible, that the debs packaged for Debian will work. This lecture will give an overview of debianizing an open source project. More importantly, it will talk about the process a package has to go through in order to be considered a part of Debian's "main" archive, with a special focus on software QA processes. (http://www.haifux.org) Subjects I'm going to cover are: 1. The basics of creating a deb 2. Standard package naming and file locations 3. The Debian human hierchy (from the sponsored maintainers to ftpmasters, possibly even up to DPL, if I'll think it's relevant). 4. The automatic QA tools (pbuilder, lintian, linda) 5. The tools that help keep it all together - dch, uscan, dupload, dpkg-buildpackage I'll also not lie, I'm doing this to help me learn the turf toward becoming a DD myself. Thing is, as mentioned above, I'm doing this in order to learn this. I'd love to hear from the mentors here about any other tools that may be worth looking into. Things I know I don't know include: someone mentioned a tool for tracking the Debian directory in CVS and SVN. There is an archive of all past Debian packages, which I can't seem to locate. Of course, there are also the things I don't know I don't know, and I would love to hear about those as well. Many thanks, Shachar Final version of the lecture's slides, as given, is available at http://www.lingnu.com/tmp. It will be moved from there to http://www.haifux.org soon. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package name
Hi list, I'm trying to package argtable (http://argtable.sf.net). I'm wondering about the names to give the package. The package itself had two major life cycles. As such, the source library is called "argtable2". As far as so version goes, it has version 4. Obviously, I will need to ad a "lib" at the beginning. At the moment, I have this: source package: argtable2 shared object: libargtable2-4 devel: libargtable2-4-dev I'm having doubts about all choices, however: Should the source be named "argtable"? It seems that upstream is not particularly interested in maintaining the "1" series around, but one never knows. They are clearly and utterly incompatible, however, and there is some slim chance that someone will want to package "libargtable1". Should the "dev" be named with the so version? The policy says it should, but the "2" is really confusing here. In general, I have a suspicion that the "2" was really meant by upstream to mean what "soversion" means, and so the package should really be named "libargtable4". This will be WAY too confusing for actual users of argtable, however. Your thoughts on the matter would be greatly appreciated. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package name
Philipp Kern wrote: On 20.05.2005, at 08:31, Shachar Shemesh wrote: The package itself had two major life cycles. As such, the source library is called "argtable2". As far as so version goes, it has version 4. Obviously, I will need to ad a "lib" at the beginning. At the moment, I have this: source package: argtable2 shared object: libargtable2-4 devel: libargtable2-4-dev (Donated by Steve Langasek) $ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/^[[:space:]] *SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//' libargtable2-4, then. I used that script to decide on the name to begin with. For the devel package I would take the binary package name without the SONAME like libargtable2-dev. Probably a good idea, yes. I'm having doubts about all choices, however: Should the source be named "argtable"? It seems that upstream is not particularly interested in maintaining the "1" series around, but one never knows. They are clearly and utterly incompatible, however, and there is some slim chance that someone will want to package "libargtable1". How is the tarball named? argtable-2.x oder argtable2-1.x? The tarball is named argtable-2.4.tar.gz. You can still download argtable-1.4.tar.gz. Then again, opening the first tarbal produces a source directory called "argtable2" (no version). The final library is named "libargtable2.so.4" (no 4.0.0 or any other libtool standard). The original library didn't have an SOVERSION, and I had to patch the Makefile in order to put one in (will be sent to upstream as soon as the package is finalized). Kind regards, Philipp Kern Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package name
Neil Williams wrote: On Friday 20 May 2005 7:31 am, Shachar Shemesh wrote: Hi list, I'm trying to package argtable (http://argtable.sf.net). I'm wondering about the names to give the package. Is this the next release? There's already a .deb for argtable2 on the website, although not in Debian itself. No, it's the same release. The deb file there is an alienated RPM, and is not in a state that can go into Debian. argtable-2.4-0_i386.deb (precompiled binary, 765KB) http://argtable.sourceforge.net/ If your package is binary compatible with argtable-2.4.tar.gz then it should respect the current naming. You only get a chance to move things around at the next binary incompatible release. I'm not sure binary incompatible is strictly defined with argtable. See below. i.e. if your package can be switched for the existing .deb on a user's system and programs, scripts and processes using the library continue to function without relinking, then your package should have the same naming. Only if it breaks something that already runs with 2.4 should it be renamed. But having a library without a "lib" name breaks and confuses things. Wouldn't it be better to produce a transition package (i.e. - argtable-2.4-1 which depends on libargtable2-2.4-1, with a description saying "you don't need this package unless you are upgrading"?). The package itself had two major life cycles. As such, the source library is called "argtable2". As far as so version goes, it has version 4. What do you get from objdump ? Nothing useful. Upstream was calling the end library "libargtable2.so.4", but not linking the version into the binary at all. I added that (hence the "4"), but now that I come to think of it, upstream was probably trying to encode the "2.4" into the name, and did not mean binary incompatibility by it. If that's the case, the so should, by right, be called "libargtable.so.2". Problem is, changing it now will probably break stuff. I had a similar query a week or so ago and the library SONAME should depend on binary incompatibility, not file package versions. I only know realized it did. Obviously, both I and upstream will have to figure the best way out of this. You say it's had two life cycles, all you need to do now is work out if your package is going to be binary incompatible with the last one. Forget the history of it - you can't correct that now and you can't skip an increment to make it look neat. Whatever SONAME you get from objdump of the current package, if the new library is binary incompatible with that, increment the SONAME. Problem is, the only reason I'm getting anything at all from SONAME is because I patched the build system. When SONAME has nothing at all, can that be considered a version "0"? If so, we can set it to "2" and solve all problems - leave a place if anyone decides to package version 1, and yet be compatible. See the archive: http://lists.debian.org/debian-mentors/2005/05/msg00057.html That's what triggered the question to begin with. Obviously, I will need to ad a "lib" at the beginning. I was wondering about that - IS it actually mandatory? I've got: qof-0.5.2.tar.gz I can have a package name: qof1 leading to a library of qof1.so It'll be installed as a library, determined by debian/control, but does the file actually have to be prefixed lib to make libqof1.so? I think you'll find it hard telling your linker that you need it. You won't be able to simply do "-lqofl". In any case, I'm not talking about the actual library file. That already has the "lib" prefix. I was talking about the package name. Even a library package that doesn't have a "lib" prefix is somewhat bad. Some of the tools that do automatic removal of unused libraries take the package name as an indication to whether it's a library. At the moment, I have this: source package: argtable2 shared object: libargtable2-4 devel: libargtable2-4-dev I thought it would be libartable2-dev? The site proposes that ArgTable2-x is one set - one introduction, one manpage and set of examples. Updates and releases that maintain binary compatibility with other argtable2 releases are within argtable2 and there's no need to specify the minor or patch version numbers. As I said above, I'm beginning to question the "-4" for the main package name as well. Also, if you increment the SONAME, the other versions in the library soname go to zero, usually. There are none of those at all, at the moment. I suspect we're looking at libargtable3 here, with libargtable3-dev. Don't confuse the SONAME version with the source package version - the two don't need to be linked. You can maintain the existin
Re: Volk wird nur zum zahlen gebraucht!
Philipp Kern wrote: On 20.05.2005, at 10:35, Netty Tielemans wrote: no email s.v.p. There is currently a flood of right-wing German SPAM. This results out of Windows boxes infected with Sober. It harvests random email addresses and uses them for outgoing emails. I advise to just kill those messages containing one or two URLs at the beginning and looking German. Kind regards, Philipp Kern I think merely marking the list "subscribers only" would do the job better. It would also leave most of the spam out of it. -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package name
Neil Williams wrote:
On Friday 20 May 2005 10:22 am, Shachar Shemesh wrote:
No, it's the same release. The deb file there is an alienated RPM, and
is not in a state that can go into Debian.
So your options for this one are limited - you need to retain binary
compatibility and can't go changing the SONAME or package name without
breaking things. You CAN implement a SONAME where one is missing, but I don't
see that skipping 1 is going to be any good.
I think a more interesting question is whether I can NOT implement
SONAME where one is missing? It seems that upstream does not like the
idea of SONAME, and prefers to do without it. I wouldn't have insisted,
except that without SONAME the package is not lintian clean.
I have still not totally given up on convincing him, though, so I'll be
in touch :-)
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package name
Steve Langasek wrote: I have still not totally given up on convincing him, though, so I'll be in touch :-) It's not acceptable to install a shared library without an SONAME for two reasons: - if the library's ABI changes and the filename doesn't change, the new library package will have to conflict with the old package, forcing removal of all other packages using the old version of the library - if at a later date upstream comes to their senses and starts using an SONAME for their shared library, the *-dev* package will still have to conflict with the old library package for the same reason, forcing removal of packages depending on it But if I do introduce SONAME to the Debian version, what version should it have? The only sensible answer that I can think of is "0", as any other answer is sure to conflict with the upstream choice, should they come to their senses in the future. I don't see the major difference between saying "SONAME" version 0 and not giving SONAME at all, but I don't mind it so much either. Introducing an SONAME to a library in Debian when it doesn't have one upstream isn't great, but the only sensible alternative is to not ship it as a shared library at all. Another thing that comes up is an incompatibility between the deb currently provided by the site (as well as binaries compiled with libargtable compiled from source) and the deb we would provide. Binaries compiled with the former two will depend on "libargtable2.so", while binaries compiled with the later will depend on "libargtable2.so.0". I can fix it by including the symlink from libargtable2.so to libargtable2.so.0 in the non-dev package, I think. Will it work? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
performance tip for the package development stage
Hi all, I'm sorry if this is well known. I haven't seen it anywhere, and I thought I'd share it with everybody. During the initial package development stage, there is a lot of repeated compilation of the same package over and over again. With some packages that's not so bad, but some take a long time to compile. I'd like to draw people's attention to a small program that can greatly help. It's called ccache, and this is the effect it has on my system. When compiling a package called "xparam" for the first time, these are the timing results (dpkg-buildpackage, including clean) real9m44.129s user7m48.328s sys 1m5.499s The second time around, these are the results: real1m50.366s user0m58.678s sys 0m27.084s It works by caching the output (both stdout/stderr, and the file output) of the compiler, and performing md5 on the input. If the same input is given, it will produce the same output. In order to set it up, apt-get install ccache. Then create a directory somewhere and put there symlinks from cc, gcc, c++ and g++ to /usr/bin/ccache. When you want to make use of this feature, add this directory to the beginning of your path and work as you would always work. Personally, I wouldn't use this for compiling the package after you have done with the debian related development, but the ccache author claims it's totally safe for that as well. I hope people find this tip useful. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package name
Steve Langasek wrote: But if I do introduce SONAME to the Debian version, what version should it have? The only sensible answer that I can think of is "0", as any other answer is sure to conflict with the upstream choice, should they come to their senses in the future. I don't see the major difference between saying "SONAME" version 0 and not giving SONAME at all, but I don't mind it so much either. An so version of 0 is the simple so version least likely to conflict with upstream's versioning in the future. If you're worried that you may have to go through ABI changes on your own before upstream gets around to the whole sanity thing, then it's probably best to use a Debian-specific so versioning scheme: e.g, libargtable2.so.0debian0, libargtable2.so.0debian1, etc. You can find examples of such library package names in the archive. No, I think I'll go with "0". Another thing that comes up is an incompatibility between the deb currently provided by the site (as well as binaries compiled with libargtable compiled from source) and the deb we would provide. Binaries compiled with the former two will depend on "libargtable2.so", while binaries compiled with the later will depend on "libargtable2.so.0". I can fix it by including the symlink from libargtable2.so to libargtable2.so.0 in the non-dev package, I think. Will it work? If you include that symlink in the non-dev package, you have the same problem as before with packages needing to conflict with one another. That being the case, I don't think you have any responsibility to work around upstream's broken .debs in your Debian packages. Lost you there. If the symlink is there for the non-dev, who am I conflicting with? Assuming I make sure that libargtable2 is not installable while argtable2 is on the machine (by either doing "conflicts" or providing an upgrade package), what are the risks? Even if some future version of argtable introduces versioning, the dev package always depends on the non dev of the precise same version, so it seems I'm not blocking any future upgrade path here. Am I missing something here? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a library.
to be, rather than as it is. As it is, punx cannot TECHNICALLY perform a GPL violation with his code, as he is the copyright holder, and does not need anyone's license in order to distribute the code. As the GPL only applies where a copyright license is needed, punx is not bound by it. Without the exception mentioned above, this would put everyone into the awkward situation where the code is GPL, but it cannot be compiled as distributed without yanking fmod out. This would definitely put potential users of the library in a tough spot, but does not make the code any less free. I'll also mention that I have my own doubt regarding how necessary this exception is. I documented them in the "COPYING" file for rsyncrypto, if you're interested. I tried to give an online pointer to the file, but the SourceForge WebCVS gateway is down at the moment. Either apt-get install it and look at the license file, or go to http://sourceforge.net/projects/rsyncrypto, hope that the webcvs is back by the time you look, and look at the COPYING file in the source CVS tree. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a library.
Neil Williams wrote: If yes, what license would be best ? There are so many, I wouldn't know where to start. I'll put in my 2 cents, then. There are TONS of free licenses, but for all intent and purposes, I really suggest you answer to yourself a couple of basic questions, and choose one of three licenses according to the answers. First question - do you want to insist that anything your write and release as free code will remain free, no matter who or what? If the answer is "no", take the three clause BSD license or the X11 license. Bear in mind that abuses have happened in the past. One example that is close to my heart is Wine. It started as an X11 license. A company called Transgaming kept using it commercially, performing development over it, but the almost all the contributions the community saw back from it were in the forms of promises (if we sell X licenses, we'll release the Direct3D code) which never transpired. Eventually, all further development was switched to a license that does not allow such behavior (LGPL). If you don't like the idea that this should happen to your code, don't go for the X11 license. If you don't think there is anything wrong with it, the X11 license is what you want. Second question: Is it ok with you if code you write will be used as a library that is used by potentially non-free software? If you only want your actual code to remain free, and don't particularly care how it's used, go with the LGPL. If you want all code which makes use of your code to be free as well, go with the GPL. Three licenses. There are some things to bear in mind here too, though: If you go with the LGPL, always remember that someone may create any APIs they want out of your code, including APIs that are cut in different locations than where you intended them to be. In effect, making code LGPL protects the actual algorithmic implementation, and very little else. Conversely, bear in mind that the GPL only reaches as far as the copyright law lets it. There are cases today where a non-GPL program is using GPLed library/provider, and people have accepted it as a non-derived work relationship, which follows that the program is not required to be GPL as well. Whatever you do, please avoid licenses outside those three unless there is a REALLY good reason. The most important feature of these three is that they are all upward compatible, and are fairly well understood. Writing your code with either one of these three licenses maximizes the amount of projects that can use your code, as well as the number of other people's code you can use. and if you do use the exception, make that clear too as it does have implications for those who would modify or distribute your code. Actually, the GPL exception was intended precisely so that it doesn't gravely implicate people using your code. The use of a non-free library, however, is something that needs to be pointed out clearly. In the same way, if I wrote a program using java (Sun), could i distribute it under the GPL license ? That would be the LGPL, if I read the gnu site correctly, but I don't use Java at all, so I haven't really looked at that. I think you misread it. The GPL specifically allows you to use libraries that are part of the development tools. Java clearly is. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package name
Steve Langasek wrote: The risk is that you can't install the new -dev package on a system that has the old lib installed, because they conflict. One normally wants to be able to build and test binaries for a new library *before* purging the old version of the library... But the -dev package always depends on the non-dev of the exact same version. This means I cannot install the new version without upgrading the library itself anyways. What am I missing here? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a library.
#x27;s important when the question of whether or not a GPL violation took place. I don't need the GPL's permission (or, alternatively, such permission is granted to me under section 5) to do stuff locally with your program. As such, I don't think the fact that your binary and my library are loaded into the same address space is any criteria at all as far as the question of GPL violation is concerned. "If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program." Personally, I think this is the FSF trying to interpret the situation according to how they want things to be, rather than how the law makes it. I think that the fact that a program loads a library into the same address space does not automatically mean that it's bound by the library's license, just like a program that uses a service over a network socket does not automatically mean that it's not bound by it's interface. It all depends on circumstances. Allow me to demonstrate by an extreme, hypothetical, question. Suppose Wine was distributed under the GPL (rather than LGPL). Is it ok to run MS Word on it? You get two distinct products. One is MS Word, produced and sold to you by Microsoft. The second is Wine, produced according to specs (the Win32 API), with no specific Word related work in it. When you combine them on your computer, one loads the other into the same address space, and uses it's functions. Is this a GPL violation? Of course not. It cannot be. Word was not even designed to work with Wine. The only place where these two program come together is on your computer, which as stated above, is not governed by the GPL. Even if I ship them on the same CD (if I manage to get a license from Microsoft, somehow), this is mere aggregation. Their coming together does not create derived work status, and thus does not violate the GPL. Why is that? Because both sides implement an established interface. In effect, Word is derived from the Win32 interface, as is Wine. As an interface is non-copyrightable, this means that both programs are free to choose a license without the possibility of conflict. This claim has a very important factor in it. It assumes that the Win32 interface is properly documented (it isn't), that Word uses just the documented parts (it doesn't), and that Wine does not have to deduce parts of the Win32 interface by running Word and finding out what it does (which Wine had to). For that reason, Wine is LGPL rather than GPL. Rsyncrypto is derived from the documented interface that OpenSSL has. It is not distributed with OpenSSL as a part of it. It therefore does not need to have a license that is compatible with OpenSSL's. I don't want this to sound as if I'm disagreeing with your statement in the COPYING file. I'm just reflecting on what's in the GPL FAQ but that isn't set in stone either - it states clearly that this area is unresolved. "What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. " What I'm saying in the COPYING file is that I think the FAQ gives guidelines that are optimistic as far as what the FSF would like reality to be. In that, they are misleading. I particularly didn't like the point where they forbid you to create non-GPL programs that link to GPL libraries, but say that it's ok to link GPL binaries to non-GPL (and, in fact, GPL incompatible) libraries. It's either up to the binary or it isn't. If I'm not allowed to do the former, I cannot do the later either. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
splitting a package's source
Hi all, I am both the maintainer and upstream for a package called "rsyncrypto". It's an encryption program for files with a twist (rsync friendly). Putting on my upstream hat, I am trying to make sure the package keeps on consistently conforming to previous versions. To that end I have created a regression testing infrastructure. It's a bunch of files pre-encrypted and with their keys. It also has a script that checks that the current version can still decrypt the original files in the regression test suite. Here's the problem, though. These tests are binary files, that make CVS sluggish and unresponsive. I simply cannot keep them on the same CVS tree as the sources for rsyncrypto. As such, I want to split the regression tests to a separate source file. Removing my upstream hat, and putting on my maintainer hat, I would still like that building rsyncrypto will be able to "make test" and run the regression test suite on the files. In effect, I need rsyncrypto to be built from two source files. My question is, "is this possible"? One way I thought of doing it is to create a Debian package called "rsyncrypto-regtest", and have rsyncrypto build-depend on it. That is probably the best way to solve my specific problem, and will be what I'll do, but I'm wondering whether there isn't another way of doing it. Is it possible to have two source files build the same package? Thanks, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: splitting a package's source
Nigel Jones wrote: If there are other custom build tools, you may just want to consider a rsyncrypto-dev package, otherwise you might just want to settle with rsyncrypto-test (people may not understand what regtest is a reference to, I actually thought for a moment it expanded to "registration test". Ok. As for Build-Depend, I doubt that, why not make -test a completely seperate package, That's what I was talking about. have a rsyncryptotest binary to run the test commands, and have that Depend on "rsyncrypto", that means you are giving X user the option to run the test suite, by doing this, it means that users who don't care (many sadly don't) aren't forced to test something they don't want to. I was aiming for something else, really. I was aiming for having a "make test" as part of the make process. This way, if rsyncrypto suddenly failed to work on PPC platform, I would get notified without having to hope that the porting group would get around to it. The thing is that I'm trying to put that into the standard rsyncrypto build system. I was thinking of having rsyncrypto-test recommend rsyncrypto. This will also be useful for users who build their own versions of rsyncrypto (i.e. - without a deb). So I would have: rsyncrypto suggests rsyncrypto-test, as well as build-depends on it. rsyncrypto-test which recommends rsyncrypto. The build process for rsyncrypto-test would only package files, not actually compile anything. The build process for rsyncrypto would run make-test after make, so that if something went wrong I (debian maintainer) will know about it, even if it's not for my platform. It also means that users can easily verify any prebuilt binaries quickly and easily. They can do that with this scheme. I guess the main question is "should debian/rules run make test, if upstream provided one"? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
