Re: Screwed up svn-inject?
On Thu, Apr 10, 2008 at 07:38:03AM -0400, Matt Arnold wrote: I recently set up a private Subversion repository for my non collab-maint packages. [1] It has helped me work efficiently (as opposed to taking two months to do anything :)). One problem however all svn-buildpackage runs produce debian native packages. I was wondering if anybody knew of a way to fix this? If this is documented somewhere i apologize. Hi, do you have the orig.tar.gz in you tarballs directory? It doesn't seem so... Maybe the tarballs were automatically saved at ../tarballs? Then you could create a symlink from tarballs to ../tarballs. I did that at my checkout. :) Cheers, Hauke signature.asc Description: Digital signature
Re: Screwed up svn-inject?
Hi! Am 10.4.2008 schrieb Matt Arnold [EMAIL PROTECTED]: I recently set up a private Subversion repository for my non collab-maint packages. [1] It has helped me work efficiently (as opposed to taking two months to do anything :)). One problem however all svn-buildpackage runs produce debian native packages. I was wondering if anybody knew of a way to fix this? If this is documented somewhere i apologize. [1] http://thegnuguru.org/wsvn/listing.php?repname=pkg-mattpath=%2Frev=0sc=0 Hmmm... looks like you didn't used the -o parameter for svn-inject; so not only your changes, but the entire tarball got added to the repository. I guess that's the cause of the native package, since that leads to the absence of an orig.tar.gz. I guess you might be able to solve the issue by delete everything but your debian/ directory and copying the orig.tar.gz to the tarballs directory. But I'm not really sure. Yours sincerely, Alexander Yours sincerely, Alexander
Regarding package installation
While running commands(red coloured font) to install a source package i am having problems (bolded text) debianabc:/home/fast# cd debian debianabc:/home/fast/debian# apt-get source bnfc Reading package lists... Done Building dependency tree... Done *E: You must put some 'source' URIs in your sources.list *debianabc:/home/fast/debian# apt-get build-dep bnfc Reading package lists... Done Building dependency tree... Done *E: You must put some 'source' URIs in your sources.list *debianabc:/home/fast/debian# cd bnfc2.2 bash: cd: bnfc2.2: No such file or directory debianabc:/home/fast/debian# cd bnfc-2.2 debianabc:/home/fast/debian/bnfc-2.2# debuild -uc -us *bash: debuild: command not found *debianabc:/home/fast/debian/bnfc-2.2# -- Regards, Zainab Rehman
Re: Regarding package installation
Le 11 avr. 08 à 15:29, Zainab Rehman a écrit : While running commands(red coloured font) to install a source package i am having problems (bolded text) Please don't send HTML or otherwise formatted e-mail to this list, it just doesnt help (I see no bolded text, instead everything looks tiny). debianabc:/home/fast# cd debian debianabc:/home/fast/debian# apt-get source bnfc Reading package lists... Done Building dependency tree... Done E: You must put some 'source' URIs in your sources.list Well, then add som 'source' URIs in your sources.list! That means you need a line starting with deb-src in /etc/apt/sources.list. Usually, you can just copy all your deb lines, replacing the initial deb by deb-src. debianabc:/home/fast/debian# apt-get build-dep bnfc Reading package lists... Done Building dependency tree... Done E: You must put some 'source' URIs in your sources.list debianabc:/home/fast/debian# cd bnfc2.2 bash: cd: bnfc2.2: No such file or directory debianabc:/home/fast/debian# cd bnfc-2.2 debianabc:/home/fast/debian/bnfc-2.2# debuild -uc -us bash: debuild: command not found debianabc:/home/fast/debian/bnfc-2.2# install devscripts. Regards, Thibaut.
Re: Regarding package installation
On Fri, Apr 11, 2008 at 10:29 AM, Zainab Rehman [EMAIL PROTECTED] wrote: While running commands(red coloured font) to install a source package i am having problems (bolded text) debianabc:/home/fast# cd debian debianabc:/home/fast/debian# apt-get source bnfc Reading package lists... Done Building dependency tree... Done E: You must put some 'source' URIs in your sources.list debianabc:/home/fast/debian# apt-get build-dep bnfc Reading package lists... Done Building dependency tree... Done E: You must put some 'source' URIs in your sources.list debianabc:/home/fast/debian# cd bnfc2.2 bash: cd: bnfc2.2: No such file or directory debianabc:/home/fast/debian# cd bnfc-2.2 debianabc:/home/fast/debian/bnfc-2.2# debuild -uc -us bash: debuild: command not found debianabc:/home/fast/debian/bnfc-2.2# The messages are pretty explanatory. (You even marked the ones that need some atention.) Add deb-src lines to the /etc/apt/sources.list file pointing to the source repositories. You also need the package with debuild. (I don't remember if there is a package only for 'debuild' or if it is part of another, so you'll have to search.) BTW, unless you are packaging bnfc (which does not seem to be the case), this is not the best mailing list for the question. Try debian-user. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Default admin password for a webapp
On Thu, Apr 10, 2008 at 08:58:51AM +1000, Ben Finney wrote: Xavier Luthi [EMAIL PROTECTED] writes: The webapp won't allow any authentication becasue the password is not set. How to ask for a password? Some way that the administrator can do so separately from installing the package. Ideally, the installation would use the same API to set the administrative password if available during the install. With a warning message on the administrative page of the webapp saying something like: 'Please run (as root) dpkg-reconfigure pixeplpost to set the password of the administrative user.' (priority is always 'low' for dpkg-reconfigure). That would do the job at hand, but is unfortunately Debian-specific. Better would be to work with the upstream to address this at the source, such that the solution becomes part of the upstream distribution. That's up to you to determine whether you have the resources to do so. The installation procedure from the upstream source ask for the administrative password the very first time anyone access the application (this the classical way for a webapp). The assumption is the installation time is the same as the configuration time, thus reducing to a minimum the time when the application is left open. In the case of the webapp packaged for Debian, the installation time is not always the same as the configuration time, so it is not an option to use the upstream method to set the password: this would be a big security hole. That's why the Debian package of a webapp often needs to diverge from the upstream source in the way the application is configured. Cheers, Xavier signature.asc Description: Digital signature
RFS: nautilus-share (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.7.2-1 of my package nautilus-share. It builds these binary packages: nautilus-share - Nautilus extension to share folder using Samba The package appears to be lintian clean. The upload would fix these bugs: 475230 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/n/nautilus-share - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/n/nautilus-share/nautilus-share_0.7.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- Thierry Randrianiriana -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libvrb (updated package)
Sorry for my really long silence. I see this version is still not in Debian. Should I upload? Székelyi Szabolcs wrote: Dear mentors, I am looking for a sponsor for the new version 0.5.1-5 of my package libvrb. Amaya sponsored the initial upload, I would prefer her for the update, too. It builds these binary packages: libvrb0- Virtual Ring Buffer library libvrb0-dev - Virtual Ring Buffer library - development files vbuf - Virtual Ring Buffer library - shell interface The package appears to be lintian clean. The upload would fix these bugs: 437455 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libvrb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libvrb/libvrb_0.5.1-5.dsc I would be glad if someone uploaded this package for me. Kind regards Székelyi Szabolcs -- ·''`. Fuck your fascist beauty standards : :' : `. `' `-Proudly running (unstable) Debian GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Easiest way to Debianise a package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cheers, Since I have last bothered debian-devel-games, I have studied how to create packages. I was asking how to properly create executable packages separate from packages containing data files. This was for an MMORPG open source client replacement called YATC. I have produced something working somewhere in February; resulting Debian-producing files can be found int: * http://opentibia.svn.sf.net/svnroot/opentibia/yatc/trunk/debian/ * http://opentibia.svn.sf.net/svnroot/opentibia/yatc/trunk/debian-data/ This works and seems to produce somewhat valid packages -- it's installable, it works, and while I didn't check in detail with lintian and linda, it looks to me like it might pass for valid Debian packages. But the solution itself does not make me happy. I'm looking for a smarter way to produce Debian packages for future games, out of SVN'ed, autotools-using projects. I'm looking for information for cases where I am the upstream. That means I could use tips with proper use of autotools to make generating DEBs easier; I'm still generally struggling with autotools. My question is generic and not related to YATC. (For example, YATC's sources can't include data files since data files from original client are, well, not licensed for such distribution.) So, I have an autotools project. Punching in make dist produces project-0.1.tar.gz. make distcheck also produces a valid executable provided that all libraries are installed. Data files are not (currently) mentioned anywhere in the autotools data files such as Makefile.am, configure.ac, etc. Questions: 1. What are your recommendations with regards to what to use to perform initial debianisation of the project? Meaning - what should I use? Just debhelper? CDBS? 2. Should data files be produced by same debianisation directory (by which I mean folder containing files copyright, rules, etc)? 3. Should source file generated by autotools contain the data files? Will that make debianisation any easier? 4. In case my questions are wrong: What would be your steps for producing packages project and project-data, considering what I mentioned above and directory structure below? What would be your desires for upstream -- what should upstream do to make your life easier? What would you do after fetching SVN (not tar.gz) that contains data as below, and whose make dist would generate .tar.gz containing just sources? I would be most grateful if someone would bother and make one little Debinoob a little more one three three seven. P.S. I'm also not sure if my signing process is valid, so if someone could check if it signs the text correctly compared to the key published on URL below, I'd be grateful. (I'm trying to use FireGPG, Iceweasel extension to add few buttons to Gmail) http://ivucica.googlepages.com/ Example directory structure: aclocal.m4 AUTHORS autogen.sh autom4te.cache BUGS ChangeLog config.status configure.ac COPYING depcomp doc/ file.txt graphics/ metal1.png metal2.png INSTALL install-sh Makefile.am Makefile.in missing models/ human.obj ship1.obj ship2.obj music/ song1.ogg song2.ogg NEWS README sectors/ sector1.xml sector2.xml ships/ ship1.xml ship2.xml sounds/ src/ Makefile.am.template Makefile.in main.cpp ship.h ship.cpp space.h space.cpp Note: src/Makefile.am.template is generated using autogen.sh to produce src/Makefile.am... don't ask. - -- Ivan Vučica - -- Croatia -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFH/4rcsunNof3e6g8RAp8OAJoCPjvV7X48SaXJEEN/r1vf3jYr/wCfWGYH B/pd9VGS4wTUbwTk2v0zSM4= =rysn -END PGP SIGNATURE-
Re: RFS: jin
On Wed, Apr 9, 2008 at 6:03 AM, Bernhard R. Link [EMAIL PROTECTED] wrote: resources/lnfs and resources/libs contains jar files with classes but nothing seems to contain their sources. After looking at the licensing issues a little deeper, and consulting upstream, it seems there are two binary-only jars that are non-free and are required to compensate for lag. Removing them would significantly degrade the user experience and it seems there's no possibility for them to be opened up. So, I have no alternative but to give up this package since I have no plans of maintaining non-free software. There was also the case of parts of the distribution being none-DFSG compliant, which needed to be looked at, but mostly superseded by the previous constraint. I still think Jin is a great piece of software, and upstream has been very courteous in responding to my requests. If anyone is willing to take it up, please let me know off the list, so I can send you what I've done so far. Thanks for your input. I'll definitely do a better job with licensing aspects next time. -- Anuradha Weeraman http://www.linux.lk/~anu/ http://anuradha.wordpress.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
* Ivan Vucica [EMAIL PROTECTED] [080411 18:18]: I'm looking for a smarter way to produce Debian packages for future games, out of SVN'ed, autotools-using projects. I'm looking for information for cases where I am the upstream. That means I could use tips with proper use of autotools to make generating DEBs easier; I'm still generally struggling with autotools. [...] So, I have an autotools project. Punching in make dist produces project-0.1.tar.gz. make distcheck also produces a valid executable provided that all libraries are installed. Data files are not (currently) mentioned anywhere in the autotools data files such as Makefile.am, configure.ac, etc. Questions: 1. What are your recommendations with regards to what to use to perform initial debianisation of the project? Meaning - what should I use? Just debhelper? CDBS? That depends whom you ask. Both has advantages and disadvantages. The biggest distadvantage of CDBS is that you have to know everything very good to be sure it does the right thing and still works tomorrow and not only by pure chance now. 2. Should data files be produced by same debianisation directory (by which I mean folder containing files copyright, rules, etc)? I don't understand the question. 3. Should source file generated by autotools contain the data files? Will that make debianisation any easier? That depends. Usually just having one .orig.tar.gz containing everything makes it easier for users compiling on their own (they just have to download a single file), for you if you want to put them into the same source package (which has the advantage of easier keeping them in sync in the archive, though the downsize that you only can upload new versions of program and data at the same time to Debian[1]). 4. In case my questions are wrong: What would be your steps for producing packages project and project-data, considering what I mentioned above and directory structure below? What would be your desires for upstream -- what should upstream do to make your life easier? In case everything is in the same source package (which I'd suggest), separating things at build time (and even only build the needed parts) is easier when arch-dependent and arch-independent parts are in separate directories and have their own Makefile's (in auto* by having their own Makefile.am doing the preparation and installing as opposed to having the top-level Makefile doing that) and no functionality in the top level dir (i.e. mostly only clean and things recursing into SUBDIRS there). What would you do after fetching SVN (not tar.gz) that contains data as below, and whose make dist would generate .tar.gz containing just sources? I guess I'd be confused but remember some games separate stuff and start reading the README. Note: src/Makefile.am.template is generated using autogen.sh to produce src/Makefile.am... don't ask. must. resist. the. urge Hochachtungsvoll, Bernhard R. Link [1] Though realistically, only both change at the same time usually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
On Fri, Apr 11, 2008 at 06:00:41PM +0200, Ivan Vucica wrote: I'm looking for a smarter way to produce Debian packages for future games, out of SVN'ed, autotools-using projects. You should check out the cdbs package which has an autotools helper. As an example, take a look at the rules for my couchdb package: https://svn.berlios.de/wsvn/erlang-pkg/couchdb/trunk/debian/rules?sc=1 At the top I include: include /usr/share/cdbs/1/rules/buildcore.mk include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk This is enough to build a basic autotools package for you automatically. HTH, -- Noah Slater - Debian GNU/Linux http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
Hello, I'm not a DD, but here are the first impressions I got from a quick review: - There are lots of unnecessary files (all the .ex stuff, empty ones, and otherwise unnecessary files). Also, yatc/trunk/debian/dirs lists some directories which probably don't need to be created explictly. - It's recommended to have a debian/watch file or a get-orig-source in debian/rules to download the upstream tarball. - Both packages have Priority: extra in debian/control. You probably want optional there; see /usr/share/doc/debian-policy/policy.html/ch-archive.html#s-priorities for an explanation about all possible values. - I haven't really checked, but on a first glance it seems like yatc misses some build dependencies. Have you tried if it builds correctly in a chroot (like for example with pbuilder)? - Why is the binary package tibia-data set as architecture dependent (Architecture: any means that it should be compiled for all available architectures; you probably want all there, which means that it is architecture independent and the .deb only needs to be build on one architecture). - Please don't say which packages it requires in yatc's description. - The descriptions could take some spell checking (an MMORPG - a MMORPG; 2d - 2D), and I think that they are too short. - You can remove lines 3-7 from debian/rules, the commented examples stuff in build-stamp and the comments from binary-arch. - tibia-data could suggest or recommend yatc. - The current standards version is 3.7.3, not 3.7.2. - This is only a personal preference, but if a package is licensed under GPL version 2 or later I prefer to refer to /usr/share/common-licenses/GPL instead of /usr/share/common-licenses/GPL-2 (was GPL links to the latest one, which is that one which the FSF recommends). But anyway, good work. I know that packaging can be quite difficult at start :). Regards, -- Siegfried-Angel Gevatter Pujals (RainCT) Ubuntu Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: yabasic ITA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all I am looking for a sponsor for the new version 2.763-5 of my package yabasic -- Yet Another BASIC interpreter. This upload patches an annoying bug upstream and closes my ITA (At last putting a dent in my stack of wnpp bugs :)) The package appears to be lintian clean and builds fine against unstable. The upload would fix these bugs: 465659 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/y/yabasic - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/y/yabasic/yabasic_2.763-5.dsc I would be glad if someone uploaded this package for me. Regards Matt Arnold (cybermatt/asciitxt) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH/7OKfGeS0kace80RAuJkAJ9WI22smNE+y9CIl/zzektYx8E+gQCghn9v Tm8BCRLRSYj5i0YdSs2398Y= =7STF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
I'm not a DD, but I have a bit of advice: it seems that new users commonly will leave a file like debian/dirs in place because dh_make put it there. If you don't know what these files do, you can find out from the man pages for various debhelper commands. You can easily guess what manual page covers what you're looking for, i.e. *install are related to dh_install, *dirs are related to dh_installdirs, *cron are related to dh_installcron. To make multiple binary packages, I usually use .install files to handle which files go to each package. There's a relevant paragraph about this at [1], but it's pretty short. Also note that dh_install has --list-missing and --fail-missing options that might help you catch files that you forgot to install (though I haven't tried them yet, so I could be wrong). [1] http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-multiple-binary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libvrb (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Amaya, Amaya wrote: Sorry for my really long silence. I see this version is still not in Debian. Should I upload? Yes, please. Thanks! - -- cc Székelyi Szabolcs wrote: Dear mentors, I am looking for a sponsor for the new version 0.5.1-5 of my package libvrb. Amaya sponsored the initial upload, I would prefer her for the update, too. It builds these binary packages: libvrb0- Virtual Ring Buffer library libvrb0-dev - Virtual Ring Buffer library - development files vbuf - Virtual Ring Buffer library - shell interface The package appears to be lintian clean. The upload would fix these bugs: 437455 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libvrb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libvrb/libvrb_0.5.1-5.dsc I would be glad if someone uploaded this package for me. Kind regards Székelyi Szabolcs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH/87yGJRwVVqzMkMRAtlVAJ9Gx2yL6PuMqNL5lBX1IZbU2+7aDgCfYUrU q6w3Wc6mawb/LSKLAET2l5Y= =jK5Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Modifications to included PHP libs
Neil, thanks for your comprehensive mail. To be honest you didn't bolster me up with your mail. The package I was talking about already has a version in debian and I'm thinking about adopting it because it was removed from testing. One of the reasons was included code that would be duplicated in debian. So I already had in mind much of what you wrote and I really feel like you're right at all. I guess I need to reconsider my intention... Hauke signature.asc Description: Digital signature
Re: Modifications to included PHP libs
On Sat, 12 Apr 2008, Jan Hauke Rahm wrote: I guess I need to reconsider my intention... There are a lot of packages that could use assistance, so please keep looking. Don Armstrong -- Nothing is as inevitable as a mistake whose time has come. -- Tussman's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Modifications to included libs
On Sat, Apr 12, 2008 at 12:20 AM, Jan Hauke Rahm [EMAIL PROTECTED] wrote: I'm working on a package that includes some php libs (e.g. pear packages). Some of those are already packaged for debian so it'd be better at all if I'd set a dependency on it and don't ship the code again, right? It is better that absolutely none of the embedded php libs are included/used/shipped in the .deb. If they are not packaged separately, the security team will not be happy at all. First of all my question is how to do that. Can I just create a symlink to the other package or must I modify the upstream source to look at the right place (without using links)? I'd suggest reading the draft debian webapps policy and asking about this on the debian webapps list. I imagine your app has a config.php in which you can set the default php include path. And the next question is: what can I do if upstream uses a modified version of that lib? Is there a proper way to ship just the modifications and for the rest use the files of the lib package? There is no proper way to ship embedded forks. Instead the fork should be merged upstream or dropped. Fix your app upstream so that it does not need the modifications, or get the php lib upstream to include the modifications and get that into Debian. The most acceptable hacky way to do it would be to create a libfoo-modified-php package that build-depends on the original version (libfoo-php), copy and apply a patch at build time, then ship the patched version in the libfoo-modified-php binary package. Then your webapp can depend on libfoo-modified-php. If there is *any* code duplicated in the source/binary package from other software, the security team must be notified of the situation so they can fix security issues properly. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Default admin password for a webapp
Please follow URL:http://www.debian.org/MailingLists/#codeofconduct; specifically, please don't send individual copies of messages you also send to the mailing list, since I haven't asked for them. Xavier Luthi [EMAIL PROTECTED] writes: On Thu, Apr 10, 2008 at 08:58:51AM +1000, Ben Finney wrote: Xavier Luthi [EMAIL PROTECTED] writes: The webapp won't allow any authentication becasue the password is not set. How to ask for a password? Some way that the administrator can do so separately from installing the package. Ideally, the installation would use the same API to set the administrative password if available during the install. The installation procedure from the upstream source ask for the administrative password the very first time anyone access the application (this the classical way for a webapp). It may be the classical way, but nevertheless it's making an unwarranted assumption. The assumption is the installation time is the same as the configuration time, thus reducing to a minimum the time when the application is left open. The installation of a network-accessible application (or even one that *could* be made network-accessible) should never have the application left open for any period of time. In the absence of proper administrative credentials, the application should refuse all access until such credentials are set. In the case of the webapp packaged for Debian, the installation time is not always the same as the configuration time, so it is not an option to use the upstream method to set the password: this would be a big security hole. That's why the Debian package of a webapp often needs to diverge from the upstream source in the way the application is configured. Such divergence is to be avoided where possible. I suggest, if you're willing, you (as the Debian packager for this package) could work with the upstream developers to close this security hole consistently in the upstream *and* Debian packages. -- \ ...one of the main causes of the fall of the Roman Empire was | `\that, lacking zero, they had no way to indicate successful | _o__) termination of their C programs. -- Robert Firth | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Default admin password for a webapp
Ben Finney [EMAIL PROTECTED] writes: Xavier Luthi [EMAIL PROTECTED] writes: In the case of the webapp packaged for Debian, the installation time is not always the same as the configuration time, so it is not an option to use the upstream method to set the password: this would be a big security hole. That's why the Debian package of a webapp often needs to diverge from the upstream source in the way the application is configured. Such divergence is to be avoided where possible. [...] This (and the rest of the paragraph) is phrased poorly, with a corollary left unimplied. Better is: Such divergence, though sometimes necessary, should be resolved as soon as possible by working with the upstream developers to merge Debian's improvements into a future upstream release. -- \“Simplicity is prerequisite for reliability.” —Edsger W. | `\ Dijkstra | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
