Re: RFS: daloradius (updated package)
Hello, On Sun, 30 Dec 2007, liran tal wrote: Hey Richard, By the way you have sent HTML mail to the list which you should avoid. but it does bother me on some level that someone whose suppose to be a Mentor has taken such a lot of effort to discourage me from building a package (whatever it may be) and to explicitly ban it from Debian. Different mentors work differently... I did not see Neil mention banning your package from Debian. What he said was: 1. *He* would not sponsor your package. 2. In *his* opinion your statements indicate that your package may never be suitable for Debian. Other mentors *may* have a different opinion but it would be up to you to show that you have at least answered Neil's criticisms to the satisfaction of a new possible sponsor/mentor. All the best with your package, Kapil. (Who does know anything about PHP) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: daloradius (updated package)
On Thu, 2007-12-27 at 11:51 +0100, liran tal wrote: It's just a bunch of .php and other related web application scripts which should simply be copied to /usr/share. If only. These files are scripts that are to be run on an unattended, internet-visible remote server that is not under your direct control and which is likely to be attacked for a variety of nefarious reasons, often by automated bots that can spend all their runtime attacking other sites with dictionary attacks, known vulnerabilities etc.. As maintainer, *you* are responsible for ensuring that your package does not lead to a security breach on those servers - including working around known vulnerabilities in other packages. PHP is well known for security vulnerabilities. There are simple fixes and there are complex problems but the maintainer needs to be familiar with all modes of attack and possible solutions, including testing the application under stress and deliberately trying to break the package. This applies to any and every other package that exist in Debian. Not true. Since when do internet-visible servers run KDE or Gnome ? Even if installed, these binaries are not run on such a server. Security involves packages that are run on remote servers, primarily. Desktop packages have less need for security - it's more about preventing data loss, not overwriting configuration files, etc.. So this is exactly what I said before - packages in Debian are dependent upon how secure they are? For packages where: 1. the language is already known to be vulnerable (PHP) and/or 2. where the package is intended to be run on remote servers, the answer is yes - packages are not uploaded to Debian if there are known security issues and maintainers are not sponsored if the sponsor is unable to get rapid, accurate and useful answers to all and any enquiries relating to security. I don't mind if other enquiries take a little time or need explanations. I do care if security enquiries are ignored or avoided, as here. What makes anyone the judge of which package is better secured than another? The maintainer, the BTS and the security team. In the case of sponsored NEW packages, this tends to be mostly down to the sponsor. So in this case, me. You might not like that but it is still true. You need to provide accurate and precise security information without delay for any sponsor to be able to work with you. Apache is a package available in Debian, do you really want me to bring up all the vulnerabilities that were discovered in it? How many have not been fixed? Are you really comparing a few hacks in PHP with the most common web server application on the internet? Comparing one developer with the cast of thousands who review the apache code? Do you *know* how arrogant that makes you sound? I think it's absurd to rule out in a snap of a finger your package is based on php, I think php is not secure so I don't want it in debian. Well, it is my judgement - as sponsor - and it is your responsibility (as maintainer) to provide all the evidence that the sponsor needs. My assessment was, and is: 1. daloradius is PHP and despite repeated requests, the maintainer has refused to provide information on how the known weaknesses in PHP have been overcome within the daloradius codebase. 2. Without security information, it is a waste of time to review PHP code as the principle reason for PHP packages causing trouble within Debian is the security of the codebase. 3. As maintainer, you have so far refused to provide any useful security information on this package and I am unable to proceed with a review. 4. Without a security review, daloradius has no place in Debian. You are not a DD. I am. I need evidence of what you have done within the code to guard against known security problems in your chosen language so that any upload I make is not immediately rejected by the ftp-master team on the basis of inadequate security precautions. Such rejections reflect badly on me, as sponsor, and I will not waste time on packages likely to be rejected. Does it make sense to you saying I don't want to include your package because it uses php and php is unsecure? because it doesn't to me. It does to me - you'll just have to deal with that. PHP *is* insecure, by default. Therefore, in order to have any chance of getting any PHP package accepted by the ftp-master team and the security team, *I* (as sponsor) must ensure that the package details exactly what steps have been taken to handle the known security problems inherent in the chosen language. Without that information, it doesn't make any difference what I do or say - the package will likely be rejected from Debian by the ftp-master on the advice of
Re: RFS: daloradius (updated package)
Hey Richard, After my last email to Neil and the mailing list I have found the following link: http://webapps-common.alioth.debian.org/draft/html/index.html Which is actually the whole essence of this conversation, it would have been suffice to simply let me know about this webapps documentation which I would have gone through and create the package accordingly (or at least attempt to) but for some reason which I really, honestly, don't understand Neil hasn't done that. I don't know why not, I do not judge people, but it does bother me on some level that someone whose suppose to be a Mentor has taken such a lot of effort to discourage me from building a package (whatever it may be) and to explicitly ban it from Debian. As you have mentioned Richard, I have no expectations from anyone to build the package for me but I do expect to find people here with a little bit more knowledge than I have on Debian and someone replying read the webapps documentation on http://...; would have been more than enough instead of starting a debate about the security issues of PHP. I don't know Neil, he's probably a good guy but you really can't argue with a persons' feelings, and I feel that the direction which Neil has taken this conversation has gone way out of proportion. In the meanwhile have a Merry Christmas and a happy New Year. Regards, Liran. On Dec 27, 2007 3:49 PM, [EMAIL PROTECTED] wrote: Quoting liran tal [EMAIL PROTECTED]: Hey Neil, On Dec 26, 2007 5:55 PM, Neil Williams [EMAIL PROTECTED] wrote: i.e. the problem lies within the package itself because it is an intrinsically difficult package to build properly and you would be best advised finding something else when you are only just starting out as maintainer. PHP is a nightmare for security problems and packaging problems. What I say to you is what I would say to anyone reading the NM guide for the first time - *don't start with PHP*! (Don't start with a compiled library either, they are complex in entirely different ways.) The NM guide does mention that libraries are not a wise choice for your first package but as it happened, I didn't get the chance of my own advice because when I started NM, I was already upstream for a library in Debian that needed an update. ;-) So learn from my mistakes and don't do things the hard way. Uhm, it seems to me that the daloradius package is actually as easy as it can be. It's just a bunch of .php and other related web application scripts which should simply be copied to /usr/share. There's no compilation, no updating of libraries and nothing that would seem to be complicated... Maybe I'm missing something but as I see it, the package should simply unpack the web application files into a directory and that's it. Well you obviously could not see the problems other people already pointed out. Maybe it is time for you to question what seems correct to you. Please correct me if I'm wrong. Some people will decline this burden even if you say Please. ..snip... I can't leave it alone Neil, it's my baby :-) Then the burden rests with you. It makes no sense to expect others to serve up the answers on a golden platter. You better be willing to dig into the documentation. A RTFM response will suffice and it is up to you to find where the documentation describes it. Richard
Re: RFS: daloradius (updated package)
Hey Neil, On Dec 26, 2007 5:55 PM, Neil Williams [EMAIL PROTECTED] wrote: i.e. the problem lies within the package itself because it is an intrinsically difficult package to build properly and you would be best advised finding something else when you are only just starting out as maintainer. PHP is a nightmare for security problems and packaging problems. What I say to you is what I would say to anyone reading the NM guide for the first time - *don't start with PHP*! (Don't start with a compiled library either, they are complex in entirely different ways.) The NM guide does mention that libraries are not a wise choice for your first package but as it happened, I didn't get the chance of my own advice because when I started NM, I was already upstream for a library in Debian that needed an update. ;-) So learn from my mistakes and don't do things the hard way. Uhm, it seems to me that the daloradius package is actually as easy as it can be. It's just a bunch of .php and other related web application scripts which should simply be copied to /usr/share. There's no compilation, no updating of libraries and nothing that would seem to be complicated... Maybe I'm missing something but as I see it, the package should simply unpack the web application files into a directory and that's it. Please correct me if I'm wrong. Maybe it was my mistake to submit the new package (0.9.5) and also go all over again about creating a package while I already started working on it in previous versions (0.9.3 and 0.9.4) - so for that I am sorry, it seemed to have fired up an un-called for argument about the package building. I'd take that as a hint that you ought to consider learning how things work using a different package as your starting point. I'm not going to advise you on daloradius for a couple of reasons: 1. I don't generally sponsor PHP anyway (I will but only if the maintainer convinces me that s/he has a firm grasp of the issues involved, which you have not done.) Again, I'm either missing something or there's a misunderstanding of what daloradius is. What kind of php security issues are there? 2. I don't think daloradius is the right package for you to maintain right now and therefore cannot be the right package for me to sponsor. Come back to it once you have learnt a lot more about Debian by packaging at least one different package that is not written in PHP. As far as PHP does, convenience (of programming) is very definitely the enemy of security. (Yes, I do write PHP, I do know at least some of the problems inherent in that language. No, I would not dare inflict my PHP on Debian as a package, I stick to the few web servers to which I have root access so that I can step in and rescue it when things go wrong.) So the reason to reject a project is because of it's programming nature that may be very much exploit-able and unsafe? Leave daloradius behind - forget it completely. Move on to a different, preferably compiled, package and restart with the NM guide. Don't even revisit daloradius packaging until you have had at least one non-PHP package successfully sponsored and bug free in Debian testing. I can't leave it alone Neil, it's my baby :-) Regards, Liran.
Re: RFS: daloradius (updated package)
On Thu, 27 Dec 2007 09:10:14 +0100 liran tal [EMAIL PROTECTED] wrote: i.e. the problem lies within the package itself because it is an intrinsically difficult package to build properly and you would be best advised finding something else when you are only just starting out as maintainer. PHP is a nightmare for security problems and packaging problems. What I say to you is what I would say to anyone reading the NM guide for the first time - *don't start with PHP*! (Don't start with a compiled library either, they are complex in entirely different ways.) The NM guide does mention that libraries are not a wise choice for your first package but as it happened, I didn't get the chance of my own advice because when I started NM, I was already upstream for a library in Debian that needed an update. ;-) So learn from my mistakes and don't do things the hard way. Uhm, it seems to me that the daloradius package is actually as easy as it can be. No, it is not and the fact that you have missed this fact is evidence enough that you are the wrong person to package daloradius (or any PHP code). It's just a bunch of .php and other related web application scripts which should simply be copied to /usr/share. If only. These files are scripts that are to be run on an unattended, internet-visible remote server that is not under your direct control and which is likely to be attacked for a variety of nefarious reasons, often by automated bots that can spend all their runtime attacking other sites with dictionary attacks, known vulnerabilities etc.. As maintainer, *you* are responsible for ensuring that your package does not lead to a security breach on those servers - including working around known vulnerabilities in other packages. PHP is well known for security vulnerabilities. There are simple fixes and there are complex problems but the maintainer needs to be familiar with all modes of attack and possible solutions, including testing the application under stress and deliberately trying to break the package. There's no compilation, no updating of libraries and nothing that would seem to be complicated... If you think *that* is complicated, you are in for a shock trying to make a secure PHP package. Maybe I'm missing something but as I see it, the package should simply unpack the web application files into a directory and that's it. Please correct me if I'm wrong. Absolutely wrong, I'm afraid. Secure PHP is very difficult to achieve and maintain. The code has to be written well, designed for security from the start and maintained rigorously. The simplicity of PHP itself only leads to more problems because many people use PHP as their first foray into programming. As I've said before, I write PHP. I have a few bits of PHP that could have been packages and a few that I use that I could package on behalf of the upstream, *but*, the code concerned was not written with security in mind from the very start and it is almost impossible now to make it secure without rewriting every single script from scratch. I'd take that as a hint that you ought to consider learning how things work using a different package as your starting point. I'm not going to advise you on daloradius for a couple of reasons: 1. I don't generally sponsor PHP anyway (I will but only if the maintainer convinces me that s/he has a firm grasp of the issues involved, which you have not done.) Again, I'm either missing something or there's a misunderstanding of what daloradius is. What kind of php security issues are there? The fact that you can even ask that question shows that PHP is the wrong language for you. Do you know how to check PHP for $_GET and $_POST vulnerabilities? Cross scripting attacks? Malicious URL and form entry processes? Corruptions and error states that would lead to security vulnerabilities? Honestly, with this admission, I could only recommend that daloradius is *NEVER* packaged for Debian as it would be fundamentally insecure, by design. You would have to show me clear and verbose evidence of a wholescale rewrite of daloradius from the ground up with clear documentation of how the new code is designed for security and evidence that none of the old code has migrated into the new package without security review. 2. I don't think daloradius is the right package for you to maintain right now and therefore cannot be the right package for me to sponsor. Come back to it once you have learnt a lot more about Debian by packaging at least one different package that is not written in PHP. As far as PHP does, convenience (of programming) is very definitely the enemy of security. (Yes, I do write PHP, I do know at least some of the problems inherent in that language. No, I would not dare inflict my PHP on Debian as a package, I stick to the few web servers to which I have root access so that I can step in and rescue it when things go wrong.) So the reason to
Re: RFS: daloradius (updated package)
Hey Neil, On Dec 27, 2007 11:01 AM, Neil Williams [EMAIL PROTECTED] wrote: On Thu, 27 Dec 2007 09:10:14 +0100 liran tal [EMAIL PROTECTED] wrote: Uhm, it seems to me that the daloradius package is actually as easy as it can be. No, it is not and the fact that you have missed this fact is evidence enough that you are the wrong person to package daloradius (or any PHP code). Well wrong is a harsh word. It's all a matter of knowledge and experience. It's just a bunch of .php and other related web application scripts which should simply be copied to /usr/share. If only. These files are scripts that are to be run on an unattended, internet-visible remote server that is not under your direct control and which is likely to be attacked for a variety of nefarious reasons, often by automated bots that can spend all their runtime attacking other sites with dictionary attacks, known vulnerabilities etc.. As maintainer, *you* are responsible for ensuring that your package does not lead to a security breach on those servers - including working around known vulnerabilities in other packages. PHP is well known for security vulnerabilities. There are simple fixes and there are complex problems but the maintainer needs to be familiar with all modes of attack and possible solutions, including testing the application under stress and deliberately trying to break the package. This applies to any and every other package that exist in Debian. Maybe I'm missing something but as I see it, the package should simply unpack the web application files into a directory and that's it. Please correct me if I'm wrong. Absolutely wrong, I'm afraid. Secure PHP is very difficult to achieve and maintain. The code has to be written well, designed for security from the start and maintained rigorously. The simplicity of PHP itself only leads to more problems because many people use PHP as their first foray into programming. As I've said before, I write PHP. I have a few bits of PHP that could have been packages and a few that I use that I could package on behalf of the upstream, *but*, the code concerned was not written with security in mind from the very start and it is almost impossible now to make it secure without rewriting every single script from scratch. So this is exactly what I said before - packages in Debian are dependent upon how secure they are? What makes anyone the judge of which package is better secured than another? Apache is a package available in Debian, do you really want me to bring up all the vulnerabilities that were discovered in it? I think it's absurd to rule out in a snap of a finger your package is based on php, I think php is not secure so I don't want it in debian. Does it make sense to you saying I don't want to include your package because it uses php and php is unsecure? because it doesn't to me. Maybe because: 1. there are other php packages in debian, are they all 100% secure? and even if I would go over their code and find it to be secure, you said for yourself that php is insecure in it's nature. 2. daloradius specifically is to be deployed in the backend servers, i.e, to be managed by the noc crew mostly so it isn't just out there in the Internet 3. do you know of a web application which says I'm 100% secure, I don't need any silly firewalls and underlying security around me? because I don't. usually when these web applications are installed administrators implement various ways to protect them - ssl, htaccess, firewalling, vpn access and I can go on and on. I'd take that as a hint that you ought to consider learning how things work using a different package as your starting point. I'm not going to advise you on daloradius for a couple of reasons: 1. I don't generally sponsor PHP anyway (I will but only if the maintainer convinces me that s/he has a firm grasp of the issues involved, which you have not done.) Again, I'm either missing something or there's a misunderstanding of what daloradius is. What kind of php security issues are there? The fact that you can even ask that question shows that PHP is the wrong language for you. Do you know how to check PHP for $_GET and $_POST vulnerabilities? Cross scripting attacks? Malicious URL and form entry processes? Corruptions and error states that would lead to security vulnerabilities? Again and again you are assuming, do you always judge people? You might be up for a surprise. I'm wondering if you put on the stand every other guy with an RFS inquiry. Honestly, with this admission, I could only recommend that daloradius is *NEVER* packaged for Debian as it would be fundamentally insecure, by design. You would have to show me clear and verbose evidence of a wholescale rewrite of daloradius from the ground up with clear documentation of how the new code is designed for security and evidence that none of the old code has migrated into the new
Re: RFS: daloradius (updated package)
Hey Chris, On Dec 25, 2007 10:08 PM, Chris Lamb [EMAIL PROTECTED] wrote: liran tal wrote: I am looking for a sponsor for the new version 0.9.5-2 of my package daloradius. This is (at least) the second time you have posted this package to the list and not corrected serious problems. As Romain Beauxis previously pointed out, this is rather annoying. I'm still spotting a number of problems I sent to you in September. I have replied to the last emails of the previous post although my replies, asking for a hand were ignored but let's move on, I wish not to dwell in the past. Please, Liran, you must either attempt to fix some of these problems (we will gladly help) or you should reply to this message justifying them. I am doing everything in my power to get this package built right. There is an enormous amount of pages about building debian packages and none of them is consistent about how to build such package. Unfortunately the New Maintainer's Guide is hardly friendly, but I am putting more effort into it again so let's try to make something out of it. As it stands, the package does not just exhibit poor style; it simply does not install any Daloradius files, and you cannot expect it to be sponsored as-is. * Wrong 'Architecture:' in debian/control If I look at http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-control The example on line 9 shows exactly that: 9 Architecture: any From looking at other packages on packages.debian.net I changed this to 'all'. * Incorrect spacing and indentation of description in debian/control * Incorrect punctuation/layout in debian/control Description I'm not sure what you mean but I have attempted to fix the description You could be more clear on what is a correct spacing/indentation and punctuation/layout? * Missing Homepage: line in debian/control I've removed the Homepage from the description and added it as a line of it's own sorrounded by as seen elsewhere. Here is an evidence of the overwhelming confusion which so many resources on the net are causing: We recommend that you add the URL for the package's home page to the package description in debian/control. This information should be added at the end of description, using the following format: . Homepage: http://some-project.some-place.org/ Link: http://debid.vlsm.org/share/Debian-Doc/manuals/developers-reference/ch-best-pkging-practices.en.html * Missing ITP number from debian/changelog Do you mean stating in the changelog that it closes some bug or rfs? Where is the ITP number coming from? * Old debhelper debian/compat compatibility number What should it be set to? * Setting 'apache' and 'php' as Depends: is probably not what you want How about that: (?) Depends: apache2, libapache2-mod-php5, php5-cli, php5-common, php-db, php-pear * Freeradius should probably not be a 'Suggests': Why not? it integrates well with FreeRADIUS. Maybe FreeRADIUS and php5-mysql should go into Recommends? * Why does it create a database called 'radius'? Why can't this be the same name of your package? Why do you have to create it at all? 1. The FreeRADIUS package provides a .sql schema which by default uses the name 'radius' for the database, as well as this is the default in all of their configuration and is extremely common across all deployments of FreeRADIUS. 2. Why to create another database? this will only cause confusion among daloRADIUS users AND it's not possible anyway because daloRADIUS relies on tables from FreeRADIUS's radius database. 3. If the 'radius' database isn't created yet then I prompt the user to create it and populate it with tables for FreeRADIUS and daloRADIUS. I note again, daloRADIUS *makes use* and is *dependent* of tables that are used BOTH in daloRADIUS and FreeRADIUS. * Lots of pointless and incorrect stuff in debian/rules. For example, CFLAGS, dh_strip, etc. True. I've no idea how to approach this file as I have nothing to compile, but rather take a bunch of files and directories (the web app) and put them in the correct place (/usr/share I assume) * Documentation in /usr/share/daloradius (eg. FAQS, etc.) How should that be populated? Should I create under the debian/ dir another /usr/share/daloradius subdir and put everything there? In addition: * The package simply does not work - no files are installed. % dpkg -c daloradius_0.9.5-2_amd64.deb drwxr-xr-x root/root 0 2007-12-25 20:55 ./ drwxr-xr-x root/root 0 2007-12-25 20:55 ./usr/ drwxr-xr-x root/root 0 2007-12-25 20:55 ./usr/share/ drwxr-xr-x root/root 0 2007-12-25 20:55 ./usr/share/doc/ drwxr-xr-x root/root 0 2007-12-25 20:55 ./usr/share/doc/daloradius/ -rw-r--r-- root/root 177 2007-12-25 20:42 ./usr/share/doc/daloradius/changelog.Debian.gz -rw-r--r-- root/root 507 2007-12-25 20:42
Re: RFS: daloradius (updated package)
On Wed, 2007-12-26 at 10:11 +0100, liran tal wrote: I am doing everything in my power to get this package built right. There is an enormous amount of pages about building debian packages and none of them is consistent about how to build such package. Unfortunately the New Maintainer's Guide is hardly friendly, The NM Guide has to start somewhere and it starts with a compiled package (Architecture: any) because that is probably the most common starter package. Just an idea. Forget daloradious for now. Find a small compiled (non-native) package that you already use. Get the Debian source using 'apt-get source' and rebuild it without changes. Copy the .orig.tar.gz to a new directory and unpack it. Now debianise that source following the guide and build a test package. Compare the *contents* of your package against the real debian package using debdiff. Compare the *.diff.gz* (the differences from upstream from the debian/ directory) using interdiff -z. It doesn't matter if the files in debian/ are different, concentrate on getting the same results as the existing package. I'm not going to spell it out for you, you should be able to find those tools, install the package(s) that provides them and read the manpages to learn how to use them. Packaging for Debian is all about using existing examples and guides on your own initiative. * Wrong 'Architecture:' in debian/control If I look at http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-control The example on line 9 shows exactly that: Because the example is a compiled package, yours is not. The guide cannot take you through *your* package - it has to assume that you know enough about your own package to discriminate between the example and your own package. I'm not sure what you mean but I have attempted to fix the description You could be more clear on what is a correct spacing/indentation and punctuation/layout? lintian -i is fairly clear, as is simply comparing with existing packages. I've removed the Homepage from the description and added it as a line of it's own sorrounded by as seen elsewhere. That support has changed recently and the guide is yet to be updated. The current practice is to put a Homepage: field in the source section of debian/control without around the url. Things are always changing within Debian - you need to ensure you keep up to date. The various guides are not always up to the minute but you should be. * Missing ITP number from debian/changelog Do you mean stating in the changelog that it closes some bug or rfs? Where is the ITP number coming from? The NM guide does cover ITP bugs. File an ITP. An RFS is not the same as an ITP. In addition: * The package simply does not work - no files are installed. That's exactly what I stated in my last email which no one replied. You have guided me to have an .orig.tar.gz tarball which is exactly my original package and NOT to put any of these files in the package No, you were guided to not change the .orig.tar.gz but create a .diff.gz instead, consisting of the contents of the debian/ directory. It is these files that determine what ends up inside the .deb - principally debian/rules. Your package should not be native so you need a 0.1.2-1 type version string. You need to pass the upstream .tar.gz to dh-make so that a .orig.tar.gz can be made. Building the package will then create a .diff.gz consisting of the changes you made in debian/. I create because that is the upstream package and it should contain no source files. Don't change the upstream package without very good reason - whatever you download from the upstream site should be preserved as .orig.tar.gz and in most cases that is fine. Whatever upstream package, whatever it contains, you generally leave it alone. When the package is built, the changes needed to make a Debian package are what generate the .diff.gz. * Out-of-date Standards-Version in debian/control What should it be set to? You are fully capable of finding that out for yourself. You need to be able to use the resources available. If you cannot find out information like that from the web pages generated for every package in Debian, you might need to reassess whether you want to be packaging for Debian at all. * Maintainer scripts are using `read`. You should use Debconf to ask users questions like this. It has many, many benefits over `read'. I will take another look at some manual for proper Debconf usage for the maintenance scripts. Debconf isn't easy for new starters - hence it may be best to forget daloradius for some time. Start with a different package that doesn't use PHP, doesn't need debconf, doesn't have complicated maintainer script requirements and is more like a typical, upstream, compiled package that fits the NM guide more closely. Maintainer scripts themselves are not something I would recommend that you
Re: RFS: daloradius (updated package)
Hey Neil, I appreciate your feedback though for the lack of better words I can summarize your reply as being a nicer way for saying RTFM. I do not wish to dwell into accusations and blames for documentations and such, if this is what you concluded from my previous email then you have spelled my intentions wrong. Maybe it was my mistake to submit the new package (0.9.5) and also go all over again about creating a package while I already started working on it in previous versions (0.9.3 and 0.9.4) - so for that I am sorry, it seemed to have fired up an un-called for argument about the package building. I suggest then that maybe we should continue where we left off with the previous package versions the last time... (before my post about 0.9.5) I have made the directories of my package building available in the following address: http://daloradius.sourceforge.net/debian/ And as it will turn out they are not structured the same way so how about we start by first saying which one of them is the proper way (or at least is close to) to get the package built? Sincerely, Liran. On Dec 26, 2007 12:42 PM, Neil Williams [EMAIL PROTECTED] wrote: On Wed, 2007-12-26 at 10:11 +0100, liran tal wrote: I am doing everything in my power to get this package built right. There is an enormous amount of pages about building debian packages and none of them is consistent about how to build such package. Unfortunately the New Maintainer's Guide is hardly friendly, The NM Guide has to start somewhere and it starts with a compiled package (Architecture: any) because that is probably the most common starter package. Just an idea. Forget daloradious for now. Find a small compiled (non-native) package that you already use. Get the Debian source using 'apt-get source' and rebuild it without changes. Copy the .orig.tar.gz to a new directory and unpack it. Now debianise that source following the guide and build a test package. Compare the *contents* of your package against the real debian package using debdiff. Compare the *.diff.gz* (the differences from upstream from the debian/ directory) using interdiff -z. It doesn't matter if the files in debian/ are different, concentrate on getting the same results as the existing package. I'm not going to spell it out for you, you should be able to find those tools, install the package(s) that provides them and read the manpages to learn how to use them. Packaging for Debian is all about using existing examples and guides on your own initiative. * Wrong 'Architecture:' in debian/control If I look at http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-control The example on line 9 shows exactly that: Because the example is a compiled package, yours is not. The guide cannot take you through *your* package - it has to assume that you know enough about your own package to discriminate between the example and your own package. I'm not sure what you mean but I have attempted to fix the description You could be more clear on what is a correct spacing/indentation and punctuation/layout? lintian -i is fairly clear, as is simply comparing with existing packages. I've removed the Homepage from the description and added it as a line of it's own sorrounded by as seen elsewhere. That support has changed recently and the guide is yet to be updated. The current practice is to put a Homepage: field in the source section of debian/control without around the url. Things are always changing within Debian - you need to ensure you keep up to date. The various guides are not always up to the minute but you should be. * Missing ITP number from debian/changelog Do you mean stating in the changelog that it closes some bug or rfs? Where is the ITP number coming from? The NM guide does cover ITP bugs. File an ITP. An RFS is not the same as an ITP. In addition: * The package simply does not work - no files are installed. That's exactly what I stated in my last email which no one replied. You have guided me to have an .orig.tar.gz tarball which is exactly my original package and NOT to put any of these files in the package No, you were guided to not change the .orig.tar.gz but create a .diff.gz instead, consisting of the contents of the debian/ directory. It is these files that determine what ends up inside the .deb - principally debian/rules. Your package should not be native so you need a 0.1.2-1 type version string. You need to pass the upstream .tar.gz to dh-make so that a .orig.tar.gz can be made. Building the package will then create a .diff.gz consisting of the changes you made in debian/. I create because that is the upstream package and it should contain no source files. Don't change the upstream package without very good reason - whatever you download from the upstream site should be preserved as .orig.tar.gz and in most cases that is fine.
Re: RFS: daloradius (updated package)
On Wed, 2007-12-26 at 17:47 +0200, liran tal wrote: I appreciate your feedback though for the lack of better words I can summarize your reply as being a nicer way for saying RTFM. No, more a case of if you are unsure how the guidelines apply to this package, reconsider whether you are the best person to package it at this stage and find something which will enable you to learn how things work for simpler packages. i.e. the problem lies within the package itself because it is an intrinsically difficult package to build properly and you would be best advised finding something else when you are only just starting out as maintainer. PHP is a nightmare for security problems and packaging problems. What I say to you is what I would say to anyone reading the NM guide for the first time - *don't start with PHP*! (Don't start with a compiled library either, they are complex in entirely different ways.) The NM guide does mention that libraries are not a wise choice for your first package but as it happened, I didn't get the chance of my own advice because when I started NM, I was already upstream for a library in Debian that needed an update. ;-) So learn from my mistakes and don't do things the hard way. I do not wish to dwell into accusations and blames for documentations and such, if this is what you concluded from my previous email then you have spelled my intentions wrong. I did not conclude that. Maybe it was my mistake to submit the new package (0.9.5) and also go all over again about creating a package while I already started working on it in previous versions (0.9.3 and 0.9.4) - so for that I am sorry, it seemed to have fired up an un-called for argument about the package building. I'd take that as a hint that you ought to consider learning how things work using a different package as your starting point. I'm not going to advise you on daloradius for a couple of reasons: 1. I don't generally sponsor PHP anyway (I will but only if the maintainer convinces me that s/he has a firm grasp of the issues involved, which you have not done.) 2. I don't think daloradius is the right package for you to maintain right now and therefore cannot be the right package for me to sponsor. Come back to it once you have learnt a lot more about Debian by packaging at least one different package that is not written in PHP. As far as PHP does, convenience (of programming) is very definitely the enemy of security. (Yes, I do write PHP, I do know at least some of the problems inherent in that language. No, I would not dare inflict my PHP on Debian as a package, I stick to the few web servers to which I have root access so that I can step in and rescue it when things go wrong.) Leave daloradius behind - forget it completely. Move on to a different, preferably compiled, package and restart with the NM guide. Don't even revisit daloradius packaging until you have had at least one non-PHP package successfully sponsored and bug free in Debian testing. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
RFS: daloradius (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.9.5-2 of my package daloradius. It builds these binary packages: daloradius - An advanced RADIUS web management The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/daloradius - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/daloradius/daloradius_0.9.5-2.dsc I would be glad if someone uploaded this package for me. Kind regards Liran Tal
