Re: Mentors upload authentication
This one time, at band camp, Michael Gilbert said: > On Thu, Feb 16, 2012 at 1:17 AM, Stephen Gran wrote: > > This one time, at band camp, Michael Gilbert said: > >> Based on discussion about making mentors official, one of the key > >> requirements is contributor DMUP agreement and upload authentication. > > > > I think that there are two main problems with this idea: > > > > First, alioth, while having an infrastructure for ssh keys, doesn't know > > anything about gpg keyrings and signed packages and so on, so all of > > that work still has to be done (and this is the hard bit - distributing > > ssh public keys is easy). > > In terms of gpg public keys, the user could simply upload theirs to a > public_html alioth location, which would allow the mentors scraping > algorithms to pick that up. That process itself would be rather > simple, and could be documented in a set of wiki instructions. Why > are you thinking that's going to be hard? Most people go to a lot more trouble to make sure gpg signatures are valid and trustworthy than just downloading them from a random home directory on a machine where accounts are created on demand. I'm not sure what level of identification you're looking for here, but that seems so trivial to subvert it makes me think you'd be better off without it. I'm assuming that the backstory here is that ftpmaster want signed and identifiable uploads. I think this idea fails that test, myself. > > Second, I think requiring all contributors on alioth to sign the DMUP is > > a very bad idea. > > Alioth is Debian machine, and its listed on > http://db.debian.org/machines.cgi, which is linked from the DMUP > (http://www.debian.org/devel/dmup). I don't really understand why > alioth is so special that it deserves a free pass from the DMUP. It's > a rather non-demanding agreement anyway. > > Just to be a bit more clear, of course DDs and DMs who've already > agreed to the DMUP shouldn't have to do it again. Just to be clear, alioth is not a regular debian.org machine. It isn't admined by the same team, accounts are not handled in the same way, and privileged groups on Debian machines have no special privilege on alioth machines. Yes, the 2 machines that make up the alioth service are in the normal debian ldap, as are several other non-DSA admin'ed machines (exodar, strauss, sumotsu, etc). You don't need to sign the DMUP to use those machines either, as far as I'm aware. Their presence in LDAP is an implementation detail of the system that exports accounts to the machines. > > We host some external project like SANE that have no > > reason to want to sign agreements about their usage of machines they'll > > never log in to. > > I don't think it would be that arduous for external contributors to > sign the DMUP as it's a rather non-demanding and sane document anyway. I do believe it will be arduous to go find all the people who currently use alioth who are not DDs and ask them to sign something in order to retain their access to a service they use. > > Even if we did think it was a good idea, account > > creation is entirely automatic and on demand - we have no way of > > ensuring people have read and agreed to something beyond adding a click > > through web page at creation time or something (ick!). > > You could change your process to do something like launchpad with > their code of conduct (i.e. contributors can/should gpg sign and > upload it). That is optional on launchpad, but I think it should be > required for the DMUP. To recap, I still don't think alioth is a good fit for this. I think you're trying to shoehorn something that works with launchpad onto an entirely different system, and it doesn't fit very well for a variety of reasons. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Mentors upload authentication
This one time, at band camp, Michael Gilbert said: > Based on discussion about making mentors official, one of the key > requirements is contributor DMUP agreement and upload authentication. > > One thought I had recently was to move the file hosting functionality > over to alioth, which already has the necessary authentication > infrastructure. The process from a contributors perspective then > would be something like: I think that there are two main problems with this idea: First, alioth, while having an infrastructure for ssh keys, doesn't know anything about gpg keyrings and signed packages and so on, so all of that work still has to be done (and this is the hard bit - distributing ssh public keys is easy). Second, I think requiring all contributors on alioth to sign the DMUP is a very bad idea. We host some external project like SANE that have no reason to want to sign agreements about their usage of machines they'll never log in to. Even if we did think it was a good idea, account creation is entirely automatic and on demand - we have no way of ensuring people have read and agreed to something beyond adding a click through web page at creation time or something (ick!). So, I think this doesn't sound like a good fit to me, sorry. Cheers, -- - | ,''`. Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: fig2sxd
This one time, at band camp, Alexander Bürger said: > Hei, > > > > You might want to investigate the 'pbuilder' package for maintaining a > > > chroot specifically to build your packages inside. > > > > You should also test your packages in unstable too. > > So how would I do that efficiently? It is highly unlikely that I buy a > second computer, or that I replace ubuntu on the existing one... Most people who want to run stable on their machines use an unstable chroot for development work. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: literally '?' in debconf template
This one time, at band camp, George Danchev said:
> On Sunday 28 September 2008 22:08:28 markus schnalke wrote:
> > Hello mentors,
>
> Hi,
>
> > lintian reports this warning:
> > using-question-in-extended-description-in-templates
> > (see [1])
> >
> > But there is no question where lintian sees one. Instead it's a
> > literally question mark. The text is:
> > "You can use wildcard expressions like '*' or '?'."
> >
> > How can I solve the situation?
> > Is there a way to escape the questions mark?
> > Do I have to override the warning?
>
> Well, lintian did his job right to warn you about a possible problem, but it
> can't sense the context (at least as of yet;-), thus you can safely override
> his decision.
Or you could file a wishlist bug with a patch something like:
--- a/checks/debconf
+++ b/checks/debconf
@@ -312,7 +312,7 @@ foreach my $template (@templates) {
tag "malformed-question-in-templates", $template->{template};
}
}
- if (defined ($extended) && $extended =~ /\?/) {
+ if (defined ($extended) && $extended =~ /\?(\s+|$)/) {
tag "using-question-in-extended-description-in-templates",
$template->{template};
}
if ($type eq 'note') {
To help eliminate false positives in tests.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: RFS: dish
This one time, at band camp, Vincent Bernat said: > OoO En ce début de soirée du lundi 02 juin 2008, vers 21:37, Dimitar > Ivanov <[EMAIL PROTECTED]> disait: > > > Finally, I did some minor changes in the main program and the > > Makefile. Hence a new upstream release emerged and has been uploded: > > > - dget http://mentors.debian.net/debian/pool/main/d/dish/dish_1.16.2-1.dsc > > Uploaded. For a future release, you should add a lintian override for > this lintian warning: > W: dish: spelling-error-in-description mysql MySQL Or, instead of hiding the warning, just fix the spelling? If it's a bug in lintian, report that instead. Overrides shouldn't be used lightly and encouraging one for a capitalization issue seems like poor judgement, IMHO. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Copyright question
This one time, at band camp, Cyril Brulebois said: > On 06/02/2008, Jean Parpaillon wrote: > > 3. All advertising materials mentioning features or use of this > > software must display the following acknowledgement: > > This product includes software developed at the University of > > Tennessee, Knoxville, Innovative Computing Laboratories. > > > > 4. The name of the University, the name of the Laboratory, or the > > names of its contributors may not be used to endorse or promote > > products derived from this software without specific written > > permission. > > > > > The advertising requirement (3.) is a problem, though. No. -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: service helper package
This one time, at band camp, C.J. Adams-Collier said: > On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote: > > > > Why not use echo and cat? Calling echo this way the shell can't use the > > builtin echo command and must spawn a new process. > > Is there a test to determine whether there is a builtin for a given > command? If so, we could test for that and use it if it exists. > Otherwise, use the fully qualified version It's recommended not to use full paths in general. Sometimes it becomes necessary to move binaries from one path to another, and hard coding full paths breaks that. Resetting PATH is more useful than hard coding full paths to binaries if you're worried about security. > > You know what you are doing here? PATH is necessary for the daemon to > > find subcommands. > > Yep. I don't want to execute any but the fully qualified commands. > It's a security thing. No, it's really not. Resetting PATH to some small subset is useful, but breaking your child processes' ability to run call popen isn't all that great. -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: interpretted scripts (Re: service helper package)
This one time, at band camp, Justin Pryzby said: > On Mon, Nov 26, 2007 at 02:13:42PM +0000, Stephen Gran wrote: > > This one time, at band camp, Jörg Sommer said: > > > > > > Init scripts should not use Bash, they should be Posix Shell scripts! > > > > Not strictly true. A script written for use with #!/bin/sh should use > > the POSIX superset allowed by policy. A script aimed at bsah should > By "superset" of posix I guess you mean posix + echo -n. IIRC policy also allows [ "$this" -a "$that" ] and [ "$this" -o "$that" ] although I might be confused in thinking those aren't POSIX. > > just declare it's interpreter as #!/bin/bash. Generally, you don't need > > to do that, but you are allowed to. > Do you mean because bash is the default sh? No, I mean that bash specific features are not generally necessary in writing something as simple as an init script. -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: service helper package
This one time, at band camp, Jörg Sommer said:
>
> Init scripts should not use Bash, they should be Posix Shell scripts!
Not strictly true. A script written for use with #!/bin/sh should use
the POSIX superset allowed by policy. A script aimed at bsah should
just declare it's interpreter as #!/bin/bash. Generally, you don't need
to do that, but you are allowed to.
> > # Check whether we were configured to not start the services.
> > check_for_no_start() {
> > if [ "$SERVICE_DISABLED" = "yes" ]; then
>
> This is such a broken behavior. Initscripts are enabled and disabled in
> the configuration of the init system.
That's not quite true - many packages in debian use an enable/disable
variable in an /etc/default/package file.
--
---------
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: [RFS] libnss-pgsql
This one time, at band camp, Michelle Konzack said: > Hello Mentors, > > I have after correting the package version 1.4.0 uploded to > and looking for a sponser Have you managed to find anyone familiar with nss and threaded programming to assist you in maintaining this fairly fundamental piece of software? Last we spoke about this, you said you were unfamiliar with both of those aspects of programming, which makes me feel as though you may want to recruit a comaintainer before maintaining this in Debian. Take care, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#419570: Bug#393832: Bug#419570: webcalendar: Package dependencies must allow php5 instead of php4
This one time, at band camp, Rafael Laboissiere said: > * Stephen Gran <[EMAIL PROTECTED]> [2007-04-18 11:14]: > > > This one time, at band camp, Rafael Laboissiere said: > > > Is this feature under development? It would be great to be able to > > > specify > > > dependencies like the following (note the parentheses): > > > > I know people have talked about the problem with an eye towards patching > > it in. I have not heard that anyone has actually produced any code. > > Do you remember where this discussion took place? At a BBQ, is my memory. As I say, I'm fairly sure it never went anywhere. -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#393832: Bug#419570: webcalendar: Package dependencies must allow php5 instead of php4
This one time, at band camp, Rafael Laboissiere said: > Is this feature under development? It would be great to be able to specify > dependencies like the following (note the parentheses): I know people have talked about the problem with an eye towards patching it in. I have not heard that anyone has actually produced any code. Sorry to get your hopes up :) -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#419570: webcalendar: Package dependencies must allow php5 instead of php4
This one time, at band camp, James Westby said: > On (17/04/07 02:27), Rafael Laboissiere wrote: > > I see a problem with the above dependencies. Imagine the following > > combination of packages in a given system: > > > > apache2 installed > > apache, apache-ssl, and apache-perl NOT installed > > libapache2-mod-php4 installed > > libapache2-mod-php5 NOT installed > > php4-mysql, php4-pgsql, and php5-pgsql NOT installed > > php5-mysql installed > > > > The above satisfy the dependencies as you wrote them. The question is: > > would php5-mysql work well with libapache2-mod-php4? The answer is of course not. Fortunately, dependencies prevent this pathological case from happening. > That's not your job, the php maintainers have to ensure their packages > work, you just have to make sure enough php/mysql/apache stuff is > installed to work. Well, that's glossing it over a bit - the problem of ORed dependencies is not trivial to deal with, and there is no support in apt for it. Theoretically, these sorts of dependencies could be written with brackets or something to make a complete set soultion possible, but it's not there just yet. -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: preinst: ( "configure" && [ -n "$2" ] ) or ( "configure" && [ -z "$2" ] ) ?
This one time, at band camp, [EMAIL PROTECTED] said: > Regarding the following part of a preinst maintainer script: > > > 1)case "$1" in > 2)configure) > 3)if [ -n "$2" ]; then > 4)mkdir -p dir/subDir > 5)# First time install. Can we autodetect the old settings? > 6)test for the old settings > > > Am I right that the comment partially means the programmer assures us that > at > this point it is a first time install? > At the 3rd line there is a test for [ -n "$2" ]. By looking at section 6.5 > of policy > I would say that for being assured this is a first time install the correct > test > should have been [ -z "$2" ]. Am I right? You are correct. However the "test for old settings" shortly after that makes no sense given that this is uspposed to be a new install. I am hazarding a guess that the comment and/or the code is wring somewhere. Good luck, -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: tstat
This one time, at band camp, Charles Plessy said: > Le Mon, Aug 21, 2006 at 11:20:35AM +0200, Adam Borowski a écrit : > > On Sun, Aug 20, 2006 at 08:21:47AM -0700, tony mancill wrote: > > > 3. All advertising materials mentioning features or use of this software > > > must display the following acknowledgement: > > >This product includes software developed by Endace Technology Ltd., > > >Hamilton, New Zealand, and its contributors. > > > 4. Neither the name of Endace Technology nor the names of its > > > contributors > > > may be used to endorse or promote products derived from this software > > > without specific prior written permission. > > > > This is exactly the wording of the 4-clause BSD license, with just the name > > of UC Berkeley replaced with Endace. It's thus DFSG-free, even though it's > > strongly discouraged. > > Dear Adam, > > Last week-end I was told by a DD that the 4-clause BSD licence was > non-free... Do you have any link in the archives which proves the > contrary? This is very interesting for me as I am interested in bringing > to Debian an unofficial package whose software is under this licence... Have a look at the DFSG. It explicitly uses the BSD license as an example of a free license. At the time that statement was written, there was no 3 clause BSD - that is a later amendment. Anyone trying to tell you the 4 clause BSD license in non-free is wrong. There are problems with it, and it can't be combined with GPL'ed code, and that might be what your informant was thinking of. But it is certainly free by Debian standards. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build depends....?
This one time, at band camp, Mihai Felseghi said: > Masami Ichikawa wrote: > > on 06/24/06 01:48, Mihai Felseghi wrote: > >>> Hello dear mentors , please tell me if there is a method of finding > >>> the build depends for a piece of software > > > > [EMAIL PROTECTED]:~]% objdump -p /usr/bin/fluxbox | grep NEEDED > > Thank you for the advice I will try this method. While that's a good start, it's a conflation of Depends and build-Depends. objdump is giving you runtime dependencies on shared libraries, which are usually related to but not the same as the build time dependencies. There is a script in one of the new maintainer documents that uses strace to look for open() calls in ./configure to help you figure out build-dependencies. Another method is to look at all the #include'd headers your package needs, and figure out where they come from. Finally, use something like pbuilder to test your builds when you think you're close - it will fail if you're missing something. Also read the build logs from the pbuilder session very carefully to see if it just disabled an optional feature rather than failed because you missed something. Take care, -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: libnet-dbus-perl -- Perl extension for the DBus message system
This one time, at band camp, [EMAIL PROTECTED] said: > On Sat, Jun 10, 2006 at 12:50:49PM +0100, Stephen Gran wrote: > > Can you tell me where it was downloaded from? I prefer to test against > > the upstream tarball. I am somewhat interested in this, a I would like > > to be able to script some dbus queries for desktop use, and this seems > > like a reaasonable way. > > http://search.cpan.org/~danberr/Net-DBus-0.33.2/ OK, so a few comments about the package: You have dh-make-perl cruft in debian/rules, copyright and control - please fix those up. This is mostly harmless boilerplate and extra comments that aren't needed, but I like to see all the files have what you need and no more. debian/copyright has no actual license declarartion. It is unredistributable like this. There is a lintian warning and an error. Both are easily fixable - please let me know if you don't understand the problems. Take care, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: libnet-dbus-perl -- Perl extension for the DBus message system
Can you tell me where it was downloaded from? I prefer to test against the upstream tarball. I am somewhat interested in this, a I would like to be able to script some dbus queries for desktop use, and this seems like a reaasonable way. Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Question about linux-wlan-ng-firmware in main
This one time, at band camp, Frank Küster said: > Stephen Gran <[EMAIL PROTECTED]> wrote: > > Can't you just ship those ten lines in contrib, and the rest in main? > > This may be archive bloat, but surely it's arch:all, so that minimizes > > the bloat at least. I am not over fond of the freer-than-free holy > > wars, but it does seem like this script is exactly the sort of thing > > that contrib was designed for. > > This explicitly does *not* mention "Suggests". Who said anything about Suggests? I am not talking about inter-package dependencies. I am only talking about the script that downloads some non-free firmware. The rest of the package is of course fine for main, as far as I can tell from the conversation so far. > I rather think it's a technical question: Can a source package in main > produce one binary package that is installed in contrib, or is the > separation done only on the level of source packages? I don't know the answer to that myself, although I can't see why not, legally or ideologically, since contrib is defined as free in and of itself, but with missing and/or non-free dependencies. It shouldn't be impossible to have a source in main/binary in contrib arrangement, although maybe it is due to limitations of the archive software. Not that I'm set on forcing this (as yet nonexistant) _binary_ package into contrib. It's just that all the other download packages are moving there, and I thought it should be with it's friends. -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Question about linux-wlan-ng-firmware in main
This one time, at band camp, Raphael Hertzog said: > Contrib is effectively meant for wrapper on non-free stuff. But contrib is > really needed when the wrapper stuff is the *main purpose* of the package. > > In the case concerning us, we have 10 lines of DFSG-free code that can be > used to download non-free firmwares within a bigger DFSG-free package. > > For me it's no worse than putting the 10 lines of code in README.Debian, > it serves really the same purpose. > > So my vote is "keep that little wrapper in the main package, it doesn't > hurt". > > In fact, I go even further: I wish that the package use a low-priority > debconf question (defaulting to "do not download") to let the user execute > the wrapper at installation time. Of course, the question should warn the > user that he's about to download non-free stuff. Can't you just ship those ten lines in contrib, and the rest in main? This may be archive bloat, but surely it's arch:all, so that minimizes the bloat at least. I am not over fond of the freer-than-free holy wars, but it does seem like this script is exactly the sort of thing that contrib was designed for. -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: E: aircrack-ng: FSSTND-dir-in-usr usr/man/
This one time, at band camp, Le_Vert said: > > > When I installed the manpage in usual directory (/usr/share/man/man1) I > got : > E: aircrack-ng: FSSTND-dir-in-usr usr/man/ This looks more like you're installing something to /usr/man/man1, instead of /usr/_share_/man/man1. Are you sure it's not installing in /usr/man/man1, and symlinking from /usr/share or something? > So I read the FHS and I understood (maybe I'm wrong) that the manpages > should be moved in /usr/share/man/en/man1. So I did... And now I get > lintian's warinings : Those subdirectories are for translated manpages. If the original is in English, it should just go in the regular /usr/share/man/man1. Take care, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS qvamps (ITP #361134)
This one time, at band camp, Claudio Moratti said: > On Friday 07 April 2006 14:49, Stephen Gran wrote: > [cut] > > No problem, we all make mistakes. Now, the buildingof the package is > > ready, but the depends really aren't. I cannot, for instance, run the > > program in a clean chroot - I get perl errors and it refuses to start. > > Can you please investigate? Clearly the Depends are missing some > > modules. > the module was > libqt-perl :( > > now fixed :) Yup, that fixed it. Uploaded now. Thanks, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS qvamps (ITP #361134)
This one time, at band camp, Claudio Moratti said: > On Friday 07 April 2006 11:35, Stephen Gran wrote: > > > > Please test that it builds in a clean chroot - you are now missing a > > build dependency, and it fails to build from source without it. > sorry for this stupid mistake :( > It's the second time that i forget 'dpatch' as dependencies -_- > Now it works (I checked it with pbuilder)! No problem, we all make mistakes. Now, the buildingof the package is ready, but the depends really aren't. I cannot, for instance, run the program in a clean chroot - I get perl errors and it refuses to start. Can you please investigate? Clearly the Depends are missing some modules. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS qvamps (ITP #361134)
This one time, at band camp, Claudio Moratti said: > On Friday 07 April 2006 00:32, Stephen Gran wrote: > > This one time, at band camp, Claudio Moratti said: > > > Hi, > > > I'm looking for a sponsor for qvamps package! > > > > I would prefer to see > > these compile time warnings go away, however: > > I fixed every warning, with the exception of: > > ifo_read.i:463: Warning(321): exists conflicts with a built-in > > name in perl > > I have created a 'dpatch patch' with these corrections! Please test that it builds in a clean chroot - you are now missing a build dependency, and it fails to build from source without it. Otherwise, looks good, though. Thanks, -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS qvamps (ITP #361134)
This one time, at band camp, Claudio Moratti said: > Hi, > I'm looking for a sponsor for qvamps package! > It is lintian errors free ;-) It is indeed. The packaging looks good overall. I would prefer to see these compile time warnings go away, however: swig -perl -Wall -nodefault libdvdread.i SWIG:1: Warning(123): dangerous, use -nodefaultctor, -nodefaultdtor instead. ifo_read.i:463: Warning(321): exists conflicts with a built-in name in perl gcc -pipe -O2 -fomit-frame-pointer -fpic -I /usr/lib/perl/5.8/CORE -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Wno-strict-aliasing -Wno-unused-function -Wno-unused-variable -c -o libdvdread_wrap.o libdvdread_wrap.c libdvdread_wrap.c: In function "DVDVolumeIdentifier": libdvdread_wrap.c:1473: warning: pointer targets in passing argument 4 of "DVDUDFVolumeInfo" differ in signedness libdvdread_wrap.c: In function "DVDVolumeSetIdentifier": libdvdread_wrap.c:1484: warning: pointer targets in passing argument 4 of "DVDUDFVolumeInfo" differ in signedness libdvdread_wrap.c: In function "DVDDiscIdentifier": libdvdread_wrap.c:1499: warning: pointer targets in return differ in signedness I'm probably being a stickler, but can you take a look at them? They don't seem particularly unfixable. Thanks, -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: vamps
This one time, at band camp, Claudio Moratti said: > I didn't use these flags, because I think that default flags set by the > upstream author are fine... > this variable is a refuse... I'll remove it in the next release ;-) OK, sounds good. Package uploaded. Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: vamps
This one time, at band camp, Claudio Moratti said:
> On Monday 13 March 2006 19:24, Stephen Gran wrote:
> > This one time, at band camp, Claudio Moratti said:
> > I see quite a few signedness issues while compiling (the packaging
> > itself looks fine, BTW - nice work!). Are you able to work on these,
> > do you need help, etc? I would prefer to fix them now, as it's mostly
> > simple stuff (it looks like, anyway), rather than wait until after upload
> > to see if it does cause problems.
> >
> I fixed these warnings with a little patch (attached)
>
> I'm uploading the fixed package to
> http://www.knio.it/debian/vamps/
Looks good. I am willing to upload at this point. I just have one more
thing I noticed, and I wanted to let you decide if you want to fix it
now before doing so.
The only issue I see now is that the CFLAGS set in debian/rules are
being ignored. You can either export them or pass them in the call to
make, like:
export CFLAGS
or
CFLAGS="${CFLAGS}" ${MAKE}
It's a fairly minor issue, but I see no point in having options set and
then ignored, as it seems like a path to confusion later. Let me know
if you want this version uploaded as is, that's fine, or tell me to wait
and upload the fixed version.
Take care,
--
-----
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: RFS: vamps
This one time, at band camp, Claudio Moratti said: > Hi! > > My sponsor is full of work, and he has not time to check and upload the new > vamps package... so I need a sponsor ;-) > > Package on the PTS: > http://packages.qa.debian.org/v/vamps.html > > The new version: > htp://www.knio.it/debian/vamps/ > > Thanks in Advice ;-) I see quite a few signedness issues while compiling (the packaging itself looks fine, BTW - nice work!). Are you able to work on these, do you need help, etc? I would prefer to fix them now, as it's mostly simple stuff (it looks like, anyway), rather than wait until after upload to see if it does cause problems. List below (built on i386): vamps.c: In function "vap_leader": vamps.c:793: warning: pointer targets in passing argument 1 of "strlen" differ in signedness vamps.c:793: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:793: warning: pointer targets in passing argument 1 of "strlen" differ in signedness vamps.c:793: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:793: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:793: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c: In function "vap_trailer": vamps.c:852: warning: pointer targets in passing argument 1 of "strlen" differ in signedness vamps.c:852: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:852: warning: pointer targets in passing argument 1 of "strlen" differ in signedness vamps.c:852: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:852: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:852: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c: In function "vap_phase1": vamps.c:990: warning: pointer targets in passing argument 1 of "strlen" differ in signedness vamps.c:990: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:990: warning: pointer targets in passing argument 1 of "strlen" differ in signedness vamps.c:990: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:990: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:990: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c: In function "vap_phase2": vamps.c:1149: warning: pointer targets in passing argument 1 of "strlen" differ in signedness vamps.c:1149: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:1149: warning: pointer targets in passing argument 1 of "strlen" differ in signedness vamps.c:1149: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:1149: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness vamps.c:1149: warning: pointer targets in passing argument 1 of "__builtin_strcmp" differ in signedness play_cell.c: In function "insert_nav_pack": play_cell.c:293: warning: pointer targets in initialization differ in signedness play_cell.c:312: warning: pointer targets in passing argument 1 of "merge_scr" differ in signedness play_cell.c:316: warning: pointer targets in assignment differ in signedness play_cell.c: In function "insert_dummy_pack": play_cell.c:420: warning: pointer targets in initialization differ in signedness play_cell.c:430: warning: pointer targets in passing argument 1 of "merge_scr" differ in signedness play_cell.c: In function "insert_private_2_pack": play_cell.c:488: warning: pointer targets in initialization differ in signedness play_cell.c:500: warning: pointer targets in passing argument 1 of "merge_scr" differ in signedness Thanks, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Removing former conffiles
This one time, at band camp, Bas Wijnen said: > Hello, > > After bug report #339387, I added a postinst file to the dummy package > gnocatan-meta-server, which does > update-rc.d gnocatan-meta-server remove &>/dev/null || true > in order to get rid of the links which were created by the previous > (non-dummy) version of the package. > > However, this didn't seem to work. Appearantly this is what happened: > - The non-dummy package created the conffile > - The package was upgraded to the dummy version, which no longer held the > conffile. However, it being a conffile, it was not removed (perhaps this is > only true if it was actually changed?) > - On purging the dummy package, the conffile is not removed because it isn't > listed as part of the package. > - update-rc.d then refuses to remove the links, because the file is still > there. > - Both the conffile and the links remain on the system. Investigate the -f option of update-rc.d. There are various tricks around for getting rid of unwanted old conf files (check that the md5sum is unchanged and rm it if so, etc), but if you can safely just remove the links and be done with it, that's probably the simplest. > The question is, how do I solve this? Should I forcefully remove the conffile > before calling update-rc.d? It feels really bad to remove files from /etc in > maintainer scripts, but perhaps it's the right thing to do... > > As an aside, I suppose that such "manual" removal would work both for file-rc > and sysv-rc, right? I have no idea how they work, sorry. -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Submission
This one time, at band camp, Larry Owens said: > How do I find where a package is installed on my hard drive by e.g. > "apt-get install libpgeasy"? For example, how do I find where a typical > package, e.g. libpgeasy, is installed? This is the sort of question apprpriate for debian-users, BTW - this list is really for mentoring of future and current developers, rather than beginning Debian administration tye questions. That being said, The actual .deb that got downloaded is at /var/cache/apt/archives/ The unpacked contents of the .deb are viewable by running dpkg -L libpgeasy There may be other files created by maintainer scripts and so forth, but that will get most of them. -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: ITP vexim
This one time, at band camp, Daniel Knabl said: > Am Fri, 27 Jan 2006 10:44:47 +0100 schrieb Marc Haber > <[EMAIL PROTECTED]>: > > > How many times have you been pointed to Debian policy? > > Do you mean "after I already read it"? Then the answer is "too many > times"... > > > And you are still asking questions that neatly show that you didn't > > read it? And that also neatly show that you have never looked at other > > packages? > > Maybe my question was confusing, that's possible. > As I understand the policy, in details the chapters 6.6, 6.6 and 6.7, > there have to be some actions performed on various targets of the files. > > The main target in postinst, when someone initially installs the > software, is "configure", and in postrm, when someone purges it, it is > "purge". For these two targets I found examples by looking at some > other packages (phpmyadmin, album, ...) that do very similar things. And > I implemented those actions to be performed also in my scripts. > > Now it seems, that I should also perform actions on some targets that > do not get used in real installation process: who should upgrade the > package, when there has never been a version of it before? > Who should downgrade the package (to a non-existent version before)? I > did some tests (installing, removing,purging ...) and there was no > unexpected behavior. Disclaimer: I have not looked at your packaging. The standard way to do this sort of thing is look through the reference for all the arguments your script can be called with, and handle them. so something like: case "$1" in configure) do_something ;; targets|you|could|be|called|with) ;; *) echo "Unknown arg $1" >&2 exit 1 ;; esac What it seems like you are missing is that Debian does not work in isolation. Other distributions like Knoppix and Ubuntu and many others reuse the work of Debian developers, and making your maintainer scripts as robust as possible will help them as well as you. At the moment, there are no Debian packaged versions of vexim, so why have an upgrade target, right? Well, presumably you will add a new version at some point, and then you'll have to handle the upgrade and downgrade targets. Knoppix may in the meantime have added a new version before you get to it, and forgot to check the maintainer scripts you wrote - bang, all the upgrades on Knoppix fail. Since it's not that hard to follow the recommendations of policy, and to future proof your work, why not just do it? I agree, Marc is being a little combative (I assume you've struck a nerve with him), but it does sound from the outside like you've still some way to go on this. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: license question
This one time, at band camp, Daniel Knabl said: > Hi, > > please have a look at the following license. In my eyes it is not a > true BSD license, but also no Artistic license. But, I may be wrong. > This would not be the first time :-/ > Would it be OK to just include this license into the debian/copyright > file? Or is it a common-license that I just don't understand? It tries to be a BSD style license, as far as I can tell, but it has a problem: >Copyright 2003 Avleen Vig and Virtual Exim Development Team. > >THIS SOFTWARE IS PROVIDED BY THE FREEBSD PROJECT ``AS IS'' AND ANY Unless Avleen Vig and the Vexim team are part of the BSD project, then this license is just silly. That will need fixing. -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: ITP vexim
This one time, at band camp, Daniel Knabl said: > Am Sun, 22 Jan 2006 14:44:59 -0500 schrieb Justin Pryzby > > How do you deal with the exim4 "conf.d" model vs the exim4.conf model? > > Please look at the previous paragraphs. ;-) Why don't you just create an entire seperate conf.d structure and tell people to use the -d switch in /etc/default/exim? I filed a bug and the exim guys graciously added it in for exactly this sort of thing. We ship an inhouse anti-spam wonder configurator gizmo that just uses another directory, and then we switch update-exim4 to use that directory instead of /etc/exim4. Works a charm. -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: directnet -- A serverless, mesh network instant messaging client
This one time, at band camp, Roger Leigh said: > Ben Hutchings <[EMAIL PROTECTED]> writes: > > > Thijs Kinkhorst wrote: > >> On Tue, January 3, 2006 09:47, Gregor Richards wrote: > >> > I updated the package to 1.0.0. The version compare algorithm doesn't > >> > like it ... it thinks that 1.0.0 is less than 1.0.0rc5 ... but that's not > >> > how release candidates work :) > >> > >> That's indeed a caveat on the Debian version compare algorithm. When > >> you're packaging a release candidate, you normally should watch out for > >> adding 'rcN' to the version to avoid being able to update it to the real > >> version later. > >> > >> What's done commonly is something like this: 0.9.9+1.0.0rc5, or for a > >> higher version: 2.4.3+2.4.4rc1. > > > > I believe this practice has been obsolete since the release of sarge. > > dpkg now considers "~" to sort before anything, even a null string, so > > you can use e.g. "1.0.0~rc5". > > The last time I checked, the archive infrastructure couldn't cope with > this, so while you could build and install, you couldn't upload > packages with a '~' in the version. > > It may be the situation has now changed; hopefully someone might be > able to clarify that. As of, er, last I heard (a month or two ago? I can't remember more precisely), you are correct. It is essentially a small patch to DAK to make this work, but it has not (or perhaps had not) yet been applied. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS vamps (ITP #320067)
This one time, at band camp, Claudio Moratti said:
> On Saturday 24 December 2005 13:33, Stephen Gran wrote:
> > debian/rules:
> > You conditionally copy in config.{sub,guess} but unconditionally rm
> > them. This is not idempotent and will lead to failures to build a
> > second time.
> uhm...
> I could remove the condition, because at first time the debian/rules remove
> the config.{sub,guess} and, after a dist-clean, copy them
> from /usr/share/misc/ dir...
>
> I don't see how it could not work or it creates problems...
I was mistaken - you build-depend on autotools-dev, so it will work
correctly in this case. But I was also just trying to nudge you towards
what I see as good practice; if something is error prone enough to
warrant a condition in one place, it is probably enough to warrant a
condition throughout. If not, no problem.
> > debian/NEWS:
> > cron (3.0pl1-74) unstable; urgency=low ...
> > ?? This looks like a cut and paste error.
> removed...
Good.
> > debian/libk9copy0.files:
> > usr/lib/libk9copy.la should go in the -dev package
> uhm...
> there is a 'little' problem:
> if I put the .la file in -dev package, k9copy does not run correctly...
Really?
[EMAIL PROTECTED]:~/k9copy-1.0.2$ head debian/libk9copy0/usr/lib/libk9copy.la
# libk9copy.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.20 Debian 1.5.20-2 (1.1220.2.287
2005/08/31 18:54:15)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.
If k9copy really needs a libtool helper file to run, something odd is
going on.
> > debian/dirs:
> > You install /usr/lib/k9copy/ in k9copy, but the libraries are installed
> > into /usr/lib/. Probably the best thing is to just drop that directory
> [cut]
> > libk9copy.install to install the files in the subdirectory.
> I removed this directory...
Good.
> > debian/menu:
> > I'm not sure what to say here. There seems to be very little coherence
> > in Debian proper about where things are dumped in the menu hierarchy,
> [cut]
> > I am not saying you have to change anything, just mentioning it.
> But You're right...
> I selected 'graphics' section because k9copy works with 'graphics things',
> but
> it is like a 'bigger tool', because it create an ISO, but it could also write
> it to a DVD...
> BTW Debian menu is a little beat
Yes, it's slowly getting better, but you are right. It was designed
before the freedesktop standards for menus, and was not really
maintained for a while. It does have the advantage of working for every
single window manager Debian ships, which is something that I don't
think any of the other systems can claim just yet, though, so it's
better than nothing. But it is still a bit of a mess. Hopefully the
discussion currently going on around it will improve things.
Take care,
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: RFS vamps (ITP #320067)
This one time, at band camp, Claudio Moratti said:
> Yes, k9copy (like the new qVamps) are frontend to vamps...
> I have had to work on k9copy package, because, from the last version, some
> things are changes (now it provides a library...)!
>
> I put k9copy package on http://www.knio.it/debian/k9copy (and after the
> holidays qvamps)...
>
> I'd like some feedback about k9copy package, because this is my first
> welldone
> (I hope) package providing a library...
Some feedback:
debian/rules:
You conditionally copy in config.{sub,guess} but unconditionally rm
them. This is not idempotent and will lead to failures to build a
second time.
debian/NEWS:
cron (3.0pl1-74) unstable; urgency=low ...
?? This looks like a cut and paste error.
debian/libk9copy0.files:
usr/lib/libk9copy.la should go in the -dev package
debian/dirs:
You install /usr/lib/k9copy/ in k9copy, but the libraries are installed
into /usr/lib/. Probably the best thing is to just drop that directory
from the dirs file. It's only a single library, so you don't really
need a subdirectory. If you really want to install into a subdirectory,
then you should use k9copy.dirs and libk9copy0.dirs and so forth so that
you don't have /usr/lib in the k9copy package, and then use
libk9copy.install to install the files in the subdirectory.
debian/menu:
I'm not sure what to say here. There seems to be very little coherence
in Debian proper about where things are dumped in the menu hierarchy,
so I am not going to say your choice is wrong - it certainly makes
a kind of sense. However, I note that at least k3b and xcdroast put
their menu entry in Apps/Tools. It seems like it would make sense to
have k9copy nearby those, although I think you could argue they are
in the wrong place. This may not be worth fixing right now, as there
is an evolving thread on another list about reforming the menu policy,
allowing for finer grained submenus to make some snse of the whole mess.
I am not saying you have to change anything, just mentioning it.
General:
Lots of compiler warnings. Not a problem in and of itself, but I always
worry about underlying coding practices when I see lots of 'comparison
between signed and unsigned' and 'takes type int but arg 4 is long int'
type warnings. For the future, you may want to do a code audit, but I
don't see it as a sticking point for now.
Hope that's helpful,
--
---------
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: RFS vamps (ITP #320067)
This one time, at band camp, Neil McGovern said: > On Fri, Dec 23, 2005 at 12:36:41AM +0100, Claudio Moratti wrote: > > Hi *! > > I'm looking for a sponsor for vamps package: > > > > Hi there, > > Thanks for packaging this, uploaded :) Hrm, beat me to it :) Thanks again, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS vamps (ITP #320067)
This one time, at band camp, Claudio Moratti said: > Hi *! > I'm looking for a sponsor for vamps package: > > -- > Package: vamps > Section: graphics > License: GPL > Description: Tool to recompress and modify the structure of a DVD > Vamps reduces the size of DVD compliant MPEG2 program streams by > selectively copying audio and subpicture tracks and by resizing > the embedded elementary video stream. > The shrink factor may be either specified for the video elementary > stream only or for the video ES only or for the full PS. > . > http://sourceforge.net/projects/vamps/ > -- > > The package (lintian errors free) is available here: > http://www.knio.it/debian/vamps/ My first impresion is that it looks quite good. On reading the play_cell manpage, I am not quite clear on what it does, but at least you have written manpages for both binaries. If no one else has stepped forward, I should be able to upload this tomorrow(ish) - tonight I just don't have time to properly QA it, but I don't see any issues on my first run through. Thanks, -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Creating a randomized cron entry
This one time, at band camp, Justin Pryzby said: > On Thu, Dec 15, 2005 at 12:55:00PM +0000, Stephen Gran wrote: > > > > Probably the most portable way to handle it is to run the job from > > cron.daily, but call a wrapper script that sleeps for a random amount of > > time less than one day before runnign the actual job. For extra > > goodness, use a lock file so that if the last random sleep was 23 hours > > and 59 minutes, and the next one is 1 minute, you don't two jobs at > > once. > But that means essentially running a daemon for the package, > completely undermining the point of cron. Except that it doesn't fork to the background, close file descriptors, or handle requests. Basically it would do sleep $RANDOM touch lock.tmp if ln lock.tmp lock 2>/dev/null; then rm -f lock.tmp run program rm -f lock else rm -f lock.tmp fi Not much a daemon, if you ask me (unless your definition of daemon is anything that uses a timer and sleep). -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Creating a randomized cron entry
This one time, at band camp, Don Armstrong said: > On Thu, 15 Dec 2005, Florian Weimer wrote: > > I'd like to create a cron entry which is run once a day, at some > > random time. This is necessary because the cron entry will result > > in a request over the network, and I want to avoid that all hosts in > > a time zone pound the server at the same time. > > Why not just something like: > > 0 0 * * * at now + $(( $RANDOM \% 1440 )) minutes [...] Because that's a bashism, and some dash user will get upset with you. Probably the most portable way to handle it is to run the job from cron.daily, but call a wrapper script that sleeps for a random amount of time less than one day before runnign the actual job. For extra goodness, use a lock file so that if the last random sleep was 23 hours and 59 minutes, and the next one is 1 minute, you don't two jobs at once. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: pbuilder and scons
This one time, at band camp, Claudio Moratti said: > Hi *! > I'm working on a package that uses scons... > > everything goes fine but I find one problem: in order to clean the sources, > debian/rules calls > /usr/bin/scons -c > but pbuilder don't try to install the Unmet build dependencies before the > "clean"... > > I read, in Debian Policy Manual, that: > "Build-Depends, Build-Conflicts > The Build-Depends and Build-Conflicts fields must be satisfied when any > of > the following targets is invoked: build, clean, binary, binary-arch, > build-arch, build-indep and binary-indep." > > Is it a bug? No, it's a misunderstanding of how pbuilder is meant to work. instead, try pbuilder build ../kleansweep_0.2.1-2.dsc If that fails (and the dsc is there and sane and so forth) then there's a bug. pdebuild is documented to call the clean target before chroot'ing, so just don't use that interface if you can't satisfy the clean target requirements. HTH, -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: "combined" prerm script problem [Bug#337223: fail2ban: leaves garbage around after purge]
This one time, at band camp, Yaroslav Halchenko said:
> Dear All,
>
> I'm maintaining fail2ban package and got a bug report about garbage left
> after purge on the package. The problem lies in prerm script which first
> tries to stop fail2ban and then if stop was successfull removes .py[co]
> files (added by dh_python) which were compiled/installed on first
> start of fail2ban:
>
> #!/bin/sh
> set -e
> # Automatically added by dh_installinit
> if [ -x "/etc/init.d/fail2ban" ]; then
> if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
> invoke-rc.d fail2ban stop || exit 0
> else
> /etc/init.d/fail2ban stop || exit 0
> fi
> fi
> # End automatically added section
> # Automatically added by dh_python
> dpkg -L fail2ban |
> awk '$0~/\.py$/ {print $0"c\n" $0"o"}' |
> xargs rm -f >&2
> # End automatically added section
>
> The simplest solution is to override error-handler for dh_installinit
> but that will impact postinst script as well and I don't want to have
> such side effect. What would be a proper solution or do I have to
> contact debhelper team (or -dev list) to resolve this case.
> I would like to avoid hacking my own prerm since it will not be a proper
> solution
If you are generating the compiled python code in postinst, then remove
the compiled code in prerm. Put the second snippet in the prerm script
before the debhelper token.
HTH,
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: FW: language.dat in allegro
This one time, at band camp, Michelle Konzack said: > Hello all, > > Miriam is packing the game Kraptor for Debian GNU/Linux and > there is a problem with the path for language.dat > > How can we solve this ? > > Please respond to the Mailinglists alleg-main, debian-mentors > and me parallel. In setup.c, you call find_allegro_resource for SETUP_LANGUAGE_FILE. SETUP_LANGUAGE_FILE is #defined as language.dat, so I am assuming this is the problematic part. Taking a quick look at how find_allegro_resource works, it appears that it will search several default paths for the file, unless the full path to the file is passed. So if you are only looking for a specific file (and not also looking for a ~/.kraptor/ file or something) you can just #define the full path, it seems. Hope that's right - I don't know allegro, and just spent about 15 minutes looking at this :) Take care, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpDyVTNAfVhH.pgp Description: PGP signature
Re: Policy about command names
This one time, at band camp, Bartosz Fenski aka fEnIo said: > On Fri, Apr 22, 2005 at 12:39:15PM -0300, Lucas Di Pentima wrote: > > Hi there, > > Hello. > > > I'm packaging ZABBIX (http://www.zabbix.com), a resource monitor & > > agent. The original programs in the upstream source tgz file are > > generated with names like this: > > > > * zabbix_agent > > * zabbix_agentd > > * zabbix_server > > > > ..etc... > > > > I've read somewhere (I think a package's changelog) that the name > > "like_this" was changed to "like-this" because of the Debian policy...so > > I've searched for this detail on the website but didn't found anything > > about that. Is it truth that programs shouldn't have the underscore on > > their names? I don't remember any command to have it anyways :-) > > ([EMAIL PROTECTED])~$ls /usr/bin/* | grep _ | wc -l > 71 > ([EMAIL PROTECTED])~$ > > That's my fresh installation (I'm during migration to new box). > Please DON'T rename binaries names. It only confuses users and often makes > examples in documentation not working. I think there's a confusion here between binary names, and binary package names. The packages should be named zabbix-agent zabbix-agentd zabbix-server But the binaries themselves should retain their original names, so as not to introduce needless incompatibility with the rest of the world. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp89guQ6aOIk.pgp Description: PGP signature
Re: common function handling in maintainer scripts
This one time, at band camp, Frank Küster said: > Stephen Gran <[EMAIL PROTECTED]> schrieb: > > > Hello all, > > > > I have a source package that generates multiple binary packages. > > Since the packages are similar in a lot of ways (config file structure, > > handling of config files, etc), I have a lot of functions that are the > > same in several maintainer scripts. Ideally, I would like to split them > > out into a common_functions file, and source it each time, instead of > > having lots of redundant code lying around. > > > > So, the binary packages include a -base, that all of the others using > > maintainer scripts Depend on.I know that I can source the common functions > > file in the postinst of all the other packages besides -base > > For the teTeX-3.0 packages, I have taken a different approach, inspired > by Davide Salvetti's nice auctex package: All the maintainer scripts, > and even debian/rules, are created by e-Perl from their corresponding > preinst.in, postinst.in, rules.in, etc. files, and during this > generation process common.functions (and postrm.functions or > postinst.functions) are included. A file debian/variables is also > included, which allows me to define directories, lists of files to act > on, and similar, in a consistent way for all maintainer scripts of all > packages. This is a nice solution. I will take a look at how you do it, and hopefully get it together shortly. Thanks for all the ideas, everyone. -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpzZGY9ieXZp.pgp Description: PGP signature
Re: common function handling in maintainer scripts
This one time, at band camp, martin f krafft said: > also sprach Stephen Gran <[EMAIL PROTECTED]> [2005.02.25.0032 +0100]: > > The second question is (on a completely unrelated note): is there > > any problem with assuming the presence of a color capable $TERM > > Yes. > > > and is > > anything likely to break if I do? > > Output will be unlegible, as it will be interspersed by escape > codes. Right. > > I have seen other linuces that use coloration in init.d scripts > > for success and failure, and I thought it looked kind of cool. > > Since it's easy, I was thinking about doing it in the binary > > packages, but I wanted to ask if it was a bad idea first. > > Uh, make sure you read over the policy, please. I don't think it's > allowed to use colour in the init.d scripts. Which other packages do > so? This isn't RedHat, you know? :) I know, but there is nothing in policy that I could see about this, which is why I asked. No problem, though - this was just sort of an add on that doesn't affect anything, so I won't do so. -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpjLQA0h368R.pgp Description: PGP signature
common function handling in maintainer scripts
Hello all, I have a source package that generates multiple binary packages. Since the packages are similar in a lot of ways (config file structure, handling of config files, etc), I have a lot of functions that are the same in several maintainer scripts. Ideally, I would like to split them out into a common_functions file, and source it each time, instead of having lots of redundant code lying around. So, the binary packages include a -base, that all of the others using maintainer scripts Depend on.I know that I can source the common functions file in the postinst of all the other packages besides -base (and likely in -base as well, since by postinst it should be unpacked, right)? My question is: can I source it in config as well? I suspect not, because of the preconfigure run that apt does. I suppose if I really wanted to do this, I could exit 0 at preconfigure time, and only run it at configure, but that seems wrong to me. The second question is (on a completely unrelated note): is there any problem with assuming the presence of a color capable $TERM, and is anything likely to break if I do? I have seen other linuces that use coloration in init.d scripts for success and failure, and I thought it looked kind of cool. Since it's easy, I was thinking about doing it in the binary packages, but I wanted to ask if it was a bad idea first. Thanks all, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpT4H6NFG1nO.pgp Description: PGP signature
Re: RFS: When, Ben Crowell
This one time, at band camp, Ben Crowell said: > Matthew Palmer wrote: > >[...] Specifically, you'll need to > >provide your sponsor with a standard Debian source package (containing > >orig.tar.gz, diff.gz, and dsc files). > > Ah, thanks for the info, I'm a newbie at this! After going through > the steps given in the Debian New Maintainers' Guide, > http://www.debian.org/doc/maint-guide/ch-build.en.html, > the debianish files I end up with in my directory are these: > > when_1.0.15-1_all.deb: Debian binary package (format 2.0), uses gzip > compression > when_1.0.15-1.diff.gz: gzip compressed data, from Unix, max compression > when_1.0.15-1.dsc: PGP armored data signed message > when_1.0.15-1_i386.changes: PGP armored data signed message > when_1.0.15.orig.tar.gz:gzip compressed data, from Unix > when-1.0.15.tar.gz: gzip compressed data, from Unix > > If the .deb is a binary package, do I need to do something else to create > a source package? Do source packages have a different extension? (Of course > the distinction between source and binary is kind of moot here, since my > program is in pure perl, but I assume they're two different formats?) > It seems like I'd need to do a dpkg-source, but from the man page, I'm > not clear exactly what to do. The guide says in section 6.1 that the > command `dpkg-buildpackage -rfakeroot' should make both a source and > a binary package, but it doesn't seem to have done so...? Your 'source package' is the combination of the three files when_1.0.15.orig.tar.gz, when_1.0.15-1.diff.gz and when_1.0.15-1.dsc. There is no container package, so the name is perhaps a bit misleading. Basically, the dsc contains some information that verifies the orig.tar.gz and the diff.gz, and the diff.gz is the patch against upstream to make it build with debian's infrastructure. > Thanks in advance for any further help you can give! HTH, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpZK9916Rdwi.pgp Description: PGP signature
Re: experimental uploads and closed bugs
This one time, at band camp, Andreas Barth said: > * Stephen Gran ([EMAIL PROTECTED]) [041207 20:10]: > > /usr/share/doc/developers-reference/developers-reference.txt.gz: > > 4.6.4: > >When uploading to unstable a package which had bugs fixed in > >experimental, please consider using the option `-v' to > >`dpkg-buildpackage' to finally get them closed. > > > > It does not actually say what you were asking, but this is the hint that > > bugs are tagged rather than closed by uploads to experimental. It would > > be nice if it were a little more explicit, I agree. > > Do you have a proposal how to write it? If so, please feel free to raise > a bug against the developers reference (or remember me often enough to > fix it :). Adding: Note that uploads to experimental do not close bugs, but they do add the tag 'fixed-in-experimental'. Bugs addressed by NMU's to experimental keep the normal behavior, that is, they add the tag 'fixed'. to the section: 5.8.4 When bugs are closed by new uploads Would probably clarify it. I don't know whether or not you think that's worth a bug report, though. -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpok9E9L8f4b.pgp Description: PGP signature
Re: experimental uploads and closed bugs
This one time, at band camp, Frank Küster said: > Andreas Barth <[EMAIL PROTECTED]> schrieb: > > > * Frank Küster ([EMAIL PROTECTED]) [041207 17:40]: > >> I'm quite sure I read it somewhere, but cannot currently find it: How > >> does the archive software treat bugs that are closed in the changelog of > >> an upload to experimental? Are the bugs tagged fixed, or is nothing done > >> at all? > > > > +fixed-in-experimental for maintainer-uploads > > +fixed for NMUs > > Thank for giving me the fish, also to Adeoato. Will you also teach me > how to catch it? /usr/share/doc/developers-reference/developers-reference.txt.gz: 4.6.4: When uploading to unstable a package which had bugs fixed in experimental, please consider using the option `-v' to `dpkg-buildpackage' to finally get them closed. It does not actually say what you were asking, but this is the hint that bugs are tagged rather than closed by uploads to experimental. It would be nice if it were a little more explicit, I agree. HTH, -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpRk5yMDzMSm.pgp Description: PGP signature
Re: postinstall script and debconf configuration
This one time, at band camp, Matthijs Mohlmann said: > On somehow i can't get this to work. And i don't know why it won't work: You never call the function config() from within the case statement? That, and since you're uisng set -e (as you should be), it'd be better to add '|| true' to all the db_get calls, and do an [ -z "$value" ] && value=false to set the default, rather than hoping debconf always returns something. -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpnIEHfJ4XDz.pgp Description: PGP signature
Re: postinstall script and debconf configuration
This one time, at band camp, Matthijs Mohlmann said: > On somehow i can't get this to work. And i don't know why it won't work: You never call the function config() from within the case statement? That, and since you're uisng set -e (as you should be), it'd be better to add '|| true' to all the db_get calls, and do an [ -z "$value" ] && value=false to set the default, rather than hoping debconf always returns something. -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp86VDz5tANJ.pgp Description: PGP signature
Re: RFS: spampd - a SpamAssassin based SMTP/LMTP scanning proxy daemon
This one time, at band camp, martin f krafft said: > also sprach Stephen Gran <[EMAIL PROTECTED]> [2004.10.02.2156 +0200]: > > Does postfix not have something like exim's routers?(I really am > > asking - I don't know postfix well). I was under the impression > > that one of the strengths of it's modularity was that you could > > plug extra pieces in in the middle of a routing chain for stuff > > just like this. > > Postfix is a MTA, not a MDA. And no, postfix does not know routers. > You can chain filters, but not after the user has been determined. > This is on purpose as it's the domain of mail delivery agents such > as procmail. Remember the UNIX philosophy? Phil Hazel doesn't... I think that's oversimplifying a bit - if postfix can plug in things like A/V scanners or content filters, then it's more than "just an MTA" at this point too. I don't know if you need amavis or something to do this with postfix, but I was under the impression that it could do it natively, with the filter= stuff, or at least I was under the impression that it could from sites like http://regions.rgs.ru/dist/postfix/ I realize it's using external helper programs, but so so do all MTA's - exim doesn't have spamassassin built in, just hooks to it's API. If it can write to the mail spool, whether that's in /var/spool/mail or $HOME, than it is also certainly an MDA, just a limited one. I have never personally seen the advantage of dissociating the MDA from the MTA, myself. I tend to think it's a holdover from sendmail's limitations, and people have gotten under the impression that it's a strength rather than a weakness. I mean, it can already filter early in the email processing (or early enough to 5xx at smtp time, so I hear), and it can deliver, so why can't it filter just before delivery? Doesn't seem like a violation of the design philosophy, so much as an unimplemented possibility of the design. Getting OT into that 'My MTA is better hung' flamewar, though, which I don't want to have, and I don't want to argue with you, Martin - chalk it up to a long day and some tall beer :) Peace, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpFEqCoOUH4R.pgp Description: PGP signature
Re: RFS: spampd - a SpamAssassin based SMTP/LMTP scanning proxy daemon
This one time, at band camp, martin f krafft said: > also sprach Stephen Gran <[EMAIL PROTECTED]> [2004.10.02.2156 +0200]: > > Does postfix not have something like exim's routers?(I really am > > asking - I don't know postfix well). I was under the impression > > that one of the strengths of it's modularity was that you could > > plug extra pieces in in the middle of a routing chain for stuff > > just like this. > > Postfix is a MTA, not a MDA. And no, postfix does not know routers. > You can chain filters, but not after the user has been determined. > This is on purpose as it's the domain of mail delivery agents such > as procmail. Remember the UNIX philosophy? Phil Hazel doesn't... I think that's oversimplifying a bit - if postfix can plug in things like A/V scanners or content filters, then it's more than "just an MTA" at this point too. I don't know if you need amavis or something to do this with postfix, but I was under the impression that it could do it natively, with the filter= stuff, or at least I was under the impression that it could from sites like http://regions.rgs.ru/dist/postfix/ I realize it's using external helper programs, but so so do all MTA's - exim doesn't have spamassassin built in, just hooks to it's API. If it can write to the mail spool, whether that's in /var/spool/mail or $HOME, than it is also certainly an MDA, just a limited one. I have never personally seen the advantage of dissociating the MDA from the MTA, myself. I tend to think it's a holdover from sendmail's limitations, and people have gotten under the impression that it's a strength rather than a weakness. I mean, it can already filter early in the email processing (or early enough to 5xx at smtp time, so I hear), and it can deliver, so why can't it filter just before delivery? Doesn't seem like a violation of the design philosophy, so much as an unimplemented possibility of the design. Getting OT into that 'My MTA is better hung' flamewar, though, which I don't want to have, and I don't want to argue with you, Martin - chalk it up to a long day and some tall beer :) Peace, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpaajLb1CaXz.pgp Description: PGP signature
Re: RFS: spampd - a SpamAssassin based SMTP/LMTP scanning proxy daemon
This one time, at band camp, martin f krafft said: > also sprach Greg Norris <[EMAIL PROTECTED]> [2004.10.02.2046 +0200]: > > I originally tried configuring postfix to do per-user filtering > > via spamc/spamd directly (using the "-u" spamc option), but that > > setup has a number of issues which make it undesirable. > > use procmail as mda and then /etc/procmailrc: > > BEGIN /etc/procmailrc 0644 > SHELL=/bin/sh > DROPPRIVS=yes > COMSAT=no > > SENDMAILFLAGS="$SENDMAILFLAGS -f $2" > > :0 fw > | /usr/bin/spamc > END > > and in main.cf: > > mailbox_command = /usr/bin/procmail -a "$EXTENSION" -a "$SENDER" -a > "$RECIPIENT" DEFAULT=\$HOME/.maildir/ > > not very performant because procmail is a hog, but better than > nothing. Does postfix not have something like exim's routers?(I really am asking - I don't know postfix well). I was under the impression that one of the strengths of it's modularity was that you could plug extra pieces in in the middle of a routing chain for stuff just like this. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpDHRiCTICt5.pgp Description: PGP signature
Re: RFS: spampd - a SpamAssassin based SMTP/LMTP scanning proxy daemon
This one time, at band camp, martin f krafft said: > also sprach Greg Norris <[EMAIL PROTECTED]> [2004.10.02.2046 +0200]: > > I originally tried configuring postfix to do per-user filtering > > via spamc/spamd directly (using the "-u" spamc option), but that > > setup has a number of issues which make it undesirable. > > use procmail as mda and then /etc/procmailrc: > > BEGIN /etc/procmailrc 0644 > SHELL=/bin/sh > DROPPRIVS=yes > COMSAT=no > > SENDMAILFLAGS="$SENDMAILFLAGS -f $2" > > :0 fw > | /usr/bin/spamc > END > > and in main.cf: > > mailbox_command = /usr/bin/procmail -a "$EXTENSION" -a "$SENDER" -a "$RECIPIENT" > DEFAULT=\$HOME/.maildir/ > > not very performant because procmail is a hog, but better than > nothing. Does postfix not have something like exim's routers?(I really am asking - I don't know postfix well). I was under the impression that one of the strengths of it's modularity was that you could plug extra pieces in in the middle of a routing chain for stuff just like this. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpTU83Ylch1q.pgp Description: PGP signature
Re: Debian vs RedHat init script
This one time, at band camp, Chirag Kantharia said: > Hi! > > I'm packaging netdump for Debian. The package comes with it's own > initscripts, which are RedHat specific. I had used the Debian template > for initscript, in my first attempt to package netdump. Using the > RedHat version of the initscript (maintained upstream), I edited > Debian template, to match the functionality provided by the RedHat > initscript. > > Because of this, I have, now, two copies of initscripts (RedHat and > Debian), which my sponsor, thinks, is redundant. The initscripts > differ quite a bit, and I am not sure, if one format can be converted > to another, using simple commands (and thus, be able to maintain just > one copy). > > How do the other packages, get around this? I would be glad, if you > would point me to specific packages, that have a (upstream maintained) > RedHat specific initscript within the package source. One of my packages (clamav) comes with init scripts for both RedHat and Suse. I leave them as is in the source tarball, and just don't put them in the distributed .debs. There are many ways to do this, but I've found the easiest is to have the normal `make install` go to debian/tmp, and then pick what you want out of there to go to the respective package directories. HTH, -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgplQYpqIs8Fq.pgp Description: PGP signature
Re: Debian vs RedHat init script
This one time, at band camp, Chirag Kantharia said: > Hi! > > I'm packaging netdump for Debian. The package comes with it's own > initscripts, which are RedHat specific. I had used the Debian template > for initscript, in my first attempt to package netdump. Using the > RedHat version of the initscript (maintained upstream), I edited > Debian template, to match the functionality provided by the RedHat > initscript. > > Because of this, I have, now, two copies of initscripts (RedHat and > Debian), which my sponsor, thinks, is redundant. The initscripts > differ quite a bit, and I am not sure, if one format can be converted > to another, using simple commands (and thus, be able to maintain just > one copy). > > How do the other packages, get around this? I would be glad, if you > would point me to specific packages, that have a (upstream maintained) > RedHat specific initscript within the package source. One of my packages (clamav) comes with init scripts for both RedHat and Suse. I leave them as is in the source tarball, and just don't put them in the distributed .debs. There are many ways to do this, but I've found the easiest is to have the normal `make install` go to debian/tmp, and then pick what you want out of there to go to the respective package directories. HTH, -- ----- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpFOudYTtm7o.pgp Description: PGP signature
[[:digit:]] - bashism?
Hello all, Looking for some advice. Recently a bug was filed on one of my packages that really had me pulling my hair out - it turned out to be that the test to make sure debconf input was numeric was failing because I use [[:digit:]]* and the user's shell was dash. I've checked the scripts with checkbashisms, and it doesn't think that that's a bash specific thing, but perhaps they missed it. Looking here: http://www.opengroup.org/onlinepubs/009695399/toc.htm , it looks like this is a POSIX expression, so I think I'm right, but I want to be sure before I just reassign the bug to dash. Does anyone know the POSIX standard well enough to know if this is a bug in dash, or a bashism? Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgphjLtn9aCAG.pgp Description: PGP signature
[[:digit:]] - bashism?
Hello all, Looking for some advice. Recently a bug was filed on one of my packages that really had me pulling my hair out - it turned out to be that the test to make sure debconf input was numeric was failing because I use [[:digit:]]* and the user's shell was dash. I've checked the scripts with checkbashisms, and it doesn't think that that's a bash specific thing, but perhaps they missed it. Looking here: http://www.opengroup.org/onlinepubs/009695399/toc.htm , it looks like this is a POSIX expression, so I think I'm right, but I want to be sure before I just reassign the bug to dash. Does anyone know the POSIX standard well enough to know if this is a bug in dash, or a bashism? Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpTZjDrf7tmm.pgp Description: PGP signature
Re: Init Script for Arbitrary Number of Daemons
This one time, at band camp, [EMAIL PROTECTED] said:
> My problem is really starting an arbitrary number...
>
> Perhaps I am guilty of some abuse of language; sorry. There is only one
> daemon, which I am trying to start an arbitrary number of copies of,
> with an arbitrary number of - possibly - different options. I'd like to
> be able to do something like:
>
> ---
> for DAEMON_OPTS in $DAEMON_OPTS_LIST; do
> echo -n " $NAME"
> start-stop-daemon --start --quiet --pidfile /var/run/$NAME.$i.pid \
> --exec $DAEMON -- $DAEMON_OPTS
> done
> ---
You want an array of arrays.
The simplest (although there are many other ways to d this, not all are
as easily self documenting or simple to use) is something like:
/etc/default/package:
# Configure here your options for each running daemon:
DAEMON_1_OPTS="..."
DAEMON_2_OPTS="..."
DAEMON_3_OPTS="..."
#(don't use 'export foo=bar here', just regular variable assignments)
/etc/init.d/package:
if [ -f /etc/default/package ]
. /etc/default/package
fi
# This cuts any line that is only whitespace, or first non-whitespace
# character is a comment (#), and parses the rest.
DAEMON_OPTS_LIST=`egrep -v '^[[:space:]]*(#|$)' /etc/default/package \
| awk -F '=' '{print $1}'`
for DAEMON_OPTS in "$DAEMON_OPTS_LIST"; do
start-stop-daemon --start --quiet --pidfile /var/run/$NAME.$i.pid \
--exec $DAEMON -- $DAEMON_OPTS
done
or something. That would be user configurable and relatively
discoverable. There are many other bash constructs that do this more
efficiently, but you should try to keep the /etc/default file as
straightforward as possible. I am still not sure I am addressing your
question fully, but I think so. I think you want:
single daemon, possibility of running multiple instances
said daemon does not by itself run multiple instances by default
(unlike, e.g, apache)
said daemon should have different options on different instances
I think my proposal allows that to happen, and in a user configurable
way. If that is still not quite what you're looking for, write back -
I'm sure we can dig something else up.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
pgpebnzJGP2xP.pgp
Description: PGP signature
Re: Init Script for Arbitrary Number of Daemons
This one time, at band camp, [EMAIL PROTECTED] said:
> My problem is really starting an arbitrary number...
>
> Perhaps I am guilty of some abuse of language; sorry. There is only one
> daemon, which I am trying to start an arbitrary number of copies of,
> with an arbitrary number of - possibly - different options. I'd like to
> be able to do something like:
>
> ---
> for DAEMON_OPTS in $DAEMON_OPTS_LIST; do
> echo -n " $NAME"
> start-stop-daemon --start --quiet --pidfile /var/run/$NAME.$i.pid \
> --exec $DAEMON -- $DAEMON_OPTS
> done
> ---
You want an array of arrays.
The simplest (although there are many other ways to d this, not all are
as easily self documenting or simple to use) is something like:
/etc/default/package:
# Configure here your options for each running daemon:
DAEMON_1_OPTS="..."
DAEMON_2_OPTS="..."
DAEMON_3_OPTS="..."
#(don't use 'export foo=bar here', just regular variable assignments)
/etc/init.d/package:
if [ -f /etc/default/package ]
. /etc/default/package
fi
# This cuts any line that is only whitespace, or first non-whitespace
# character is a comment (#), and parses the rest.
DAEMON_OPTS_LIST=`egrep -v '^[[:space:]]*(#|$)' /etc/default/package \
| awk -F '=' '{print $1}'`
for DAEMON_OPTS in "$DAEMON_OPTS_LIST"; do
start-stop-daemon --start --quiet --pidfile /var/run/$NAME.$i.pid \
--exec $DAEMON -- $DAEMON_OPTS
done
or something. That would be user configurable and relatively
discoverable. There are many other bash constructs that do this more
efficiently, but you should try to keep the /etc/default file as
straightforward as possible. I am still not sure I am addressing your
question fully, but I think so. I think you want:
single daemon, possibility of running multiple instances
said daemon does not by itself run multiple instances by default
(unlike, e.g, apache)
said daemon should have different options on different instances
I think my proposal allows that to happen, and in a user configurable
way. If that is still not quite what you're looking for, write back -
I'm sure we can dig something else up.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
pgp0.pgp
Description: PGP signature
Re: Init Script for Arbitrary Number of Daemons
This one time, at band camp, [EMAIL PROTECTED] said: > The "skeleton" "init.d" file is a great default for starting _one_ > daemon, complete with the "$DAEMON_OPTS" variable. It's not clear, > however, what this newbie package developer should do to start an > arbitrary number of daemons, each with - potentially - different > "$DAEMON_OPTS". > > It's nice to be able to throw "$DAEMON_OPTS" into > "/etc/default/package" and get get a bit more control over the daemon; > but I can't think how to nicely specify an arbitrary number of > "$DAEMON_OPTS" variables in a "/etc/default/package" script fragment. > > I'm still searching for a solution... Input much appreciated! I am not exactly sure what you mean by arbitrary - I'm assumin you have a real number in mind, but that it could vary (e.g., some may not be selected to actually run at boot, or all could, depending on the setup). If the daemons are useful independently of each other, package them seperately. If not, try one of the following. You can use multiple init scripts, or you can take a look at the init scripts of packages that start multiple daemons (slapd and samba come to mind) for examples of how others do it. If you just want seperate defaults, seperate lines in /etc/default/package would work well - it's just sourced, so DAEMON_1_OPTS="..." DAEMON_2_OPTS="..." etc. If you really mean arbitrary, in the sense that you have no idea how many, I can't help :) HTH, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0i5wUbt68j.pgp Description: PGP signature
Re: Init Script for Arbitrary Number of Daemons
This one time, at band camp, [EMAIL PROTECTED] said: > The "skeleton" "init.d" file is a great default for starting _one_ > daemon, complete with the "$DAEMON_OPTS" variable. It's not clear, > however, what this newbie package developer should do to start an > arbitrary number of daemons, each with - potentially - different > "$DAEMON_OPTS". > > It's nice to be able to throw "$DAEMON_OPTS" into > "/etc/default/package" and get get a bit more control over the daemon; > but I can't think how to nicely specify an arbitrary number of > "$DAEMON_OPTS" variables in a "/etc/default/package" script fragment. > > I'm still searching for a solution... Input much appreciated! I am not exactly sure what you mean by arbitrary - I'm assumin you have a real number in mind, but that it could vary (e.g., some may not be selected to actually run at boot, or all could, depending on the setup). If the daemons are useful independently of each other, package them seperately. If not, try one of the following. You can use multiple init scripts, or you can take a look at the init scripts of packages that start multiple daemons (slapd and samba come to mind) for examples of how others do it. If you just want seperate defaults, seperate lines in /etc/default/package would work well - it's just sourced, so DAEMON_1_OPTS="..." DAEMON_2_OPTS="..." etc. If you really mean arbitrary, in the sense that you have no idea how many, I can't help :) HTH, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: Versioning question
This one time, at band camp, Andreas Metzler said: > I think you are misparsing Colin. The pool managing scripts will > definitely complain if you upload a new foish-bar_0.70.orig.tar.gz. > You /cannot/ replace a foish-bar_0.70.orig.tar.gz in the archive > without changing the name. That was my feeling - thanks. I should not do email before coffe - it leads to all sorts of random output. Thanks all for all the suggestions, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpULomNAjlaG.pgp Description: PGP signature
Re: Versioning question
This one time, at band camp, Humberto Massa said: > I think he meant > > 0.70-rc1 when RC, then 0.70-rel1 when RELEASE > > $ dpkg --compare-versions 0.70-rc1 lt 0.70-rel1 && echo yes > yes Ah, sorry about that. Parse error. That would work, and has the advantage that it's less ugly than the other hacks. The disadvantage of course, is that I'm stuck with it longer :) Thanks for the advice, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpH5H293ca16.pgp Description: PGP signature
Re: Versioning question
This one time, at band camp, Andreas Metzler said: > I think you are misparsing Colin. The pool managing scripts will > definitely complain if you upload a new foish-bar_0.70.orig.tar.gz. > You /cannot/ replace a foish-bar_0.70.orig.tar.gz in the archive > without changing the name. That was my feeling - thanks. I should not do email before coffe - it leads to all sorts of random output. Thanks all for all the suggestions, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: Versioning question
This one time, at band camp, Humberto Massa said: > I think he meant > > 0.70-rc1 when RC, then 0.70-rel1 when RELEASE > > $ dpkg --compare-versions 0.70-rc1 lt 0.70-rel1 && echo yes > yes Ah, sorry about that. Parse error. That would work, and has the advantage that it's less ugly than the other hacks. The disadvantage of course, is that I'm stuck with it longer :) Thanks for the advice, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: Versioning question
This one time, at band camp, Colin Watson said: > There's ~, but you can't use that until sarge has been released. > > In the absence of that, something like 0.69-really-0.70-rc-1 (or what > you suggest) is a common workaround. It's not too bad to change the > tarball name. OK, if it's not a big deal to change the tarball name, then I will just go ahead and do that. I was thinking it made for more complication than it apparently does - the thing I'm worried about is uploading when 0.70 comes out, and I am uploading a new tarball. If both are named 0.70 (wuith only the revision changing from -0rc1 to -1), I thought the pool managing scripts would complain. Maybe the ugly but workable 0.69-really-0.70-rc-1 is the best way to go, so there is definitely no confusion. Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgplqXQ8yqwC2.pgp Description: PGP signature
Re: Versioning question
This one time, at band camp, Michael Koch said: > On Thu, Mar 18, 2004 at 12:55:33PM -0500, Stephen Gran wrote: > > Hello all, > > > > This may be a simple thing that has been solved many times before, but I > > am apparently being stupid about it. I am packaging the newest release > > of one of my packages, and I am having some trouble ensuring > > upgradeability. > > > > The version for this release is 0.70-rc, and upstream says the next > > release will be 0.70. The obvious problem is: > > [EMAIL PROTECTED]:~$ dpkg --compare-versions 0.70-rc-1 lt 0.70-1 && echo yes > > [EMAIL PROTECTED]:~$ > > > > That won't upgrade, so I need some hack to do it. I could go with > > something like 0.70-0rc1, but then I have to change the name of the > > upstream tarball as well to a version that it really isn't, correct? > > Anybody already faced this problem and come up with a reasonable > > solution? > > You could use 0.70-release-1 (or 0.70-rel1). [EMAIL PROTECTED]:~$ dpkg --compare-versions 0.70-release-1 lt 0.70-1 && echo yes [EMAIL PROTECTED]:~$ dpkg --compare-versions 0.70-rel1 lt 0.70-1 && echo yes [EMAIL PROTECTED]:~$ Same result. Thanks, though. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpipNbzjSe3R.pgp Description: PGP signature
Versioning question
Hello all, This may be a simple thing that has been solved many times before, but I am apparently being stupid about it. I am packaging the newest release of one of my packages, and I am having some trouble ensuring upgradeability. The version for this release is 0.70-rc, and upstream says the next release will be 0.70. The obvious problem is: [EMAIL PROTECTED]:~$ dpkg --compare-versions 0.70-rc-1 lt 0.70-1 && echo yes [EMAIL PROTECTED]:~$ That won't upgrade, so I need some hack to do it. I could go with something like 0.70-0rc1, but then I have to change the name of the upstream tarball as well to a version that it really isn't, correct? Anybody already faced this problem and come up with a reasonable solution? Thanks in advance, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpU0toNgLpID.pgp Description: PGP signature
Re: Versioning question
This one time, at band camp, Colin Watson said: > There's ~, but you can't use that until sarge has been released. > > In the absence of that, something like 0.69-really-0.70-rc-1 (or what > you suggest) is a common workaround. It's not too bad to change the > tarball name. OK, if it's not a big deal to change the tarball name, then I will just go ahead and do that. I was thinking it made for more complication than it apparently does - the thing I'm worried about is uploading when 0.70 comes out, and I am uploading a new tarball. If both are named 0.70 (wuith only the revision changing from -0rc1 to -1), I thought the pool managing scripts would complain. Maybe the ugly but workable 0.69-really-0.70-rc-1 is the best way to go, so there is definitely no confusion. Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: Versioning question
This one time, at band camp, Michael Koch said: > On Thu, Mar 18, 2004 at 12:55:33PM -0500, Stephen Gran wrote: > > Hello all, > > > > This may be a simple thing that has been solved many times before, but I > > am apparently being stupid about it. I am packaging the newest release > > of one of my packages, and I am having some trouble ensuring > > upgradeability. > > > > The version for this release is 0.70-rc, and upstream says the next > > release will be 0.70. The obvious problem is: > > [EMAIL PROTECTED]:~$ dpkg --compare-versions 0.70-rc-1 lt 0.70-1 && echo yes > > [EMAIL PROTECTED]:~$ > > > > That won't upgrade, so I need some hack to do it. I could go with > > something like 0.70-0rc1, but then I have to change the name of the > > upstream tarball as well to a version that it really isn't, correct? > > Anybody already faced this problem and come up with a reasonable > > solution? > > You could use 0.70-release-1 (or 0.70-rel1). [EMAIL PROTECTED]:~$ dpkg --compare-versions 0.70-release-1 lt 0.70-1 && echo yes [EMAIL PROTECTED]:~$ dpkg --compare-versions 0.70-rel1 lt 0.70-1 && echo yes [EMAIL PROTECTED]:~$ Same result. Thanks, though. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Versioning question
Hello all, This may be a simple thing that has been solved many times before, but I am apparently being stupid about it. I am packaging the newest release of one of my packages, and I am having some trouble ensuring upgradeability. The version for this release is 0.70-rc, and upstream says the next release will be 0.70. The obvious problem is: [EMAIL PROTECTED]:~$ dpkg --compare-versions 0.70-rc-1 lt 0.70-1 && echo yes [EMAIL PROTECTED]:~$ That won't upgrade, so I need some hack to do it. I could go with something like 0.70-0rc1, but then I have to change the name of the upstream tarball as well to a version that it really isn't, correct? Anybody already faced this problem and come up with a reasonable solution? Thanks in advance, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: Multiple binary source & per-package dh_ options?
This one time, at band camp, Shaul Karl said: > On Fri, Jan 30, 2004 at 04:01:33PM -0500, Stephen Gran wrote: > > Hello all, > > > > I am working on a multi-binary source, and what I want to do is pass > > different options to different packages. Is this possible? I see the > > -p option common to all debhelper programs, but how to do this? > > dh_installinit -p foo -n > > dh_installinit -a > > or something? > > > > Anybody doing anything like this? I can work around it by including the > > debhelper parts in all the scripts and passing the option to all > > packages, but I figured it would be nice to be able to only do it for > > the one I want. > > > > Any pointers welcome. Thanks in advance, > > > You might try the man pages and some other packages. Beside the man > pages for each debhelper program there is a debhelper man page. Trust me I did try the manpages, and the example rules files included in doc/, and some sample source trees. The problem is, with 10,000 or so to choose from, it's difficult to decide which one t go with for unusual packaging. > I didn't understand what you were trying to accomplish with the init > example. In general I have a source tree that produces 7 binary packages. I want one of them to get the --no-scripts option for dh_installinit, but have the rest produce not get this option. So on for some other variants on the same theme. I think Andreas Metzler's reference will take care of it. Thanks. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpwQL8YEwvxi.pgp Description: PGP signature
Re: Multiple binary source & per-package dh_ options?
This one time, at band camp, Shaul Karl said: > On Fri, Jan 30, 2004 at 04:01:33PM -0500, Stephen Gran wrote: > > Hello all, > > > > I am working on a multi-binary source, and what I want to do is pass > > different options to different packages. Is this possible? I see the > > -p option common to all debhelper programs, but how to do this? > > dh_installinit -p foo -n > > dh_installinit -a > > or something? > > > > Anybody doing anything like this? I can work around it by including the > > debhelper parts in all the scripts and passing the option to all > > packages, but I figured it would be nice to be able to only do it for > > the one I want. > > > > Any pointers welcome. Thanks in advance, > > > You might try the man pages and some other packages. Beside the man > pages for each debhelper program there is a debhelper man page. Trust me I did try the manpages, and the example rules files included in doc/, and some sample source trees. The problem is, with 10,000 or so to choose from, it's difficult to decide which one t go with for unusual packaging. > I didn't understand what you were trying to accomplish with the init > example. In general I have a source tree that produces 7 binary packages. I want one of them to get the --no-scripts option for dh_installinit, but have the rest produce not get this option. So on for some other variants on the same theme. I think Andreas Metzler's reference will take care of it. Thanks. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Multiple binary source & per-package dh_ options?
Hello all, I am working on a multi-binary source, and what I want to do is pass different options to different packages. Is this possible? I see the -p option common to all debhelper programs, but how to do this? dh_installinit -p foo -n dh_installinit -a or something? Anybody doing anything like this? I can work around it by including the debhelper parts in all the scripts and passing the option to all packages, but I figured it would be nice to be able to only do it for the one I want. Any pointers welcome. Thanks in advance, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpZNBM2GRIrF.pgp Description: PGP signature
Multiple binary source & per-package dh_ options?
Hello all, I am working on a multi-binary source, and what I want to do is pass different options to different packages. Is this possible? I see the -p option common to all debhelper programs, but how to do this? dh_installinit -p foo -n dh_installinit -a or something? Anybody doing anything like this? I can work around it by including the debhelper parts in all the scripts and passing the option to all packages, but I figured it would be nice to be able to only do it for the one I want. Any pointers welcome. Thanks in advance, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
po2debconf errors
Hello all, I am working on a package that uses po files, inherited from the previous maintainer, and I am getting this during build: po2debconf debian/clamav-daemon.templates > debian/clamav-daemon/DEBIAN/templates Warning:Outdated PO file: debian/po/fr.po, running debconf-updatepo --podir=debian/po WARNING: It seems that none of the files in POTFILES.in contain marked strings What is a 'marked string' and how do I dig about to fix this? I am new to po, so I'm sorry for asking, but I'm not sure where to start digging for this error message. I have looked through the /usr/share/doc stuff and info files, but I'm just not seeing it. Cluebat? -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpihyJuZhEc8.pgp Description: PGP signature
po2debconf errors
Hello all, I am working on a package that uses po files, inherited from the previous maintainer, and I am getting this during build: po2debconf debian/clamav-daemon.templates > debian/clamav-daemon/DEBIAN/templates Warning:Outdated PO file: debian/po/fr.po, running debconf-updatepo --podir=debian/po WARNING: It seems that none of the files in POTFILES.in contain marked strings What is a 'marked string' and how do I dig about to fix this? I am new to po, so I'm sorry for asking, but I'm not sure where to start digging for this error message. I have looked through the /usr/share/doc stuff and info files, but I'm just not seeing it. Cluebat? -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: Moving a config file
This one time, at band camp, Matt Zimmerman said: > On Fri, Dec 05, 2003 at 02:30:46PM -0500, Stephen Gran wrote: > > > This is the kind of thing I want to do - how do I extract $old_version? > > I want to do the move if upgrading from >> 5.4-5, but not after that, so > > that I don't keep on doing funky things to users' conffiles. Pointer to > > refs would great. > > Debian Policy Manual (this is the usual place to look for these things), > section 6.4. Thanks - the cluebat was what I needed. All better now. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpBkwY4Uo9tO.pgp Description: PGP signature
Re: Moving a config file
This one time, at band camp, Matt Zimmerman said: > On Fri, Dec 05, 2003 at 02:30:46PM -0500, Stephen Gran wrote: > > > This is the kind of thing I want to do - how do I extract $old_version? > > I want to do the move if upgrading from >> 5.4-5, but not after that, so > > that I don't keep on doing funky things to users' conffiles. Pointer to > > refs would great. > > Debian Policy Manual (this is the usual place to look for these things), > section 6.4. Thanks - the cluebat was what I needed. All better now. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: Moving a config file
This one time, at band camp, Matt Zimmerman said: > On Thu, Nov 27, 2003 at 04:07:06PM -0500, Stephen Gran wrote: > > > I have to move a config file, and I am not sure of the best way of > > handling it, so I wanted to ask for opinions. > > > > The problem is that I am currently shipping an > > /etc/default/$package, which needs to now become /etc/$package.conf > > - it's not a shell script, but more of a hacked together config > > file. What I want to do is ensure that any user changes to the old > > /etc/default/$package file get seemlessly merged into > > /etc/$package.conf, but not mess up any user made up $package.conf > > Is the file a conffile, or not? Yes - I guess I was unclear. It is shipped as /etc/default/hdparm. What I meant is that it is unsuitable as an /etc/default file because it is the package's configuration file, rather than a sell script setting variables, as required by policy. > If it is a conffile (and if it is shipped in the package, it must be), > then move it in preinst (wrapped in appropriate checks, such as > package version and file existence), and dpkg will handle the rest. This is the kind of thing I want to do - how do I extract $old_version? I want to do the move if upgrading from >> 5.4-5, but not after that, so that I don't keep on doing funky things to users' conffiles. Pointer to refs would great. Thanks, -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpgdHeL1o8WK.pgp Description: PGP signature
Re: Moving a config file
This one time, at band camp, Matt Zimmerman said: > On Thu, Nov 27, 2003 at 04:07:06PM -0500, Stephen Gran wrote: > > > I have to move a config file, and I am not sure of the best way of > > handling it, so I wanted to ask for opinions. > > > > The problem is that I am currently shipping an > > /etc/default/$package, which needs to now become /etc/$package.conf > > - it's not a shell script, but more of a hacked together config > > file. What I want to do is ensure that any user changes to the old > > /etc/default/$package file get seemlessly merged into > > /etc/$package.conf, but not mess up any user made up $package.conf > > Is the file a conffile, or not? Yes - I guess I was unclear. It is shipped as /etc/default/hdparm. What I meant is that it is unsuitable as an /etc/default file because it is the package's configuration file, rather than a sell script setting variables, as required by policy. > If it is a conffile (and if it is shipped in the package, it must be), > then move it in preinst (wrapped in appropriate checks, such as > package version and file existence), and dpkg will handle the rest. This is the kind of thing I want to do - how do I extract $old_version? I want to do the move if upgrading from >> 5.4-5, but not after that, so that I don't keep on doing funky things to users' conffiles. Pointer to refs would great. Thanks, -- --------- | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Moving a config file
Hello all,
I have to move a config file, and I am not sure of the best way of
handling it, so I wanted to ask for opinions.
The problem is that I am currently shipping an /etc/default/$package,
which needs to now become /etc/$package.conf - it's not a shell script,
but more of a hacked together config file. What I want to do is ensure
that any user changes to the old /etc/default/$package file get
seemlessly merged into /etc/$package.conf, but not mess up any user made
up $package.conf
Does the following postinst snippet do it, or should I let standard dpkg
config file handling take care of it, or does anyone have other
suggestions?
# HDPARM_OLD is the md5sum of the unmodified file
HDPARM_MD5=`md5sum /etc/default/hdparm | awk '{print $1}'`
HDPARM_CONF=`md5sum /etc/hdparm.conf | awk '{print $1}'`
HDPARM_OLD="9578464c1ae847fc33d58e049f8c08fc"
if [ -f /etc/hdparm.conf ]; then
if [ ! $HDPARM_CONF = $HDPARM_OLD ]; then
echo -n "Backing up old hdparm.conf . . "
mv /etc/hdparm.conf /etc/hdparm.conf.dpkg-old
echo "done"
fi
fi
if [ -f /etc/default/hdparm ]; then
if [ $HDPARM_MD5 = $HDPARM_OLD ]; then
# New basic default config file already added, just remove cruft
rm /etc/default/hdparm
else
echo -n "Moving /etc/default/hdparm to /etc/hdparm.conf . . "
mv /etc/default/hdparm /etc/hdparm.conf
echo "done"
fi
fi
There is also a note in README.Debian that the config file location has
changed. The problem I see with the above is that by the time postinst
runs, there will already be /etc/hdparm.conf, as it is shipped in the
package. So I see the flow of logic as, if /etc/hdparm.conf exists, and
is changed (most likely the user has made their own), then back up
theirs - if it is the same as the shipped, do nothing. If the old
config file exists, but is unchanged, remove it - they now have the new
config file. If it is changed, mv it to the new location.
Thanks for any comments,
--
-----
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
pgppRbwQ2Zd1T.pgp
Description: PGP signature
Moving a config file
Hello all,
I have to move a config file, and I am not sure of the best way of
handling it, so I wanted to ask for opinions.
The problem is that I am currently shipping an /etc/default/$package,
which needs to now become /etc/$package.conf - it's not a shell script,
but more of a hacked together config file. What I want to do is ensure
that any user changes to the old /etc/default/$package file get
seemlessly merged into /etc/$package.conf, but not mess up any user made
up $package.conf
Does the following postinst snippet do it, or should I let standard dpkg
config file handling take care of it, or does anyone have other
suggestions?
# HDPARM_OLD is the md5sum of the unmodified file
HDPARM_MD5=`md5sum /etc/default/hdparm | awk '{print $1}'`
HDPARM_CONF=`md5sum /etc/hdparm.conf | awk '{print $1}'`
HDPARM_OLD="9578464c1ae847fc33d58e049f8c08fc"
if [ -f /etc/hdparm.conf ]; then
if [ ! $HDPARM_CONF = $HDPARM_OLD ]; then
echo -n "Backing up old hdparm.conf . . "
mv /etc/hdparm.conf /etc/hdparm.conf.dpkg-old
echo "done"
fi
fi
if [ -f /etc/default/hdparm ]; then
if [ $HDPARM_MD5 = $HDPARM_OLD ]; then
# New basic default config file already added, just remove cruft
rm /etc/default/hdparm
else
echo -n "Moving /etc/default/hdparm to /etc/hdparm.conf . . "
mv /etc/default/hdparm /etc/hdparm.conf
echo "done"
fi
fi
There is also a note in README.Debian that the config file location has
changed. The problem I see with the above is that by the time postinst
runs, there will already be /etc/hdparm.conf, as it is shipped in the
package. So I see the flow of logic as, if /etc/hdparm.conf exists, and
is changed (most likely the user has made their own), then back up
theirs - if it is the same as the shipped, do nothing. If the old
config file exists, but is unchanged, remove it - they now have the new
config file. If it is changed, mv it to the new location.
Thanks for any comments,
--
-----
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
pgp0.pgp
Description: PGP signature
Looking for apt-get internals guide
Hello all, This is not precisely on-topic for this list, as I am not looking to package this stuff for debian (yet), but other lists seemed even less appropriate. Sorry about that. The reason I am writing is that a company I work for (all debian shop - yay!) uses a package to ease administration and set up working defaults and users and so forth. This package ships a lot of application- specific files in it that hopelessly violate policy. They exist simply to patch config files for other packages, or add logcheck-ignore rules, or the like. What I want to do is add a hook into apt (probably something in apt.conf.d) that would see if we are either installing a package that we have files for, or have already installed a package that we have files for, and then take the appropriate action. To do so, I ned to know a little more about apt's guts than I do currently, I'm afraid, and I was hoping someone could point me to a good reference guide about how apt calls external programs (like apt-listchanges) and parsing the syntax that apt calls with and that sort of thing. Hopefully I've been clear enough - I only have a rough roadmap in my head at this point. Other suggestions for smarter ways of doing this would be welcome as well. Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgprHE5hq2alA.pgp Description: PGP signature
Looking for apt-get internals guide
Hello all, This is not precisely on-topic for this list, as I am not looking to package this stuff for debian (yet), but other lists seemed even less appropriate. Sorry about that. The reason I am writing is that a company I work for (all debian shop - yay!) uses a package to ease administration and set up working defaults and users and so forth. This package ships a lot of application- specific files in it that hopelessly violate policy. They exist simply to patch config files for other packages, or add logcheck-ignore rules, or the like. What I want to do is add a hook into apt (probably something in apt.conf.d) that would see if we are either installing a package that we have files for, or have already installed a package that we have files for, and then take the appropriate action. To do so, I ned to know a little more about apt's guts than I do currently, I'm afraid, and I was hoping someone could point me to a good reference guide about how apt calls external programs (like apt-listchanges) and parsing the syntax that apt calls with and that sort of thing. Hopefully I've been clear enough - I only have a rough roadmap in my head at this point. Other suggestions for smarter ways of doing this would be welcome as well. Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
A question about boot order
Hello all, I recently took over hdparm when it was orphaned, and as I was looking it over, I decided to finally add the init script that had multiple wishlist bugs open as I wanted the feature anyway. I wrote up something I'm happy with as far as the script itself goes (although more review would always be welcome if anyone wants to look - it's in the archive now). My reason for writing in is that I am trying to figure out where in the boot order to place it - I have taken the 'defaults' for now, as that doesn't really harm anything. I would like to move it earlier in the boot sequence, but still leave wiggle room if an admin screws up. This means moving it to the very beginning of entering a runlevel (rc2-5.d/S10 or so). It makes the most sense to me to have it right after mountall, but that leaves no room in case of error, and I'm not happy with that - this program has too much potential to do real harm. Do my ideas seem reasonable, or should I say 'the admin really should know better, I am going to place it where it actually does the most good' - which would be rcS/S41 or so - ? I prefer to protect users from potential harm where possible, but I am looking for others opinions on this. Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgplWCiqYWDpW.pgp Description: PGP signature
A question about boot order
Hello all, I recently took over hdparm when it was orphaned, and as I was looking it over, I decided to finally add the init script that had multiple wishlist bugs open as I wanted the feature anyway. I wrote up something I'm happy with as far as the script itself goes (although more review would always be welcome if anyone wants to look - it's in the archive now). My reason for writing in is that I am trying to figure out where in the boot order to place it - I have taken the 'defaults' for now, as that doesn't really harm anything. I would like to move it earlier in the boot sequence, but still leave wiggle room if an admin screws up. This means moving it to the very beginning of entering a runlevel (rc2-5.d/S10 or so). It makes the most sense to me to have it right after mountall, but that leaves no room in case of error, and I'm not happy with that - this program has too much potential to do real harm. Do my ideas seem reasonable, or should I say 'the admin really should know better, I am going to place it where it actually does the most good' - which would be rcS/S41 or so - ? I prefer to protect users from potential harm where possible, but I am looking for others opinions on this. Thanks, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: RFS: anteater
This one time, at band camp, Andrea Capriotti said: > I'm an applicant and I'm looking for a sponsor. > > http://nm.debian.org/nmstatus.php?email=a.capriotti%40nettuno.it > > Package: anteater Some nitpicks (some important, some less so): You ship an empty /usr/sbin (debian/dirs) You ship two copies of the manpage, one in /usr/share/man/man1/ and one in /usr/share/man/man1/man1/. The tar.gz of upstream source should be renamed to anteater_0.4.4.orig.tar.gz. And lintian says: E: anteater source: package-lacks-versioned-build-depends-on-debhelper 4 N: N: If a package sets debhelper's compatibility version to >= 1, either N: via DH_COMPAT, or via debian/compat, or via dh_testversion (which is N: deprecated), it must declare a versioned Build-Depends on the needed N: version of debhelper. HTH, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: RFS: anteater
This one time, at band camp, Andrea Capriotti said: > I'm an applicant and I'm looking for a sponsor. > > http://nm.debian.org/nmstatus.php?email=a.capriotti%40nettuno.it > > Package: anteater Some nitpicks (some important, some less so): You ship an empty /usr/sbin (debian/dirs) You ship two copies of the manpage, one in /usr/share/man/man1/ and one in /usr/share/man/man1/man1/. The tar.gz of upstream source should be renamed to anteater_0.4.4.orig.tar.gz. And lintian says: E: anteater source: package-lacks-versioned-build-depends-on-debhelper 4 N: N: If a package sets debhelper's compatibility version to >= 1, either N: via DH_COMPAT, or via debian/compat, or via dh_testversion (which is N: deprecated), it must declare a versioned Build-Depends on the needed N: version of debhelper. HTH, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Sponsor for xmms-bumpscope and xmms-synaesthesia
This one time, at band camp, John Lightsey said: > Hi there, > > I'm looking for someone to review and sponsor two xmms visualization plugins. > > All the relevant files are here: > > http://www.nixnuts.net/xmms-bumpscope.tar.gz This one looks OK. > http://www.nixnuts.net/xmms-synaesthesia.tar.gz This one does ... interesting things to my display with either of the full screen options checked - instead of theexpected full-screen display of the plugin, I get a resized display similar to choosing a default resolution with a larger virtual screen size in X - I'm left looking at just a corner of the screen. Fortunately, it was the same corner that xmms was in, and I could stop it, and the screen resized on exit. Using X 4.3 here, don't know if it works on X 4.2. Packaging looks good otherwise, might want to investigate this build warning: configure.in:26: warning: AC_TRY_RUN called without default to allow cross compiling in xmms-synaesthesia. autotools issue? HTH, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Sponsor for xmms-bumpscope and xmms-synaesthesia
This one time, at band camp, John Lightsey said: > Hi there, > > I'm looking for someone to review and sponsor two xmms visualization plugins. > > All the relevant files are here: > > http://www.nixnuts.net/xmms-bumpscope.tar.gz This one looks OK. > http://www.nixnuts.net/xmms-synaesthesia.tar.gz This one does ... interesting things to my display with either of the full screen options checked - instead of theexpected full-screen display of the plugin, I get a resized display similar to choosing a default resolution with a larger virtual screen size in X - I'm left looking at just a corner of the screen. Fortunately, it was the same corner that xmms was in, and I could stop it, and the screen resized on exit. Using X 4.3 here, don't know if it works on X 4.2. Packaging looks good otherwise, might want to investigate this build warning: configure.in:26: warning: AC_TRY_RUN called without default to allow cross compiling in xmms-synaesthesia. autotools issue? HTH, -- - | ,''`. Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: dpkg-gencontrol breakage?
This one time, at band camp, Stephen Gran said:
> This one time, at band camp, Stephen Gran said:
> > This one time, at band camp, Goswin von Brederlow said:
> > > Stephen Gran <[EMAIL PROTECTED]> writes:
> > >
> > > > Hello all,
> > > >
> > > > I'm seeing this in a package I'm an uploader for:
> > > >
> > > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > > dpkg-gencontrol: warning: unknown substitution variable ${F:Version}
> > > >
> > > > These are, to my knowledge, legitimate fields, no? Is this known
> > > > breakage? I looked at the bug reports for debhelper and dpkg, and I
> > > > don't see anything about this - am I just looking in the wrong place?
> > >
> > > Afaik that happens when there are unset, e.g. no libs to depend on
> > > whrere found.
OK, sorry, I think I misparsed what was happening - I thought that the
above errors were stopping the build, but it's a later error, where the
value of ${F:Version} is needed. That's easy enough to work around, but
I'm still not sure why ${F:Version} is no longer valid.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: dpkg-gencontrol breakage?
This one time, at band camp, Stephen Gran said:
> This one time, at band camp, Stephen Gran said:
> > This one time, at band camp, Goswin von Brederlow said:
> > > Stephen Gran <[EMAIL PROTECTED]> writes:
> > >
> > > > Hello all,
> > > >
> > > > I'm seeing this in a package I'm an uploader for:
> > > >
> > > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > > dpkg-gencontrol: warning: unknown substitution variable ${F:Version}
> > > >
> > > > These are, to my knowledge, legitimate fields, no? Is this known
> > > > breakage? I looked at the bug reports for debhelper and dpkg, and I
> > > > don't see anything about this - am I just looking in the wrong place?
> > >
> > > Afaik that happens when there are unset, e.g. no libs to depend on
> > > whrere found.
OK, sorry, I think I misparsed what was happening - I thought that the
above errors were stopping the build, but it's a later error, where the
value of ${F:Version} is needed. That's easy enough to work around, but
I'm still not sure why ${F:Version} is no longer valid.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: dpkg-gencontrol breakage?
This one time, at band camp, Stephen Gran said:
> This one time, at band camp, Goswin von Brederlow said:
> > Stephen Gran <[EMAIL PROTECTED]> writes:
> >
> > > Hello all,
> > >
> > > I'm seeing this in a package I'm an uploader for:
> > >
> > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > dpkg-gencontrol: warning: unknown substitution variable ${F:Version}
> > >
> > > These are, to my knowledge, legitimate fields, no? Is this known
> > > breakage? I looked at the bug reports for debhelper and dpkg, and I
> > > don't see anything about this - am I just looking in the wrong place?
> >
> > Afaik that happens when there are unset, e.g. no libs to depend on
> > whrere found.
>
> Wll, I think that would be a bug - it should pass a null string,
> rather than something unparseable, and I remember it used to. This
> looks to me like it actually has problems parsing the string - 'unknown
> substitution variable' doesn't imply an unset variable, but a variable
> name that is undefined.
>
> Also, ${F:Version} should be expanded to the Version string from the
> package named, and so should never be unset, right?
>
> Ah, it looks like this may be the change:
> dpkg (1.10.14) unstable; urgency=low
>
> * controllib.pl:
> * Rewrote the parsedep stuff, so that it wasn't done during control
> file parsing. Scripts that need the internal parsed format should
> call parsedep on the field's value.
> * Split the substvars parsing into a separate function.
> * No longer validate dependency fields when reading the control file.
> Some fields may have vars in them, which breaks the validation.
> * dpkg-gencontrol calls substvars after parsing the control file, and
> then validates the substituted depends lines. Originally,
> substitution occured only during writing of the final output file.
>
> Have to go look at the actual source and file a bug, I guess. I have a
> hard time believing nobody's seen this before now, though.
To answer my own question, it looks like the parsing field is broken.
This is the code from :
if (defined($substvar{$vn})) {
$v= $lhs.$substvar{$vn}.$rhs;
$count++;
} else {
&warn("unknown substitution variable \${$vn}");
$v= $lhs.$rhs;
}
It doesn't need to warn here, and it should return '' instead of
$lhs.$rhs - this is where the literal quoting of the variable name is
coming from, I think. Maybe I'm wrong - I don't particularly know dpkg
internals. This still doesn't explain why F:Version isn't getting
filled out, but I'll chase that down later.
Any one have any suggestions, or comments, besides the obvious 'file a
bug?'
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: dpkg-gencontrol breakage?
This one time, at band camp, Goswin von Brederlow said:
> Stephen Gran <[EMAIL PROTECTED]> writes:
>
> > Hello all,
> >
> > I'm seeing this in a package I'm an uploader for:
> >
> > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > dpkg-gencontrol: warning: unknown substitution variable ${F:Version}
> >
> > These are, to my knowledge, legitimate fields, no? Is this known
> > breakage? I looked at the bug reports for debhelper and dpkg, and I
> > don't see anything about this - am I just looking in the wrong place?
>
> Afaik that happens when there are unset, e.g. no libs to depend on
> whrere found.
Wll, I think that would be a bug - it should pass a null string,
rather than something unparseable, and I remember it used to. This
looks to me like it actually has problems parsing the string - 'unknown
substitution variable' doesn't imply an unset variable, but a variable
name that is undefined.
Also, ${F:Version} should be expanded to the Version string from the
package named, and so should never be unset, right?
Ah, it looks like this may be the change:
dpkg (1.10.14) unstable; urgency=low
* controllib.pl:
* Rewrote the parsedep stuff, so that it wasn't done during control
file parsing. Scripts that need the internal parsed format should
call parsedep on the field's value.
* Split the substvars parsing into a separate function.
* No longer validate dependency fields when reading the control file.
Some fields may have vars in them, which breaks the validation.
* dpkg-gencontrol calls substvars after parsing the control file, and
then validates the substituted depends lines. Originally,
substitution occured only during writing of the final output file.
Have to go look at the actual source and file a bug, I guess. I have a
hard time believing nobody's seen this before now, though.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: dpkg-gencontrol breakage?
This one time, at band camp, Stephen Gran said:
> This one time, at band camp, Goswin von Brederlow said:
> > Stephen Gran <[EMAIL PROTECTED]> writes:
> >
> > > Hello all,
> > >
> > > I'm seeing this in a package I'm an uploader for:
> > >
> > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > dpkg-gencontrol: warning: unknown substitution variable ${F:Version}
> > >
> > > These are, to my knowledge, legitimate fields, no? Is this known
> > > breakage? I looked at the bug reports for debhelper and dpkg, and I
> > > don't see anything about this - am I just looking in the wrong place?
> >
> > Afaik that happens when there are unset, e.g. no libs to depend on
> > whrere found.
>
> Wll, I think that would be a bug - it should pass a null string,
> rather than something unparseable, and I remember it used to. This
> looks to me like it actually has problems parsing the string - 'unknown
> substitution variable' doesn't imply an unset variable, but a variable
> name that is undefined.
>
> Also, ${F:Version} should be expanded to the Version string from the
> package named, and so should never be unset, right?
>
> Ah, it looks like this may be the change:
> dpkg (1.10.14) unstable; urgency=low
>
> * controllib.pl:
> * Rewrote the parsedep stuff, so that it wasn't done during control
> file parsing. Scripts that need the internal parsed format should
> call parsedep on the field's value.
> * Split the substvars parsing into a separate function.
> * No longer validate dependency fields when reading the control file.
> Some fields may have vars in them, which breaks the validation.
> * dpkg-gencontrol calls substvars after parsing the control file, and
> then validates the substituted depends lines. Originally,
> substitution occured only during writing of the final output file.
>
> Have to go look at the actual source and file a bug, I guess. I have a
> hard time believing nobody's seen this before now, though.
To answer my own question, it looks like the parsing field is broken.
This is the code from :
if (defined($substvar{$vn})) {
$v= $lhs.$substvar{$vn}.$rhs;
$count++;
} else {
&warn("unknown substitution variable \${$vn}");
$v= $lhs.$rhs;
}
It doesn't need to warn here, and it should return '' instead of
$lhs.$rhs - this is where the literal quoting of the variable name is
coming from, I think. Maybe I'm wrong - I don't particularly know dpkg
internals. This still doesn't explain why F:Version isn't getting
filled out, but I'll chase that down later.
Any one have any suggestions, or comments, besides the obvious 'file a
bug?'
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: dpkg-gencontrol breakage?
This one time, at band camp, Goswin von Brederlow said:
> Stephen Gran <[EMAIL PROTECTED]> writes:
>
> > Hello all,
> >
> > I'm seeing this in a package I'm an uploader for:
> >
> > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > dpkg-gencontrol: warning: unknown substitution variable ${F:Version}
> >
> > These are, to my knowledge, legitimate fields, no? Is this known
> > breakage? I looked at the bug reports for debhelper and dpkg, and I
> > don't see anything about this - am I just looking in the wrong place?
>
> Afaik that happens when there are unset, e.g. no libs to depend on
> whrere found.
Wll, I think that would be a bug - it should pass a null string,
rather than something unparseable, and I remember it used to. This
looks to me like it actually has problems parsing the string - 'unknown
substitution variable' doesn't imply an unset variable, but a variable
name that is undefined.
Also, ${F:Version} should be expanded to the Version string from the
package named, and so should never be unset, right?
Ah, it looks like this may be the change:
dpkg (1.10.14) unstable; urgency=low
* controllib.pl:
* Rewrote the parsedep stuff, so that it wasn't done during control
file parsing. Scripts that need the internal parsed format should
call parsedep on the field's value.
* Split the substvars parsing into a separate function.
* No longer validate dependency fields when reading the control file.
Some fields may have vars in them, which breaks the validation.
* dpkg-gencontrol calls substvars after parsing the control file, and
then validates the substituted depends lines. Originally,
substitution occured only during writing of the final output file.
Have to go look at the actual source and file a bug, I guess. I have a
hard time believing nobody's seen this before now, though.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
