Re: RFS: zynaddsubfx
On Mon, Dec 17, 2007 at 01:01:30PM -0500, Barry deFreese wrote: > Barry deFreese wrote: >> I am CC'ing Debian QA because this fixes an RC bug and the maintainer may >> be MIA. >> >> I am looking for a sponsor for the new version 2.2.1-4.1 >> of my package "zynaddsubfx". > > OK, I have uploaded another version with a couple of more fixes and have > moved the source changes from diff.gz to patches. A quick glance at the package made me conclude two things: - It seems you did a good job fixing lots of things, making the package much better. - This is not an NMU upload, but a QA upload. If the maintainer is indeed MIA, that's fine, but he might not be, so I'm currently not sponsoring this. QA team, how should this be handled? Do we wait for you to confirm MIA-ness, or do you upload the package yourself if he is MIA? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Developer wishing to join "the debian train"
Hi, On Wed, Dec 19, 2007 at 12:19:23AM +0100, Richard van Roy wrote: > I'm a programmer with at least abdicate understanding of C++ and a long > time Debian user. At the moment I have a lot of free time and I wish to > spent this productively by aiding Debian in development. Great, welcome. :-) > I really do not have a clue where to start. I thought of taking over a > near dead package that was up for adoption. That's a good choice. Try to pick something you use yourself, and in a language that you understand. > But I really don't have a clue what my jobs as a maintainer are (And > I'm a little ashamed of that) Does it mean I have to remove bugs and > improve the package and coordinate others to do the same??? It all comes down to "keeping the package in a good shape". That means fixing bugs in the packaging (things like incorrect dependencies) and making sure bugs in the package are fixed (either by doing it yourself, or by asking "upstream" (the people who wrote the code) to do it). In Debian terminology, "feature requests" are called "wishlist bugs" and should also be fixed (although that can sometimes be done by saying "I don't agree that this is a useful feature" ;-) ). In many cases, you can of course also fix things which are not reported. You can always report them first yourself if it makes you happy. :-) In case of large bugs, and certainly security-related bugs, this is even a good idea for the sake of documentation. > Maybe if I don't even know what a maintainer is, it is not the time of > becoming one. Well, if you think it would be nice, you have some reading to do. No reason to stop before finding out what it is. :-) As was suggested already, you should read the new maintainer's guide. Eventually, you should also read the policy manual and the developers' reference. However, you can start working before you've read all that. Looking at the tables of contents when you're working on something is a good idea though. :-) All these documents can be found under http://www.debian.org/devel/. > Another thing (I think) is to help with the bugs and todo's of > packages, but this seems to me like a fast moving train, which is fine > by me, but I have no idea how to jump in and join the ride. That's QA stuff. Help is always very welcome there. :-) You don't even need any special permissions. Just read bug descriptions of release-critical bugs, and see if you can fix them. Lists of RC bugs can be found via http://bugs.debian.org/release-critical/. In particular using the links on the bottom of the page. I think it may be better to do some packaging before fixing bugs, so you know how a package looks and what can be wrong with it. However, when fixing bugs in the upstream code, that is less of a concern. > So my question is, does anybody have any tips on how to “jump in the > train” like a sad before, I'm a good programmer but constantly when I > wish to join Debian I'm a bit confused or maybe overwhelmed. You should probably start with reading the new maintainer's guide. And then create some packages. First just package anything, it doesn't have to go into Debian. Or adopt an orphaned package (see NM guide about how to do that). When you have problems, you can ask them on this list or on irc (irc.debian.org, #debian-mentors). More more howto-style documentation, you can read things at http://wiki.debian.org/ (I think). Most importantly, remember to always do things you like to do. If you feel that things are not going the way you like them, and you are unable to do anything about it, go do something else. We're a volunteer project, and we shouldn't torture ourselves. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFS: zynaddsubfx
On Sat, Dec 22, 2007 at 07:35:48PM +, tim hall wrote: > Joerg Jaspert wrote: >> Its in no way important, not even near to it. Its priority extra, so >> lowest possible priority. > > Sorry, wrong terminology. It's a very useful multimedia application, which > many people use and would expect to find in Debian. Therefore it is worth > making the extra effort to keep it well maintained IMO. The point being > that debian-multimedia should deal with it if group maintenance is needed > rather than QA. I don't know the package myself, but if this is true, it seems that the package should be priority optional, not extra. Extra is for packages which you only want if you have special needs. (There are also no conflicts.) Whoever is going to improve and/or take over this package might want to consider changing this. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: ifeq in an if statement
On Sun, Jan 27, 2008 at 01:20:45AM +0100, Laszlo Boszormenyi wrote: > If I add findstring like: > @if [ -f $(GRADM_PAM) ] ; then \ > echo "Installing gradm_pam..." ; \ > $(INSTALL) -m 4755 $(GRADM_PAM) $(DESTDIR)/sbin ; \ > ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) > $(STRIP) $(DESTDIR)/sbin/$(GRADM_PAM) ; \ > endif > fi > I get: > /bin/sh: -c: line 3: syntax error near unexpected token `,' > /bin/sh: -c: line 3: `ifeq (,)' > make[1]: *** [install] Error 2 > > What do I miss? If a backslash appears just before a newline, both will be ignored. This is a very nice, but it also means your ifeq statement doesn't start at the beginning of a line, and it is therefore not parsed by make. As you can see from the error message, it's sh, not make, which is complaining about not understanding the ifeq, which makes sense. The other suggestion to set STRIP to true is probably a nice solution for your problem. If you really want to use ifeq, you'll need to put the entire logical line in it (the whole block, until the line without a \ at the end), and use an else with the same block plus the STRIP line. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFS: QA Upload - imlib - Two bug fixes, including RC bug
On Mon, Feb 04, 2008 at 12:37:36PM -0500, Barry deFreese wrote: > Hi folks, Hi Barry, :-) > I've uploaded a version of imlib that fixes an important and RC bug. If > someone has time to review/sponsor. I'll try to have a look at it tomorrow. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFS: (3 packages)
Hi, Sorry for the delay. I'll have a look at these, hopefully today. If anyone is faster, don't wait for me, though. ;-) On Mon, Feb 04, 2008 at 10:04:39PM +0800, LI Daobing wrote: > I am looking for a sponsor for the new version 1:0.4.1-1 > of my package "qterm". On Wed, Feb 06, 2008 at 11:08:33AM +0800, LI Daobing wrote: > I am looking for a sponsor for the new version 1.8-2 > of my package "lunar-applet". On Wed, Feb 06, 2008 at 02:11:42PM +0800, LI Daobing wrote: > I am looking for a sponsor for my package "libgcl". Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFC/RFS: zerofree - zero free blocks from ext2/3 file-systems
Hi, On Wed, Feb 06, 2008 at 05:25:15PM +0100, Thibaut Paumard wrote: > I am looking for a sponsor for my package "zerofree". I have several other packages waiting for me at the moment, so I'm afraid I can't do that (at least not soon). > Note that I have set the Dm-Upload-Allowed field. This package is > unrelated to the work I usually do with my sponsor Christoph Haas, which > is why I prefer to ask here rather than to him. In that case, I think it is not appropriate to set the field. It should be set in an upload by someone who has seen more work of you (if possible on that package), and who trusts you with it. I'm not saying you can't be trusted with this package. It may be fine to have the field, I wouldn't know. But that's exactly the point. ;-) So I'd advise to get a sponsor who will upload new versions at least 2 or 3 times before adding the flag. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Copyright question
On Wed, Feb 06, 2008 at 05:46:31PM +0100, Stefan Potyra wrote: > Hi, > > Am Mittwoch, 6. Februar 2008 16:30 schrieb Jean Parpaillon: > > Hi, > > I intend to package HPL benchmarks. Copyright file contains the > > following statements: > > -- > > 1. Redistributions of source code must retain the above copyright > > notice, this list of conditions and the following disclaimer. > > > > 2. Redistributions in binary form must reproduce the above copyright > > notice, this list of conditions, and the following disclaimer in the > > documentation and/or other materials provided with the distribution. > > > > 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. > > > > > > I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can > > someone help me ? If it's not ok, may it be in contrib ? > > IANAL, but this license doesn't seem to allow modification, does it? Good point. Which brings us to the next point: this is really a question for -legal. I'm sending it there with this mail. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote: > Bas Wijnen <[EMAIL PROTECTED]> writes: > > > I suggest to mandate "remove all generated files in the clean target" > > (formulated in a way which includes "generated by upstream", not only > > "generated by the build target), which implies "rebuild everything in > > the build target". > > [...] > > > I'd like to hear why this exception is so important for people. Or > > better yet, I'd like to hear that everyone agrees with me, so we can > > make this change and finally to the Right Thing. :-) > > It may be less common now, but for many years it was quite common for > upstreams to use very specific versions of autotools, which means that if > Debian had dropped the specific autoconf in question, it wasn't easy to > regenerate the files. Now, that may be a problem for other reasons since > as you point out it means we don't really have horribly usable source, but > that's the most common practical concern, I think. Oh, I didn't know that. IMO that would mean the package should really be in contrib, because we're missing a build dependency in main then (not used, but AFAIK using pre-built files is not an acceptable way to avoid getting in contrib in such a situation). Anyway, I don't think that is still a reason for not running autotools nowadays, so it's just historical background. :-) > Always re-running autoconf and automake would increase the number of > FTBFS's that we'd need to fix. Not really. It would lead to many bugs that packages aren't following policy. Especially if we start with should and later (possibly) upgrade it to must, I think it is workable. In particular because these bugs don't actually stop a package from being built. I would be very happy with consensus that the autotools _should_ be run during build. The implementation of actually doing it in all packages may take a while, I don't have a problem with that. Unless of course you are talking about cdbs. When that changes to running autotools, it likely needs to know if there are extra arguments. That may indeed result in FTBFSs for many packages which use it (because they may need, but don't provide, the arguments). But it's good when they're fixed as well. :-) > (Probably for the greater good of free software, but.) Yes, IMO it's one of those situations where Debian should do what's Right, not what's Easy (similar to what I wrote about the /bin/sh bash->dash move on -policy today). > Also, it's not always easy to figure out which files are generated in > order to remove them, but that's probably programmatically fixable. That's in principle a problem for the maintainer to solve, and secundarily for lintian. If things can be automated, that may be nice, but it is not required. Once policy mandates to remove generated files in the clean target, it's up to the maintainer to do it. And if the maintainer makes a mistake and forgets to remove a file, that's not a big problem (it would be a bug with this change in policy, but only a minor one, IMO). At this moment however, I don't think there is consensus yet that it is always better to remove all generated files, including autotools-generated stuff, in the clean target. After that happens, we can think about how to implement it in the archive. Slowly, I would suggest. :-) Because it is a good thing if we do this Right, but we shouldn't break half the archive for it. ;-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 11, 2008 at 03:19:36PM -0800, Russ Allbery wrote: > Bas Wijnen <[EMAIL PROTECTED]> writes: > > On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote: > > >> Always re-running autoconf and automake would increase the number of > >> FTBFS's that we'd need to fix. > > > Not really. > > No, really, I promise it will. :) Each time we upgrade autoconf, it will > break a bunch of packages that were doing things that weren't supported. Ah, that is a point. But that should not be the case if the packages build-depend on the right version, or is it still a problem? I know automake in particular changes a lot between versions, but that's why I always build-depend on a version (such as "automake1.10"). That's recommended as well AFAIK. So the problem of removing old versions of automake (such as automake1.8 at the moment) gets bigger, but it shouldn't make it FTBFS bugs most of the time. > > Yes, IMO it's one of those situations where Debian should do what's > > Right, not what's Easy (similar to what I wrote about the /bin/sh > > bash->dash move on -policy today). > > I am generally in favor of that, but I also don't have the free time to > volunteer for the release team, who ends up bearing the brunt of us doing > the right thing in this area, so, y'know, easy for me to say. :) I'm happy to report bugs and provide patches for many packages if that helps doing this properly. > > That's in principle a problem for the maintainer to solve, and > > secundarily for lintian. > > Well, yeah, but it would still be nice to provide some help. Sure. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Lintian: outdated-autotools-helper-file
On Mon, Feb 11, 2008 at 05:40:58PM +0530, Kapil Hari Paranjape wrote: > On Mon, 11 Feb 2008, Bas Wijnen wrote: > > I suggest to mandate "remove all generated files in the clean target" > > (formulated in a way which includes "generated by upstream", not only > > "generated by the build target), which implies "rebuild everything in > > the build target". > > It is a good idea if one can use .orig.tar.gz to be the same as the > upstream .tar.gz whenever it is DFSG-free to do so. Yes, I agree with that, but it seems unrelated. > Note that if the upstream's auto-generated files are deleted during > the clean target, then the source *must* be re-packaged to avoid > needless clutter in the .diff.gz which is of a "negative" nature. Not at all. Firstly, policy only allows repackaging of the upstream tarball when really needed (to remove non-free contents, or because it's not in .tar.gz format), and even when you do it, you must not make more changes than really needed. It is unacceptable to repackage just to avoid cluttering the diff.gz, or even to avoid it by making changes to an already (for good reasons) repackaged tarball. Secondly, when the clean target removes all generated files, they are ignored when generating the diff.gz, so it doesn't actually clutter it. It does produce some warnings during make clean, but those are not a problem IMO. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Lintian: outdated-autotools-helper-file
On Mon, Feb 11, 2008 at 02:17:54PM +0100, Daniel Leidert wrote:
> Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino:
> > Il giorno Mon, 11 Feb 2008 10:53:48 +0100
> > Bas Wijnen <[EMAIL PROTECTED]> ha scritto:
> >
> > > I suggest to mandate "remove all generated files in the clean target"
> > > (formulated in a way which includes "generated by upstream", not only
> > > "generated by the build target), which implies "rebuild everything in
> > > the build target".
> >
> > I fully agree with you here: the build target should also build Makefile.in
> > from Makefile.am, for example. Thus we clean *.in, *.sub, *.guess, in the
> > clean
> > target.
>
> The files you mention belong to the maintainer-clean target.
Most of them, yes. In my Makefile.ams I have an "autoclean" target,
which really removes everything. Some things are installed by autotools
with the intention that you turn them into source files (INSTALL for
example). I want those removed as well, because they aren't source
files on my system.
> To remove them in the debian/rules clean target you would often have
> to repackage the source tarball,
What gave you that idea? What sort of change do you expect to need that
can't be done in the diff.gz?
> which often includes patching, because many autotools-based build
> environments do not fully implement maintainer-clean.
Except for packages where I am upstream, I don't think I know any
packages which have a proper autoclean target. Indeed, in such a case
Debian should do it by itself. Not that it's very hard. It's simply a
matter of:
AUTOJUNK = list of files to potentially remove
ifneq ($(wildcard ${AUTOJUNK},))
rm -r $(wildcard ${AUTOJUNK},)
endif
Or, if you're lazy, you can just use rm -rf. I prefer this method,
because -f hides more errors than just "file doesn't exist".
> Otherwise you would need to duplicate maintainer-clean in the
> debian/rules clean target (good luck with large source archives, maybe
> including even sub-projects!).
Your package plus its build-depends must contain the full source of
whatever is built. The source of every single generated file _must_
already be in your package anyway. If you can give an example of a
package which would need extra source files to build everything in it,
then please file a bug against it.
> You further need to build depend on the whole autotools chain +
> additional tools like gnome-doc-utils or intltool or
Not a big problem, and also very reasonable: if someone wants to build
this package from source, she does indeed need all those packages. If
a user wants to make changes to the source, those packages are needed
anyway to get those changes reflected in the package.
As a good example you can have a look at gnujump. I could have just
called configure and make. But I decided to run autotools during build.
I found that it needed autoconf-archive, plus an argument to the
autoconf invocation, to make it compile. If I would not have
regenerated configure during the build process, it would have been
easier for me. But when users would try to build the package from real
source, they would find that they couldn't. And they would need to find
out why. I think it is a Good Thing(tm) if Debian's build scripts can
be used as documentation for how a package can be built from source.
> We simply copy config.sub and config.guess into the build directory for
> some years now and I never observed any problem with this.
The mail you replied to was about such a problem, you even quoted it. I
just told you about a problem with gnujump. The whole reason we're
having this discussion is because there are problems with the current
approaches.
You are saying "Building from source means we need dependencies, and you
have to figure out how to build the program, and there are lots of
problems in general. Let's just use pre-built files instead."
This is of course entirely true. It is also true for every other
generated file. Why not pre-compile bash, put it in the diff.gz
uuencoded, and let debian/rules just uudecode it? It makes things much
easier, you don't get nasty build failures, and you don't need many
build-dependencies.
Let's for the moment ignore the architecture-specific problems of that
approach. I hope you agree with me that it still isn't an acceptable
way to package bash? Why do you want to allow it for
autotools-generated files?
> I'm really wondering why you want to make the situation complicated?
The "complication" that I'm adding is that I want to build things from
source. AFAIK that is something everyone agrees on as a Good Thing.
Only for some reason there is an exception for autotools.
> >
Re: Lintian: outdated-autotools-helper-file
On Sun, Feb 10, 2008 at 03:48:20PM -0800, Russ Allbery wrote: > Raphael Geissert <[EMAIL PROTECTED]> writes: > > > Quoting the Debian Policy, section 4.9 Main building script: > > debian/rules[1] > > > >> clean > >> > >> This must undo any effects that the build and binary targets may > >> have had, except that it should leave alone any output files > >> created in the parent directory by a run of a binary target. > > > > So according to the policy the clean target must put the original > > files back on place. > > This Policy dictate as written is pretty widely ignored and (IMO) is > somewhat hard to defend in several of its implications. We haven't > figured out what to say instead, but deleting the files is fairly > common right now. > > See http://bugs.debian.org/397939 for some additional discussion. Thank you for this link. I would like to add a suggestion as a solution. IMO the important thing is, as stated by Bill, that "clean" and "clean; binary; clean" should result in the same tree. From the log it seems that people agree that this implies either creating a huge diff.gz, or running autotools in the clean target. This is not true if you simply build the whole package from source. That is, run autotools during build, remove all generated files, including Makefile.in, configure, etc, in the clean target. For some reason many people seem to think that the whole package must be built from source, except for configure and Makefile.in. I still don't understand what the idea behind this exception is. Especially when it leads to unwanted concequences (unreadable diff.gzs, for example), I don't think it is a good idea to hold on to the idea that running autotools is not part of building the package. Apart from that, this discussion is about users making changes to the source and compiling a package with those changes in it. When not running autotools during build, that doesn't work if the user changes Makefile.am or configure.ac. Yet another undesirable effect of this strange exception to "build everything from source". I suggest to mandate "remove all generated files in the clean target" (formulated in a way which includes "generated by upstream", not only "generated by the build target), which implies "rebuild everything in the build target". With the current wording it is allowed to use shipped built files from the upstream tarball, as long as the source is present. It is even allowed to ship the build results (uuencoded, for example) in the diff.gz and use those. I suppose we all agree that this is unacceptable for normal build results. Now reread the previous paragraph while thinking of Makefile.in instead of "normal build results". It is common practice to do exactly that: ship and use pre-built versions, or even ship them in the diff.gz (which then gets huge). Makefile.am is only present as source-file, but it isn't used at all during the build. Any changes the user makes will not be noticed by the build system. I'd like to hear why this exception is so important for people. Or better yet, I'd like to hear that everyone agrees with me, so we can make this change and finally to the Right Thing. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Thu, Feb 14, 2008 at 04:43:52PM -0500, Clint Adams wrote: > On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote: > > I suggest to mandate "remove all generated files in the clean target" > > (formulated in a way which includes "generated by upstream", not only > > "generated by the build target), which implies "rebuild everything in > > the build target". > > Tell me how I, as an upstream, can use an experimental version of > libtool in that situation. Upstream can do whatever they want, of course. Policy only applies to Debian. So I'll instead answer the question "How can I, as a packager, follow this rule when upstream uses an experimental version of libtool?" If a package requires a compiler which currently is not in Debian (main), then the package cannot be in main either (even if the compiler is free). This situation you describe falls in that category IMO. A workaround could be to not regenerate the files. This is how it is usually done now. IMO that is incorrect, because the compiler for every generated file must be in Debian. The current practise of not rerunning autotools makes this rule technically unnecessary, but it can still be violated (and that should still be considered a bug, even if it doesn't result in a build failure). Another workaround could be to include the experimental libtool in the package. This is not a very good idea, and it would probably be better to package the new libtool as a separate package (not named "libtool", to avoid it being used as default) and Build-Depend on that. Even better would probably be to convince upstream to not use features of experimental versions. That may of course not always be possible. :-) Does this answer your question? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote: > Bas Wijnen <[EMAIL PROTECTED]> writes: > > A workaround could be to not regenerate the files. This is how it is > > usually done now. IMO that is incorrect, because the compiler for every > > generated file must be in Debian. The current practise of not rerunning > > autotools makes this rule technically unnecessary, but it can still be > > violated (and that should still be considered a bug, even if it doesn't > > result in a build failure). > > Note that libtool is an unusual case here and isn't the same as Autoconf > or Automake. The files included in the package (libtool.m4 and ltmain.sh) > are not generated files in the same sense. Running libtoolize basically > just copies those files from the installed libtool into the package. Oh, ok. That changes things a bit. In that case, not copying them, but using the included copy instead is similar to using an included version of a library instead of the package containing it. This is bad for security, but not a problem with respect to policy. > I think (but am not at all certain) that ltmain.sh is a generated file in > that I don't think it's maintained in that form by the libtool > maintainers, but if so, whatever generation is done is already done as > part of the installation of libtool. In that case, my proposal would require it to be copied from there, and not used from upstream. That is wise anyway, but if it would just be a copy of the source, it would strictly not be required. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008 at 03:07:59PM +, Colin Watson wrote: > On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote: > > This is not true if you simply build the whole package from source. > > That is, run autotools during build, remove all generated files, > > including Makefile.in, configure, etc, in the clean target. > > > > For some reason many people seem to think that the whole package must be > > built from source, except for configure and Makefile.in. I still don't > > understand what the idea behind this exception is. Especially when it > > leads to unwanted concequences (unreadable diff.gzs, for example), I > > don't think it is a good idea to hold on to the idea that running > > autotools is not part of building the package. > > It's a well-established principle of the GNU build system that there are > targets that are run by maintainers and there are targets to be run by > people building the package. This division is there to make our lives > easier, and ignoring it, IMHO, is cutting off our nose to spite our > face. (Even the section in the GNU Coding Standards regarding the > maintainer-clean target doesn't go so far as deleting configure.) So according to the GCS, even the maintainer shouldn't need to regenerate configure, or at least not by default. This doesn't quite prove your point, that this is a "maintainter-only" thing. ;-) Anyway, AFAIK the reason that autoconf exists is to allow building programs reliably, even on exotic architectures. They may have really weird shells, or a weird make, or libraries in weird places needing special flags, etc. That is a good thing. I am happy that it is possible to build the programs on those architectures with relatively little trouble. One of the essential things of autoconf there, is that it doesn't require itself to be installed. The generated configure script should be very platform-independent. It is pre-built exactly for that reason: to make sure that the build does not require autoconf to be installed. So far so good. But Debian isn't an exotic system. It's GNU with a Linux kernel. You can't get more standard than that, from autoconf's (thus GNU's) point of view. We don't need this super-platform-independence on our system. We have a proper shell, GNU make, and autoconf and automake can be installed without any trouble. In other words, there is no reason to use the pre-built files. Their reason for existing isn't applicable to Debian. > The underlying problem here is that users who change configure.ac etc. > need to do some additional manual work to update the build system, and > that this should be done automatically. I agree. However, this is not > the same as regenerating the full build system from scratch on every > build. Let's compare it with a Java program. Would you consider it acceptable for the packager to build it, uuencode it, put it in the diff.gz and from debian/rules just uudecode it, instead of regenerating it? I fail to see the difference between this and using a pre-built configure and Makefile.in. Compiled Java is also platform independent (AFAIK), so there isn't even a problem with architectures. > You should be aware, if you aren't already, that the process of > generating a package's build system from scratch is often really quite > complicated Of course it is. That's exactly the reason that I care so much about it. If it would be trivial, everyone could just do it, even without using debian/rules, or having it as an example. > and may well involve network access, which build daemons do > not have. Building the package should not require network access. The package is built using the version which was "the newest" (I hope) when it was created. While it could be nice to be able to use newer versions of things, I agree that we do not want that. It makes builds less reproducible, for example. > For example, the usual update process for a package that uses > Gnulib involves rsyncing translations for some messages from > translationproject.org. And so this step is not needed for the Debian package (but it would be nice if debian/rules did actually contain a target for it). > If you mandate that Debian maintainers must support full build system > regeneration on every build, then you will force some of them to > maintain a separate bootstrapping process which is guaranteed not to > access the network, which will involve duplicating work already done > by upstream and will undoubtedly introduce errors at some point. While I think Gnulib is not a good example (AFAIK it contains GNU libc functions for platforms without GNU libc, which are unused if they are available natively), I see your point. I think this should be uncommon,
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008 at 11:15:20AM -0800, Russ Allbery wrote: > Bas Wijnen <[EMAIL PROTECTED]> writes: > > > Autoconf is pretty stable, > > This has not been the experience of many of us. I haven't had a lot of > trouble fixing things for newer releases of Autoconf, but I definitely > have seen issues. So far I haven't, but I readily believe they do exist. :-) > And the Autoconf 2.13 to 2.50 transition and all the subsequent > instability was not that long ago. Ok, but I don't think anything like that should happen again soon. If it does become as unstable as automake, we can just use the same versioning system in our packages. Also, updating autoconf becomes a bit more tricky, like updating gcc currently is. It should all be fine, but when actually doing it, some packages don't like it anyway. I think this is acceptable. There's always the easy quick-fix of build-depending on the old version (which should then remain in the archive). Of course, all this is only needed if it turns out that these problems aren't just hypothetical. > > so I suppose you're talking about automake. Because of its interface > > instability, you should never depend on "automake", but always on > > "automake1.10" (or whatever version you tested with). > > Just FYI: > > windlord:~> apt-cache policy automake1.10 > automake1.10: > Installed: (none) > Candidate: (none) > Version table: It's a virtual package, provided by automake. When 1.11 is released, I suppose it becomes a real package. Perhaps it's nicer to make "automake" virtual, not "automake1.10", but it doesn't make much difference IMO. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008 at 09:29:59PM +, Mark Brown wrote: > On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote: > > > The fact that there exist packages which work properly without > > recompiling from source doesn't mean it's a good default. IMO the > > default should be to always compile from source. Yes, that means hassle > > for the packager; it's pretty much the whole task of packaging. > > It's probably worth bearing in mind that there are quite a few people > out there who use autotools for want of a standard alternative and are > either indifferent to it or actively dislike it. Often people have been > burned by the version incompatbilities in the past and try to avoid > having anything to do with it - I've seen people do things like check > the generated files into their VCS to avoid dealing with the churn. I'm > not sure how prevalent this is it is an issue. Yes, that's a good point. For such cases, I don't mind if the package would keep the bug for having an improper clean target open and/or tagged upstream, because it is hard to fix. > > > In other words, this proposal will have the effect of requiring that > > > Debian maintainers become experts in the Autotools before being able > > > to upload policy-compliant packages again, > > > Not at all. Autoconf is pretty stable, so I suppose you're talking > > Not as stable as, say, C by a long way... C isn't really that stable. When we upgrade the default gcc version, there're always some packages that break. Of course they break on not being proper C, but still, the problems exist. I think there are less problems with new autoconf versions, but I didn't check that. > > then IMO it's totally reasonable that that weirdness is in debian/rules, > > so users can see what's happening, if they want to. > > OTOH if the standard Debian build process jumps through unusual hoops > like forcing regeneration of all the autotools files that makes it less > useful as a guide for the things you'd actually want to do in the normal > course of affairs. The things are pretty separate IME. The parts which do the compile after autotools have been run can easily be found in most cases. If not, then the file probably wasn't readable without running autotools either. ;-) As an example, I needed 3 extra lines and a Build-Depends for gnujump: export ACLOCAL=aclocal-1.9 -I /usr/share/autoconf-archive export AUTOMAKE=automake-1.9 autoreconf -f -i -s (The last line in the build target.) When I wrote that, I didn't know automake-1.10 was out (if it was...) Otherwise I would have used that and tested with it. > I know I've found Debian packages very useful for that when doing > things like working on programs for upstream purposes or for > non-Debian things like cross development. Yes, I'm regularly using debian/rules as documentation as well. I don't usually want to check autotools stuff, but it would sure be nice if I could. For example, I think it is very useful in gnujump that debian/rules (and control) shows that autoconf-archive is needed, and how it is used, to run aclocal. > > > I'm sure that that would make the security team's life a lot harder, > > > for instance > > > Perhaps you mean that lots of bugs pop up when "automake" increases its > > version? In that case I apologize for being unclear; I thought it was > > commonly known and agreed upon that you should always build-depend on > > the versioned package. > > If you're willing to do things by forcing a particular version in the > general case then this sounds more like something that could be checked > outside the standard package build process. No, I don't want to force a version, I want the package to force it. That is, if a package requires automake-1.4, it should ask for that. Build-depending on "automake" is dangerous, because with a new automake release it's not at all unlikely that you have given yourself an FTBFS bug. > If you're keen on introducing this I'd suggest doing some work to see > how much effort would be involved in doing so. I'm happy to do so, but don't really see where I could start. I would probably want to regenerate the autotools files for packages which currently depend on autotools-dev. However, I think there isn't really a standard way for that. That's the reason I want it in debian/rules. :-) Or do you mean I should manually transition some packages? I'm happy to try some which are likely hard. If anyone has a package which is a good candidate (and preferably, which they don't mind running autotools at build time, so my work is actually used), please let me
Re: Writing get-orig-source targets to conform with policy
On Sun, Feb 17, 2008 at 11:30:42PM +0100, David Paleino wrote: > Il giorno Sun, 17 Feb 2008 13:59:51 -0500 > Andres Mejia <[EMAIL PROTECTED]> ha scritto: > > > On Sunday 17 February 2008 11:37:54 am David Paleino wrote: > > > > > Why not using $(CURDIR)? It should give you the dir where debian/ is > > > located (i.e. $(CURDIR) == debian/../). I've always used it in my > > > debian/rules files, and never had any problem. > > > > $(CURDIR) gives you the current working directory you are in, not where > > debian/ would reside unless you were in the package's top directory anyway. > > When you execute debian/rules, $(CURDIR) *MUST* give you the package's top > directory. That's a firm point. Am I missing something? Yes. That this is only true when executing debian/rules. Not when executing /home/user/src/debian/packages/foo-1.3/debian/rules . The get-orig-source target specifies that it must work from anywhere. So you can't rely on CURDIR to be where debian/ is. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Writing get-orig-source targets to conform with policy
On Mon, Feb 18, 2008 at 12:30:32AM +0100, Daniel Leidert wrote: > Am Sonntag, den 17.02.2008, 23:58 +0100 schrieb Bas Wijnen: > > [..] > > The get-orig-source target specifies that it must work from anywhere. > > Where do you read this? The policy says, that it "[..] may be invoked in > any directory [..]". That's what I was referring to. > To my understanding, this is not a "must work from anywhere". I agree, > that script-calls should work from any directory. But I expect the > user to run the target at a place, where the user has write > permissions. I don't want to add tests and checks for this. But this > would be necessary to fulfill the requirement you state. Of course the user needs write permissions. The meaning of get-orig-source is to write a file to the current directory. If the user isn't allowed to write there, trying to do this should obviously result in an error. Any sensible implementation (that is, just about any implementation except running a shell script without -e) does this automatically without the need for an explicit check. So indeed, my formulation was a bit sloppy. Sorry about that. What I meant to say was that the tarball should also be created (if the user has enough permissions) in the working directory, if that is not the top-level build directory. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 18, 2008 at 12:47:41PM +, Mark Brown wrote:
> On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote:
> > On Sun, Feb 17, 2008 at 09:29:59PM +, Mark Brown wrote:
> > > If you're willing to do things by forcing a particular version in the
> > > general case then this sounds more like something that could be checked
> > > outside the standard package build process.
> >
> > No, I don't want to force a version, I want the package to force it.
>
> By forcing a version I mean doing so in the package.
Then I still don't understand your statement above. What is the thing
that you prefer to check outside the normal build process?
> > > If you're keen on introducing this I'd suggest doing some work to see
> > > how much effort would be involved in doing so.
>
> > Or do you mean I should manually transition some packages? I'm happy to
>
> Yes, that's the sort of thing I meant.
Ok, I'll see what I can do. I repeat my request for packages which may
be hard to transition. If I get none of those, I'll just pick some
random packages from the archive which currently build-depend on
autotools-dev.
It would be nice to have some consensus that my transition efforts are
not wasted though. So I have a question:
Does everyone agree that it would in theory be better to run autotools
during the build process? In other words, if you don't have to do
anything to your packages for it, would you have a problem with this?
("you" above is addressed to anyone reading this.)
> > > We already have regular tests for things that aren't caught by the
> > > normal build processes, this could be checked in a similar fashion.
>
> > We could check if an automake upgrade would produce many FTBFSs, if the
> > packages are already build-depending on automake. However, most
> > packages currently don't do that, and it's in the general case not
> > possible (AFAICS) to run it for them automatically.
>
> What I'm suggesting is that if you add something out of the normal build
> process which regenerates autotools stuff (like an extra target in the
> rules file, for example) then we could test this without doing it on
> every single build.
I still consider "not building from source" to be a Bad Thing, and
therefore I think this is the wrong approach.
The best argument I've heard so far, is "we care more about other bugs,
and we want to be able to ignore those". However, I don't really think
this is a big problem. The program was tested with the same automake
version that it is built with. Why would it suddenly FTBFS? I can see
that it might do so while doing the transition to running autotools
during the build. But that's the maintainer's problem. They can take
their time (or ask me for help :-) ). It's not a big problem if they
delay following my proposed rule. Once they have changed their rules
files, things should just keep working.
And if it doesn't, a dirty workaround of not running autotools can
always be installed, if fixing whatever problem does come up seems to be
too hard.
Build-depending on versioned automake doesn't look really nice, though.
This is how it currently should be done, AFAIK, but it might be better
to recommend against it. However, in that case great care must be taken
when increasing its version, similar to increasing the default gcc
version.
All this can easily be tested before actually starting the transition,
though, just like with gcc. Bugs can be filed and fixed to make
packages work with the newer automake before it becomes the default.
Transitions may be some work, but they shouldn't result in too much
breakage. And if the RMs don't like it, and want us to spend time on
other bugs, they can just say "the newer automake will not be the
default for the next release, therefore bugs with it are not RC".
> > > Personally, I expect the package to restore things to the state they
> > > were in the distribution tarball.
>
> > That has been suggested, but it would mean backing up generated files
> > which get overwritten during the build (such as config.guess and
> > config.sub). There seems to be agreement that such backing up is not
> > useful.
>
> My point is that I don't expect the clean target to clean with respect
> to anything except the upstream tarball rather than going around making
> things clean with respect to upstream revision control or similar.
So you don't want to remove files which are unchanged during the build.
Do you agree on removing all files which were changed though? I think
even that would require rerunning of some autotools parts in some cases,
but I'm not sure.
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 18, 2008 at 12:39:29PM -0800, Chris Waters wrote: > But honestly, I think our job is to deliver full source and binaries. > I _don't_ think we necessarily have to exercise every bit of the > source (e.g. the .am files) on every build. In fact, my primary > objections to the java example would be a) that it confounds user > expectations, and b) that it would result in huge diffs. I'm not sure > that either of those objections would apply to the autoconf case. At least the huge diff does, that's one of the documented (in autotools-dev's README.Debian) downsides of not running autotools during package build. > > The fact that there exist packages which work properly without > > recompiling from source doesn't mean it's a good default. IMO the > > default should be to always compile from source. Yes, that means hassle > > for the packager; it's pretty much the whole task of packaging. > > I think there's a big difference between recompiling from source as an > end user would do and (re)generating _everything_ as an upstream might > do. I suspect the ultimate question here is: does Debian serve as a) > a proxy for the user, generating binaries so they don't have to, or b) > as a proxy for upstream? I tend to lean towards the former position; > it sounds like you lean towards the latter. Probably, although I'm not sure who we're proxying from and to then. ;-) I think providing binary packages which work to users is certainly a very important part of Debian. However, that's not everything. We also want to keep it free, and one important aspect of that is that we provide source packages which work as well. To me, a "working" source package is the complete source plus build rules (which work ;-) ) for that source. And that's all the source, not just a part of it. Of course, the suggestion to add a debian/rules target which does this which doesn't have to be run during the normal build process would work for this as well. One problem I have with that is that it'll be much less tested. This can be fixed by running automated testing, as also suggested, but I think it will still mean that we will have packages which can't be compiled from source. Another problem is that the normal build rules will still generate a huge and unreadable diff.gz. I would therefore still prefer to build everything from source. However a recommended (or even mandatory) extra target to at least be able to do it would be acceptable to me. That doesn't solve the "what should the clean target do exactly" problem, though. Is "remove all files which have been changed during the build" an acceptable answer to that? If that means autotools must be rerun during normal build (which I think will be the case sometimes), is that acceptable to most people? As a sidestep, I think this target may actually be legally required for GPL (at least 2 and 3) licenced code. They say For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. (version 2), and The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. (version 3). In other words, build rules to generate the binary from source must be present. If upstream doesn't normally ask from users that they regenerate all files, that doesn't mean that we should make it as hard for the users as well. Because that's the main result of not running autotools IMO: it makes it harder for the user to make use of the sources. I think this also has to do with: > Well, I see one big difference. I often get patches from downstream > to configure. Perhaps this is because when running debian/rules that's the file that is used as the source. If any other file would be changed, they should include instructions for how that change can be made part of the package. (In the simplest case a list of extra build-depends.) > But to me, this indicates that downstream often considers the > configure file to be a readable source format. This cannot be said of > a uuencoded binary. I think that's an important distinction. I do agree with this, though. :-) > Bottom line: it sounds like you think the java example is > fundamentally wrong; Indeed. > I merely see it as flawed, awkward and hard to maintain: a bad idea in > general, but not necessarily wrong. Interesting... I didn't expect Debian people to disagree with me on that... (Just to be clear, that's saying something about my expectations, not about your opinion being wrong or anything. ;-) ) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a bet
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Mon, Feb 18, 2008 at 10:14:24PM +, Mark Brown wrote: > > Then I still don't understand your statement above. What is the thing > > that you prefer to check outside the normal build process? > > That we can regenerate the autotools products. I answered this in another reply. Sorry for not merging it with this one. > > Does everyone agree that it would in theory be better to run autotools > > during the build process? In other words, if you don't have to do > > anything to your packages for it, would you have a problem with this? > > If I didn't have to do anything - but the maintainer is at least going > to have to upload changes to run autotools. What I mean is that I make the required changes to the packages and send patches to everyone. All the maintainers need to do then is apply the patch (and maintain the result, but I'm also happy to help with that). > > Build-depending on versioned automake doesn't look really nice, though. > > This is how it currently should be done, AFAIK, but it might be better > > to recommend against it. However, in that case great care must be taken > > when increasing its version, similar to increasing the default gcc > > version. > > Of course, doing this introduces all the work that was causing people to > raise concerns about this... Yes, and I share those concerns, which is why I didn't recommend this. However, thinking more about it, it really is the Right Thing. And when doing it the same way as we handle gcc, I think it shouldn't be causing too much trouble, even. > > Of course this is a separate point. IMO clean should remove any file > > which was changed during the build. And secondly, I think build should > > regenerate everything it can. Combined, these can be formulated as > > "clean should remove all non-source files", because every shipped > > non-source file must be updated (and thus changed) by the build. > > Right, half the thing for me is that I don't see this as being something > that we need to check on each and every single build. If we build separate infrastructure to test it, it would likely also try to do this for every upload. And preferrably on different (or even all) architectures we support. So if we make this whole extra check work right, it isn't actually costing any less computing time. Assuming that is what you have against doing it on every build, that is... Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Tue, Feb 19, 2008 at 11:22:04PM +0100, Kurt Roeckx wrote: > On Tue, Feb 19, 2008 at 10:50:23AM +0100, Bas Wijnen wrote: > > As a sidestep, I think this target may actually be legally required for > > GPL (at least 2 and 3) licenced code. They say > > > > For an executable work, complete source code means all the > > source code for all modules it contains, plus any associated > > interface definition files, plus the scripts used to control > > compilation and installation of the executable. > > (version 2), and > > The "Corresponding Source" for a work in object code form means > > all the source code needed to generate, install, and (for an > > executable work) run the object code and to modify the work, > > including scripts to control those activities. > > (version 3). > > > > In other words, build rules to generate the binary from source must be > > present. > > The GPL does not require us to build anything. Just that the source > are available. Yes. But in "source" any scripts needed to build it are included. So having a debian/rules target which can generate configure, and not running it, is fine. Not having it is a violation of the license AFAICS. > I would also like to point out this exception from the autoconf license: This is about configure itself. It means that autoconf may be used to generate a configure for a non-GPL project. It doesn't mean that using autoconf is a way to avoid having to follow the GPL on a project's source. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Tue, Feb 19, 2008 at 11:00:55PM +, Mark Brown wrote: > It's not just the computing resources required that concern me, it's > also the effort involved in doing it and the disruption that could be > caused, especially if we were to do things like changing autotools > versions underneath the package. I think by doing things the gcc-way, there shouldn't be much trouble at all, and as far as there is, we can delay it until we have time (by waiting with the upgrade). But if this is a concern for many people, it is of course possible to do it in a separate (but not optional, IMO) target. It should be defined in a way which allows easy building of the binary package from real source. (This should be the normal situation if you call it before dpkg-buildpackage. However, it should be mandated that this really works, and that the normal build doesn't still use some other generated files.) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: GPG key change
On Wed, Feb 20, 2008 at 04:23:03PM +0100, David Paleino wrote: > is there any procedure to follow in case one needs to revoke his GPG > key (thus creating a new one)? > > I mean, I have some packages in Debian, which are signed by my current > key (0x1392B174). Packages in Debian are signed by a DD or DM key, which was valid (and in the keyring) at the time the package was installed. So unless you are a DM, your packages were not signed by your key (a sponsor replaces the signature with his own when sponsoring). > Is it sufficient to start signing new packages with my new key? You should get some signatures on your new key so people can trust it. Then you can use it as usual. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Machine-interpretable debian/copyright with little files without copyright info
On Wed, Feb 20, 2008 at 05:24:42PM +0100, Giovanni Mascellani wrote: > I'd like to convert my very little packages to the > machine-interpretable debian/copyright format described on the Wiki. Good idea. :-) > In my packages (but I think that this applies to many others) I have > some very little files, such as README or tiny documentations, which > don't include any specification of copyright holder or license terms, > and that are so little that it would be absurd to add them. Doesn't the combination have any either? If the combination is big enough to be copyrightable (and that's not big at all), then without such a statement Debian cannot distribute it. The statement doesn't have to be in every file (that's just recommended "to be sure", which I think is mostly about big files), but it has to be somewhere. > How should I cope with them? I couldn't find anything about this on the > Wiki page, maybe someone should add a few words on the question (I can > do it, once I get an answer!). I don't know what should be done with uncopyrightable pieces. However, they're so small, that you can just repeat them and say it's yours. ;-) Then again, in that case they're probably not worth packaging. Because a combination of several of those pieces is copyrightable, and needs a copyright statement and a license (from the person who combined them). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Requests for sponsors to upload NMUs
Hi, On Wed, Mar 05, 2008 at 01:34:39PM +, Neil Williams wrote: > On Wed, 2008-03-05 at 12:37 +, Sune Vuorela wrote: > > On 2008-03-05, Neil Williams <[EMAIL PROTECTED]> wrote: > > >> of course is changing SONAMEs in a NMU appropriate if it is appropriate. > > > > > > That equates to a hostile hijacking. If the package is orphaned or if > > No it don't. it is just bugfixing. If it requires binary incompatible > > changes to fix it, of course the SONAME should be changed as well. Else > > you introduce new bugs. > > Such intrusive "fixes" should not be done without at least trying to > contact the maintainer. Of course. I didn't understand it otherwise. However, if contacting fails, and the SONAME upgrade is needed to fix a bug, then it may be acceptable to do this in an NMU. Since it's a big change, it would be good to make all delays in the process a bit longer than required, but in the end it may still be acceptable to do a SONAME bump in an NMU. > If this is to fix an RC bug, then yes, a SONAME might need changing but > this should not be done without consensus or without very good cause. Of course. A SONAME change is very intrusive, and it is clear that it must not be done lightly. > At the very least, contact debian-release for advice before changing a > SONAME in an NMU close to a release freeze. That sounds like a very good idea. > Do *not* change a SONAME in an NMU merely on a lintian warning/error. Does a SONAME change ever fix (or hide) a lintian bug? Ah well, as far as I can see we all agree that this is not something to do in an NMU. > > You seem to be living in perfect-world where maintainers are always > > reachable. > > Or just busy. Every NMU must give the maintainer a chance to fix the > problem themselves. The zero-day BSP only applies if the RC bug has > already been open for more than 7 days, specifically to allow time for > the maintainer to fix the problem themselves. Sune mentioned uploading to DELAYED/7. Doing that will give the maintainer 7 days, not only to come up with his own solution, but also to see whether the proposed (at that moment) NMU is acceptable. Of course it is possible to post the patch to the BTS, wait, and after 7 days do a non-DELAYED NMU upload. The DELAYED queue just automates that process. > NMUs should not be rushed or overly intrusive and should not include > changes that are more than "just bugfixing". I agree. In particular, they should not even fix real bugs which aren't in the BTS yet. But when using the DELAYED queue, this is very simple: report the bug, and upload the fix. If nothing more happens, then 7 days later your NMU will automatically be done. If something does happen, the upload can easily be cancelled (by the maintainer or the NMUer), if that turns out to be desirable. In other words, I'm saying that uploading to a DELAYED queue is just a polite means to provide a patch and allow the maintainer to accept it without any action. The maintainer can also reject it without any extra action, by uploading a better solution before the delay is up. And with minimal extra effort, it can even be rejected without uploading a better solution, although of course that leaves the bug open and thus isn't so nice. :-) > > MIA-process && orphaning is too slow for bugfixing. This isn't about > > anything else than bugfixing. > > Not true. These are not your own packages, these are packages under the > care of someone else. Until you know that the maintainer is MIA, you > MUST allow time for the maintainer to supply a fix. The RC BSP states 7 > days for this time, absolute minimum. Before that time, yes, feel free > to comment on the bug report, add info, suggest a patch etc. but an NMU > should not be done, even under zero day BSP release party rules, until > the maintainer has had some time to view the problem. Right. But uploading to a DELAYED queue doesn't count as "doing an NMU". Instead it counts as "notifying the maintainer", plus a public anouncement and automation of doing an NMU if nothing else changes. > I worry that too many requests for sponsors for NMUs here were about > everything *except* bug fixing and that sponsors were asking for NMUs > to make changes that were completely stylistic or solely to shut up > lintian. That is not the purpose of an NMU. I haven't followed the requests, so I wouldn't know, but I agree with you that installing lintian overrides is certainly outside the scope of an NMU. "fixing lintian warnings" in general may be within the scope, but only if the lintian warning is not a false positive, and if the bug is already in the BTS. Also, for sponsored NMUs I think there is no need for a DELAYED upload, because as a non-DD I think it is reasonable to just post your patch to the BTS and wait 7 days before requesting an NMU sponsor. > By all means lets keep NMUs for bug fixing - I like that idea, that is > what people expect from an NMU. Indeed. I think we agree on that. :-) > > >
Re: RFS: liblunar and lunar-applet
Hi, On Tue, Apr 01, 2008 at 10:31:40PM +0800, LI Daobing wrote: > lunar-applet is chinese calendar applet for gnome environment. it's > version is 2.0-1 in this upload(in sid it's 1.8) > > in lunar-applet 2.0, the library part is separated to liblunar by upstream. I'll look at lunar-applet after the library is through new, otherwise it becomes uninstallable until the library gets in the archive. > PS. I have set DM-Upload-Allowed in these two packages. I don't think this is a good idea, for two reasons: - You're not a DM, so it's removing a safety check without any current need. That means that when/if you would become a DM, this check would be skipped, possibly unnoticed. It's better if this would be done explicitly when there is an actual intention of uploading this package as a DM (so after you are a DM at least). - This flag should IMO only be added when the uploader has shown that he or she can maintain this package well. This means that the sponsor must have done a few uploads of this package for this maintainer already. (Only when using the DM status as a workaround for the slow account creation, can this be skipped, IMO, but you're not at that stage yet. ;-) ). Some comments about the package itself: - The library version is complex. This is probably upstream's choice, in which case it's fine. Libraries normally have a [base]-[version] and [base]-dev package. That means the base name of this library is liblunar-1. Gtk+ uses a similar naming, but personally I don't think it's needed to do this until version 2 is needed *and* it is such a big change that porting old applications is not reasonable, *and* there are enough old applications to keep providing the old version as a -dev package next to the new version. Most libraries don't ever get in that state, so they don't need such a complex version. - Packages containing functionality for use in a script language should be named lib-, in this case liblunar-python instead of python-lunar. - In the copyright file you use (C). This is said to be legally meaningless, you should use the complete word "Copyright" instead (which means it's on some lines twice). Also, it needs a time indication (years are good enough). You have that for your packaging, but not for the main program. Summary: for every copyright holder, you need a line of they type "Copyright [year] [name] [email]". The email can be omitted. For every piece of code you also need a license, but you have that already. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Custom Debian package installation
Hi, On Wed, Apr 09, 2008 at 09:35:53PM +1000, David Schulberg wrote: > So how can I actually check in my initscript that it is running during > the installation process so I can skip the start of my service at that > time? Using debhelper I'm not sure if that's possible at all. I would not consider it a bug if it isn't, because there's no good reason to ever need the information. You don't want "is this run during the installation?", but "is the configuration file already set up?". The usual method for doing this is described in the e-mail you quoted, and I quote it again below. The reason to do it this way, and not how you suggest, is that you cannot rely on the user to edit the configuration file before the next reboot. What if the user is in a hurry, but just installs the package and then shuts down. The next time he boots, he plans to edit the config file. But then the service is started with the default, which was wrong. This is easily avoided: if the default configuration is wrong (so it's really just a template), then the init script should not start until it's edited, no matter how oft it's tried. Another solution is to use debconf to create a sensible configuration file during the install. Then it is fine to start it after the install, because by that time a good file will be installed. Thanks, Bas > -Original Message- > On Mon, Apr 07, 2008 at 07:43:34AM +1000, David Schulberg wrote: > > I have a Debian package which starts a service set up by having > > ‘dh_installinit’ in my rules file. > > > > I want the service to start every time my computer boots up. > > > > Does it also have to fire up straight after I install the package? > > > > I have a configuration file that is part of my package which needs > > to be customised before I run the service that is installed by > > the package so I don’t want to run the service until I have done > > that. > > The way this is usually tackled is to either have the initscript > refuse to start the service if not yet configured (but still exit > with an okay return value so package installation succeeds), or ship > a file in /etc/default/ sourced by the initscript and containing a > switch variable to make the initscript's start function a no-op > (until edited to turn it on). > -- -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFS: liblunar and lunar-applet
Hello again, I should have been much faster with this, but better late than never I guess... On Thu, Apr 03, 2008 at 10:43:09PM +0800, LI Daobing wrote: > On Wed, Apr 2, 2008 at 11:40 PM, Bas Wijnen <[EMAIL PROTECTED]> wrote: > > - The library version is complex. This is probably upstream's choice, > > in which case it's fine. Libraries normally have a [base]-[version] > > and [base]-dev package. That means the base name of this library is > > liblunar-1. Gtk+ uses a similar naming, but personally I don't think > > it's needed to do this until version 2 is needed *and* it is such a > > big change that porting old applications is not reasonable, *and* > > there are enough old applications to keep providing the old version as > > a -dev package next to the new version. Most libraries don't ever get > > in that state, so they don't need such a complex version. > > lintian will complain if the name is not liblunar-1-0, this name is > come from "objdump -p /usr/lib/liblunar-1.so.0.0.0 | grep SONAME" Yes, this comment was more directed at upstream. As long as upstream uses this versioning, you should follow it. What I'm saying is that it's probably too complex for what upstream needs. > > - Packages containing functionality for use in a script language should > > be named lib-, in this case liblunar-python instead > > of python-lunar. > > no, debian python policy 2.2 said the package name should be > python-foo, and python-lunar really provide a lunar module. Ah, ok. I'm not too familiar with the Python policy, thanks. :-) > an updated version is uploaded to mentors.debian.net. remove > DM-Upload-Allowed and update copyright information, please check it. It looks good, but some problems have been caused by my delay: - There are several warnings now that it's being compiled with gcc-4.3. This is upstream stuff, you probably don't need to fix it, but upstream may want to know. - python-lunar.install looks in /usr/lib/python2.4/, but the files are now installed in /usr/lib/python2.5/. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
[Uploaded] liblunar and lunar-applet
On Thu, Apr 24, 2008 at 10:43:05PM +0800, LI Daobing (李道兵) wrote: > a new version 1.0.0-1 uploaded to mentors.debian.net Looks good, I uploaded it. Please let me know when it passes NEW, so the new lunar-applet can be uploaded as well. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: really old bugs
Hi, On Fri, May 16, 2008 at 03:22:52PM +0200, Christoph Egger wrote: > I am working through the bugs of glademm which I recently adopted. There > are some 6-7 years old Bugs that are not reproducible any more while > they clearly have existed once. > > I guess simply closing them with an notice about not being able to > reproduce them on any recent Version is the way to go, right? In principle, yes. However, it's good to check with the submitter(s) if they can still reproduce it first. If it's not too much trouble, knowing when it was fixed and supplying a version would of course be good, but I wouldn't spend more than 5 minutes searching for it. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: dh_clean and explicit package clean lists
Hello, On Sun, May 18, 2008 at 08:59:31AM +0200, Ansgar Burchardt wrote: > > You probably want a custom regex in the -i option to dpkg-source. > > Using debuild and DEBUILD_DPKG_BUILDPACKAGE_OPTS in ~/.devscripts is a > > good way to prevent the need to add it to the dpkg-buildpackage > > command-line every time you run it. > > Is it possible to set this option in the package itself? This would > make life easier in case of team maintenance, NMUs and adoption. > If these options can only be set in $HOME, everybody involved will have > to add them themselves. This is IMO a likely cause of error, which > could be avoided. I see your point, but disagree. :-) I would prefer to use a different approach, which will break instead of ignore. In particular, if I still have a vim swap file, I want the build to fail. If it doesn't it's too easy to forget to save before building. All the VCS stuff should definitely not be ignored; packages are built from released tarballs, not from vcs checkouts (well, most of the time anyway). But leaving them in will make lintian complain, which is good. :-) Anyway, my point is that what exactly should be ignored is a personal thing, which has little to do with the package that's being worked on. That's a good reason for putting thing in $HOME. And also for not allowing such options to be overridden from a package. Defaults from a package could be acceptable, but I don't see much benefit to that, really. Thanks, Bas -- I encourage people to send me encrypted e-mail (see http://www.gnupg.org). Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. for more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Fwd: Issue 126 in scim-python: license issue about pinyin_table.txt
On Tue, Jun 24, 2008 at 09:32:04PM +0800, LI Daobing (李道兵) wrote: > Dear mentors, > > I got a question from the upstream, the source tarball contains GPL > and LGPL code, and this source tarball can generate several packages. > can I release one package in GPL and another in LGPL? Yes, because the tarball is just an aggregation of the parts, so there is no problem if some of them are GPL and others are not. Even if the rest would need to be GPL for that, it wouldn't be a problem. The LGPL states that it is allowed to relicense the code under the GPL instead. So for practical purposes, LGPL licensed works are always dual licensed LGPL/GPL[1]. If there are binary packages which build solely from LGPL sources (they do not use any GPL-only sources), those packages can be licensed as LGPL. > Is it possible to create several debian binary packages from signal > tarball, and mark different debian package with different license? In > fedora, I created several binary rpms from scim-python tarball with > different license. pinyin-table.txt is needed by xingma engine, you > could put it in xingma package and mark it GPL. This is also possible in Debian. > Other parts should be LGPL. It is always allowed to just license LGPL'd packages as GPL, so "should" is a bit strong here. However, it is the best thing to do, I think; it gives our users all the options (GPL or LGPL). Thanks, Bas [1] Watch out for versions though: LGPL 3 may be turned into GPL 3, which is not compatible with GPL 2. So if you have one part which is GPL 2 only, and another which is LGPL 3 or later, they cannot be combined. I do not know if this is relevant here. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Fwd: Issue 126 in scim-python: license issue about pinyin_table.txt
On Tue, Jun 24, 2008 at 06:41:37PM +0200, Bas Wijnen wrote: > If there are binary packages which build solely from LGPL sources (they > do not use any GPL-only sources), those packages can be licensed as > LGPL. Sorry for replying to my own mail, but I was writing confusing things. :-) The packages aren't licensed as a whole, they are, like tarballs, aggregations of files which may have different licenses. I was really talking about files when I wrote packages. There is no problem to have a binary package which includes both GPL and LGPL files. Of course it should all be documented in debian/copyright. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFS: scim-python: python bindings and input methods for scim
On Mon, Jul 21, 2008 at 10:06:27AM +0900, Osamu Aoki wrote: > In License, you have: > LGPL-2+ can also be treated as version 2.1 of GNU Lesser General Public > License. On Debian systems, the complete text may be found in > /usr/share/common-licenses/LGPL-2.1. > > LGPL-2+ can also be treated as version 3 of GNU Lesser General Public > License. On Debian systems, the complete text may be found in > /usr/share/common-licenses/LGPL-3. > --- > > These are missleading. > I do not think you need these additional (and very misleading when mentioning > GPL3) text here. They are properly addressed in respective license or in > source code as "or (at your option) any later version." You seem to have misread the license file (I didn't check, but only read what you quoted). It talks about LGPL-3, not about GPL-3. It's not misleading, just complete. The files are distributed with multiple licenses, namely LGPL-2, LGPL-2.1, and LGPL-3. Later versions are automatically added to that list as they are released. As always when receiving multiple licensed files, debian/copyright should list them all. Listing licenses which aren't released yet isn't possible of course, but listing all currently available options is a good idea IMO. That's what the part you quoted does. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: RFS: scim-python: python bindings and input methods for scim
On Wed, Jul 23, 2008 at 10:05:25PM +0900, Osamu Aoki wrote: > Hi Bas, Hi, > I may have made confusing statement for casual observer... > > On Mon, Jul 21, 2008 at 01:09:02PM +0200, Bas Wijnen wrote: > > On Mon, Jul 21, 2008 at 10:06:27AM +0900, Osamu Aoki wrote: > > > In License, you have: > > This should have been "In copyright" file describing license term in the > package, you (Mr. Li) have:" > > > > LGPL-2+ can also be treated as version 2.1 of GNU Lesser General Public > > > License. On Debian systems, the complete text may be found in > > > /usr/share/common-licenses/LGPL-2.1. > > > > > > LGPL-2+ can also be treated as version 3 of GNU Lesser General Public > > > License. On Debian systems, the complete text may be found in > > > /usr/share/common-licenses/LGPL-3. > > > --- > > > > > > These are missleading. > > > > > I do not think you need these additional (and very misleading when > > > mentioning > > > GPL3) text here. They are properly addressed in respective license or in > > > source code as "or (at your option) any later version." > > > > You seem to have misread the license file (I didn't check, but only read > > what you quoted). It talks about LGPL-3, not about GPL-3. It's not > > misleading, just complete. > > I clearly made you confused. If you read packager's copyright file, you > should have understood my comment. I did read it now, but I still don't understand it. The copyright file doesn't talk about the GPL anywhere (except in the python part about compatibility, but that's not about versions), it only talks about LGPL versions. You quoted this part of the copyright file (it's still quoted above). Do I understand correctly that your problem is "Mr. Li talks about GPL, but the files are licensed LGPL"? I would agree that he should not do this; I'm just saying that you seem to have misread the file, because de doesn't talk about the GPL. ;-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
--as-needed linker option (was Re: binary-without-manpage)
On Thu, Aug 21, 2008 at 09:44:52PM +0200, Jeffrey Ratcliffe wrote: > >> I've tried using --as-needed, but ocropus then FTBFS. > > http://paste.debian.net/15317/ --as-needed will let the linker throw away all symbols that aren't used. It always does this when linking static libraries. That's why with those, it's important that they're in the right order. The same is true when using --as-needed. The order should be such, that all used symbols from a library must be used by files which are mentioned before (so they are undefined references when the library gets linked). This means your source file must be before all libraries (not after them, as it is now), and libararies which depend on each other must be in the correct order as well[1]. Hope this helps, Bas [1] Not sure about that, perhaps that's sorted out when they were compiled. Anyway, it doesn't hurt to do it. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Re: ldconfig-symlink-missing-for-shlib error
On Thu, Jul 14, 2005 at 05:17:12AM -0400, kamaraju kusumanchi wrote: > One possible alteration would be (with minimal changes to the original > text) > > The run-time library package should include the symbolic link to the > shared libraries that| |would have normally been created by ldconfig. I don't think this is a good formulation. It depends on your definition of what's normal. I think on a Debian system, anything dictated by policy is normal. So according to that rule, ldconfig wouldn't normally create any symlinks, because they are already included in the package. If the wording needs to be changed, I'd suggest something like "that would otherwise be created by ldconfig". > This link has to be created by the maintainer. For example, the > |libgdbm3| package should include a symbolic link from > |/usr/lib/libgdbm.so.3| to |libgdbm.so.3.0.0|. This is needed so that > the dynamic linker (for example |ld.so| or |ld-linux.so.*|) can find the > library between the time that |dpkg| installs it and the time that > |ldconfig| is run in the |postinst| script. As far as I understand it, this is incorrect. The links are not provided for use during this time, they are provided because they must be erased again during package removal. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: where to put object file
On Fri, Jul 22, 2005 at 03:44:05PM +1000, skaller wrote: > Where should a required object file be put? > > File in question is a mainline stub, associated with a > static archive, program is built by linking it with > the archive and user object file. If I were upstream, I would probably put it inside the static archive using ar. If that is not desirable, e.g. because there are two upstreams, I would make it a separate static archive, using ar. However, if upstream doesn't do that and you want other sources which use this method of linking to keep building without modification (unlikely anyway, as the library path is not searched for object files), I think it should go in /usr/lib/package/, like other (platform dependant) package helper files. I suppose this is a -dev package btw? If you're packaging the compiled program, the object file and the static library are both no longer needed, as they are statically included in the executable (as far as needed by it), so you don't need to put them in the package at all. > The archive is in /usr/lib, should the .o go there too? I think only libraries should go in /usr/lib. A directory like that gets pretty unreadable, because it's so full of stuff, but the fact that the compiler can find things there is worth it. However, as it won't find object files there (unless specifically pointed to it), putting them there anyway would just be obscure IMO. However, IANADD, so I could be wrong. :-) Bye, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: howto get rid of native-package-with-dash-version?
On Thu, Aug 04, 2005 at 11:32:01PM +0200, Bastian Venthur wrote: > > Ok but one question remains: When I unpacked the original sources, I had to > rename the resulting dir to calm dh_make down -- when I now unpack the .zip > in order to make an .orig.tar.gz out of it, do I have to rename the dir too > or has the .orig.tar.bz an exact copy of the .zip? Usually, it is a good idea to keep the original tarball as it is, so the directory it unpacks to should not be changed. dpkg-buildpackage will handle it if it doesn't unpack to the "correct" name. The reason for keeping the original is as far as I understood it that the md5 checksum is the same as the distributed version. However, since your distribution is a zip file, and not a tar.gz, that doesn't work anyway. So you can make it the renamed directory I guess. But there's not really any reason to do so, as dpkg-buildpackage doesn't need it. So I would just unzip, then tar -czf, and name it .orig.tar.gz. Hope this helps, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFS: tvbrowser -- TV-Browser is a java-based TV guide
Hi, While completely off-topic (at least for -mentors), I still feel the need to respond to this. The DFSG defines what free software is. An important freedom (IMO) is #3, the freedom to modify the program and distribute modifications. However, this freedom is pretty useless (to people who want to use exclusively free software) if the modified source needs a non-free compiler. That is the reason (I suppose) that a non-free Build-depends: will land a package in contrib. It may be free, but not all of the freedoms can be used. I very much value (in GNU's words) "The freedom to study how the program works, and adapt it to your needs". Therefore none of my sources.lists have contrib in them. I don't want to use a program, just to find that I cannot reasonably modify it when I feel the need to do so. Bye, Bas Wijnen On Sun, Aug 07, 2005 at 01:41:48PM -0400, Joe Smith wrote: > Just to chime in: > IMNSHO: > It really makes little difference if software is packaged in main or > contrib. The way I see it both have software available under a > DFSG-complient licence. > Because sometimes there is software in contrib that actually is usable > without non-free software, although it use may be limited, I *always* > reccomend that contrib be included in any and all source.lists. There > really is no reason not to. If the package depends on software in non-free > it will just fail to install. Otherwise it will install just fine because > it does not depend on a missing package. > > There is no good reason not to think of contrib as an extention of main, > where *some* software may require non-free packages. > > Actually I see no good reason at all for a source.list to fail to have > contrib. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
autotools during build
Hello mentors, I have some packages which use autotools. I thought it would be good to compile as much as possible, so it is clear all the sources are correct. That means including autoconf, of course. However, linda doesn't agree with that: W: gfpoken; Package Build-Depends on automake* or autoconf. This package Build-Depends on automake* or autoconf. This is almost never a good idea, as the package should run autoconf or automake on the source tree before the source package is built. lintian doesn't consider this to be a problem. My question is: is linda correct and should I not run autoconf from rules.make? Extrapolating that would mean that compilation is not needed at all, if a precompiled version of the program is packaged in the source tarball. That doesn't seem right to me. So if linda is right, then where is the limit? Generated files which are included for portability reasons (such as configure) are ok, but others are not? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: autotools during build
On Fri, Aug 12, 2005 at 02:12:57AM -0700, Steve Langasek wrote: > On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote: > > I have some packages which use autotools. I thought it would be good to > > compile as much as possible, so it is clear all the sources are correct. > > That > > means including autoconf, of course. > > > However, linda doesn't agree with that: > > W: gfpoken; Package Build-Depends on automake* or autoconf. > > This package Build-Depends on automake* or autoconf. This is almost > > never a good idea, as the package should run autoconf or automake on > > the source tree before the source package is built. > > > lintian doesn't consider this to be a problem. > > > My question is: is linda correct and should I not run autoconf from > > rules.make? Extrapolating that would mean that compilation is not needed at > > all, if a precompiled version of the program is packaged in the source > > tarball. That doesn't seem right to me. So if linda is right, then where > > is > > the limit? Generated files which are included for portability reasons > > (such as > > configure) are ok, but others are not? > > The limit is between autogenerated sources that upstream ships in the > tarball, and autogenerated sources that are expected to be built at build > time. That sounds like a good way to sneak non-free stuff into main. In fact, gfpoken is a good example of that. The new upload doesn't use the original artwork, because it had to be compiled with povray. However, the compiled files were in the source tarball (in fact, the art source was in a different tarball). Opinions vary wether it was needed to have art with a free compiler, but that's because it's about art. If it would have been a piece of C code, generated with a non-free compiler, then the package obviously shouldn't be in main. However, if upstream (which could be the packager) has pregenerated the files, then according to this rule there is no problem. That doesn't seem right. > If you rerun autoconf/automake/libtool at package build-time, when you don't > need to, what you get are large diffs against upstream every time a new > version of the autotools becomes available. Aside from wasting (a little) > space in the archive, that makes it harder for NMUers or passing developers > to see what's going on in your package. I noticed that, and "manually" removed all files generated by auto* in debian/rules:clean. That way they get ignored for the diff. > The autotools-dev README.Debian is a good guide to these issues. I'll read that. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: predepends/depends order
On Tue, Aug 16, 2005 at 08:13:03PM +0200, Sandro Dentella wrote: > > I don't have an idea how this could be done. The only alternative I see > > is to tell the people "install A-pre first, then install A which will > > pull in B,C,D"; or to create a script in A-pre that will ask the debconf > > questions and then ask "You must install A,B,C and D for this to have an > > effect. Proceed" and run apt-get install A B C D. > > Thanks, I do realize this is the best solution. It sounds like a very dirty hack to me, and that can never be the best solution. If it would really be needed, the tools should be changed, and it might be a temporary solution (if it would work, but as was pointed out it probably wouldn't). I may be missing the problem, but as far as I understand it you want B, C, and D to have Depends: A. If they don't have it and cannot be used without A, file a bug report. If they can also be used without A then you must not depend on being configured before them, because users may first install those packages, and add A later. If they should be reconfigured at that time to support the new possibilities which weren't there without A, they should provide a reconfigure option (dpkg-reconfigure comes to mind ;-) ). About your original message: If you want to provide people with a system that doesn't ask questions for which you have good defaults (for their situation), you could create a script which preseeds debconf so it doesn't ask the questions. Your package should definitely not block questions in other packages, as there may be people who don't like your defaults and want to answer those questions. And in general, those are not your package's questions, so you're not supposed to mess with them. I hope this helps, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: predepends/depends order
On Tue, Aug 16, 2005 at 10:46:34PM +0200, Sandro Dentella wrote: > > I may be missing the problem, but as far as I understand it you want B, C, > > and D to have Depends: A. If they don't have it and cannot be used > > without A, file a bug report. If they can also be used without A then you > > no! salpd as an example con live w/o my package, that depends on that. In that case it is not your business to demand that your package is configured before them. Theirs can have been installed years ago. It seems you just want to allow people to not need to answer questions for packages which are not yours. I think the proper thing to do is to file a wishlist bug for them to not ask the same question more than once (so they can store the answers and use them all or something). For the specific problem of preventing users from seeing too many questions, that's not something that should be solved by packages. It can be solved by an install script you write, but that shouldn't be in a package IMO. If it must be in a package, it should be their package. You can of course patch them (and send the maintainers the patches) by yourself and use that. > > About your original message: If you want to provide people with a system > > that > > doesn't ask questions for which you have good defaults (for their > > situation), > > you could create a script which preseeds debconf so it doesn't ask the > > questions. Your package should definitely not block questions in other > >If I understand what preseeds mean, is just what I did. I just fill in >some debconf variable so that I get a chance that it will not ask for >that (unless they dpkg-reconfigure). > >What I do is to check if the value was already set by the user, if not I >set a default. If the value was already answered for a package I fill in >with the same value into another one (eg: libnss-ldap, libpam-ldap, slapd) That's quite ok, but it should be done by the package asking the questions, or by something which is managing the install, such as a script which you can write. Don't touch questions of packages from other packages. > > packages, as there may be people who don't like your defaults and want to > > answer those questions. > > true (they will use dpkg-reconfigure) but is very unlikely that you want > to say 'dc=isi,dc=org' for a package and 'dc=debian,dc=it' for another. In > some circumstances to place the same question more than one time is > puzzling. Nevertheless is not a bug, becouse there could be cases in which > you need different answers. Sounds like it is a good idea for them to use each other's answers as defaults. Still, that's something that should be taken care of in their package, not in some other package. Bye, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: debconf notes and automatically generated password
On Thu, Aug 18, 2005 at 09:05:32PM +0200, Fabio Tranchitella wrote: > > I am a big fan of not using debconf/postinst for any of this. So am I. Definitely not postinst: that should be without interruption. The install process of Debian asks questions directly after downloading them. After the questions have been answered, the install should work without interruption. Except for conffile problems, which still annoy me. ;-) > I'm still confused about debconf's 'note', mainly because > debconf-devel(7) clearly says that debconf will do everything to display > that message to the user, but I'm not able to obtain this behaviour. Not "everything". It said it would go through great pains. However, if a user set the frontend to "noninteractive", then nothing is going to wait for a key press (and if something is, then that's a very serious bug, as it makes unattended installs impossible). In such a case, the user probably knows what they're doing, and you shouldn't force your message on them. I have no idea when the mentioned e-mailing would take place. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: howto deal with upstream authors not responding?
On Fri, Sep 02, 2005 at 01:41:58PM +0200, Bastian Venthur wrote: > The problem is: > > On kde-look[1], everaldo put his icons under LGPL, but he did not put a copy > of this license in his tarball. While a copy of the license gives more legal certainty, I don't think it is required. It is a good idea to put one in Debian nontheless. There a pointer to /usr/share/common-licenses will do for LGPL, but you may want to put a copy of the license in the diff.gz (but don't include it in the binary packages). Not sure if doing that makes sense though. > But on his homepage[2] he has a more restrict copyright which seems just > because he also sells other icons. Unfortunatly all crystal icon sets he > has created so far are on this page too, which means his strict copyright > note must apply to the crystal icons too, because not stated otherwise. It seems to me they are available under the LGPL if you get them from kde-look, and under the more restrictive license if you get them from his site. In that case it's your choice which license you want to agree to, if any. You need a license if you want to modify and redistribute it, and in this case the LGPL is probably the one you want to use (and thus agree to). > NOTE: As far as I understand, this means that our current default icon set > on KDE3 is unfree as well :( If the files were licensed under the LGPL, then they still are. The LGPL cannot be revoked (except if it is violated by the licensee, which I assume is not the case). So there isn't really a problem. Remember that a license is a right to do things you would otherwise not be allowed to do. You get a license with software. Software can be licensed to different people using different licenses simultaneously. So software cannot "be" GPL, the software is licensed to someone under the GPL. The author can license the same software to someone else under a more restrictive license, but that doesn't change anything to the licenses which were already given out. > Any ideas what I can do now? Get the icons from somewhere under the LGPL. Contacting the author about it would be nice, but the good thing about the (L)GPL is that it's not actually needed in order to redistribute the material. IANAL, TINLA. Greetings, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Change version number only for a different build.
Hi, On Mon, Sep 05, 2005 at 03:06:11PM +0200, Antonio Ospite wrote: > Since my packages are "unofficial" I want them to be built for sarge and > sid (i use pbuilder for that), but in the same upstream version; is that > allowed by the policy. What i have to do? Policy is only about the official Debian archive, not about things you build for yourself. If you want to get your packages into the official archive, they will only enter unstable. Packages get in stable by going from unstable to testing after some time, and then testing being released makes it stable (which then includes the package). Very few things get changed in stable. Security bugs do, and I think translation updates as well, but I'm not sure about that. > I tought i can use a different package version for binary packages > targeted to different distribution, does something like package_x.x-1 > for sid and package_x.x-1sarge for sarge sound reasonable to you? It doesn't sound good to me. If you have the same source package, and the only difference is that it must be compiled with the libs from stable instead of the ones from unstable, I don't think it should be a different version. However, maybe someone else has something sensible to say about it. Of course the pool doesn't allow two binary packages of the same name, because they must be in the same directory. > And how do i have to report the different builds in the changelog? > Is it an acceptable practise to add a changelog entry only for a build > on a different distribution? In the official archive, this doesn't happen. If there is a new version for unstable, then it will not have the same name as the one in stable (because it's a new version). If it's still the same version, then it really is the same file as well, so in that case the name _should_ be the same. Bye, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Packaging Barcode Writer in Pure PostScript
On Tue, Sep 06, 2005 at 09:53:51AM +0100, Terry Burton wrote:
> Hi,
Hello,
> Would people please examine the package and tell me what problems
> exist. You can view the files at
> http://www.terryburton.co.uk/barcodewriter/files/debiansrc
After a very brief look, I can only say I saw a lot of commented out lines in
rules.make. I guess they come from dh_make. There's no need to leave them
in, just remove them.
> Some additional questions:
>
> The project has no dependancies. Is it safe to remove this line from
> the control file?
> Depends: ${shlibs:Depends}, ${misc:Depends}
A follow-up to that question: ${misc:Depends} gives "undefined variable" (or
something) warnings on some of my packages. Should I remove them from those,
or is it good to leave them in in case something will be substituted in there
later? Where would the content come from anyway?
> The upstream project unpacks all files into a single directory and
> does not provide a facility for installing the files into a distro's
> file system hierarchy. For the Debian package I have created a
> Makefile that accomplishes his via the install target. There is no
> compilation necessary so I have created empty all and clean targets.
> Could somebody verify that this is the correct way to handle such a
> package.
Personally, I would just use debian/rules for that. There is a step to build
(which will be empty in this case) and one to install, which will be like
cp --parents files debian/tmp/somedir/.
> Debian Policy mandates that programs have a manpage. Since this is a
> PostScript resource (similar to a shared library) does this rule still
> apply. If so then I'm not sure what the content of such a manpage
> ought to be.
Policy mandates manpages for executables. This is not one of them, I guess.
However, it is good to create one anyway if the user can directly use the
file. That is, if it is only used by other programs (as is the case for a
shared library), there is no need for a manpage. If you expect the user to
use the files in the package directly, a man page is in order IMO. In it
should be a manual describing what the user could do with it. In other words,
after reading the man page, the user should be able to use the package.
> The project is platform independant as specified in the control file.
No, you specified "Architecture: any" in the control file, which means it is
portable to all platforms, in other words that it can be compiled on each of
them. "Architecture: all" means it's platform independant.
> After I have got the source package into good shape, do you have any
> advise on finding a package sponser? Any volunteers.
I'm not a DD yet, so I can't help you there.
Bye,
Bas Wijnen
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
Re: RFS: update of squashfs-tools package
On Wed, Sep 07, 2005 at 01:52:38PM +0200, Fr?d?ric BOITEUX wrote: > I've now a new version, 2.2-0.1, ready to be uploaded, but the official > maintainer which > has orphaned the package don't have any time to do it. According to the bts, there's only a RFH, not an O. Did he forget to do this? > - How can I do to avoid removing package from archive ? Normally, retitling the RFA or O bug into ITA should help. However, there is no such bug, as there is only a RFH. If he really meant to orphan the package, you can retitle it to ITA (but discuss this with him before doing it). Also write a comment in the bug report about the situation, explicitly saying it shouldn't be removed, because you want to adopt it. Bye, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Willing to adopt a few orphaned packages
On Fri, Sep 09, 2005 at 02:26:02PM +1000, Ben Finney wrote: > On 08-Sep-2005, Stan Vasilyev wrote: > > I am wondering if anyone is willing to sponsor my work on some of > > the orphaned packages I listed below. > > Prospective sponsors will need to know that you've read the FAQ and > addressed its issues. > > Then they will need to see your new source packages that you want > sponsored. Post here with the URL to the source packages you have > created. I think the question is: "If I create a package of this, will someone sponsor it?". Which sounds reasonable, as sometimes packages pass by on this list which don't find a sponsor. I expect Stan to know that the sponsor can ask for some changes once he built a package, but I don't think that's what he's asking about. Bye, Bas signature.asc Description: Digital signature
Re: curious deb installation
Hi, When I unpack debian packages, they have the following structure: debian-file \- control.tar.gz \- data.tar.gz \- debian-version In control.tar.gz are the postinst, etc. files, in data.tar.gz are all the "normal" files. debian-version is just a number. To see this, unpack a package of your choice with ar x package.deb Note that that unpacks in the current directory, so go somewhere where that is no problem. Is there any reason you don't want to use dpkg-buildpackage, by the way? I can't think of a good reason not to... On Fri, Sep 09, 2005 at 09:38:18AM +0200, Roland Pontes wrote: > Paketlisten werden gelesen... Fertig > Abh?ngigkeitsbaum wird aufgebaut... Fertig > Die folgenden NEUEN Pakete werden installiert: > ordnername > 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. > Es m?ssen noch 0B von 662B Archiven geholt werden. > Nach dem Auspacken werden 0B Plattenplatz zus?tzlich benutzt. It would probably be a good idea to unset your locale setting when pasting such results to an international mailing list. Many people here will not speak german and therefore understand only part of it. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFS aldo - A morse code trainer
On Sun, Sep 11, 2005 at 03:05:47PM +0200, Giuseppe Martino wrote:
> New package on: http://dakordhost.homelinux.org/~denever/aldo_debian
I have two things to say about this:
- debian/ should not be in the orig.tar.gz, but only in the diff.gz. See [1].
- Your diff.gz is huge, but it seems to contain only generated changes from
auto{make,conf}, not source file changes. To prevent this, remove the
generated files in the "clean" target. See [2].
[1] http://lists.debian.org/debian-mentors/2005/04/msg00219.html
[2] http://lists.debian.org/debian-mentors/2005/08/msg00231.html
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
Re: RFS aldo - A morse code trainer
On Mon, Sep 12, 2005 at 01:44:14PM +0200, Christoph Berg wrote: > Re: Giuseppe Martino in <[EMAIL PROTECTED]> > > >But what's more important. The build failed here: > > > > > >configure: error: cannot find install-sh or install.sh in config > > >./config > > >make: *** [config.status] Error 1 > > > > The problem is a missed Build-Depends aboud automake1.9. > > The proper way to fix that is to ship a bootstrapped .tar.bz2. Your > tarball does not build: > > $ ./configure > configure: error: cannot find install-sh or install.sh in config ./config Normally, these files should just be in the distribution tarball AFAIK. Such bootstrap scripts are used when getting the source from cvs (where you do not want generated files). > $ sh bootstrap > configure.ac: installing `config/install-sh' > configure.ac: installing `config/mkinstalldirs' > configure.ac: installing `config/missing' > Makefile.am: installing `./COPYING' > Makefile.am: installing `./INSTALL' > libaudiostream/Makefile.am: installing `config/depcomp' > > $ ./configure > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > [...] > > Please provide an updated upstream tarball. > > This will allow you to drop the build-dependency on the autotools, > which is considered evil by most people anyway. Huh? Looking at the output of bootstrap, it runs the autotools. Or do you mean it should be run before packaging the tarball? In any case, I strongly disagree that build-depending on autotools is wrong. The autotools were created to make platform-independant building possible on platforms with no special programs (such as the autotools) installed. However, if they _are_ available, then it's a good idea to regenerate all the files, because old versions of the autotools can have bugs (and it makes sure that the source files such as Makefile.am are actually the versions which produced the Makefile). It's a good idea to use the output from the newest autotools if possible, and on a Debian system that is easily possible, namely by build-depending on them. > Oh, and please ship real files in the tarball: > > lrwxrwxrwx 1 cb cb 31 2005-09-12 13:29 COPYING -> > /usr/share/automake-1.9/COPYING > lrwxrwxrwx 1 cb cb 31 2005-09-12 13:29 INSTALL -> > /usr/share/automake-1.9/INSTALL I agree that real files should be shipped in the tarball. However, to make sure the diff doesn't get too large, remove such files in the "clean" target (in debian/rules). > (Yes, having 1003951 copies of the GPL on your filesystem is a waste > of space, but that's the way it works.) No, it isn't. :-) The GPL should be in the source tarball (if the package is licensed under it), but you should not put it in the binary package. Instead, write in /usr/share/doc//copyright that it can be found in /usr/share/common-licenses/gpl. Since most people don't have many source packages installed, it's not a waste of user filesystem space, but only of archive filesystem space. Which is a much smaller problem. :-) > Re: Giuseppe Martino in <[EMAIL PROTECTED]> > > > I have two things to say about this: > > > - debian/ should not be in the orig.tar.gz, but only in the diff.gz. See > > > [1]. > > The .orig.tar.gz should be identical to the upstream tarball > (re-bz2-ipped in your case). It should, but as far as I understood it he was himself upstream, so he can change the upstream tarball. :-) If I understood it wrongly, he should urge his upstream to remove it, and just use it like this in the mean time. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFS aldo - A morse code trainer
On Mon, Sep 12, 2005 at 04:14:57PM +0200, Christoph Berg wrote: > Re: Bas Wijnen in <[EMAIL PROTECTED]> > > > Please provide an updated upstream tarball. > > > > > > This will allow you to drop the build-dependency on the autotools, > > > which is considered evil by most people anyway. > > > > Huh? Looking at the output of bootstrap, it runs the autotools. Or do you > > mean it should be run before packaging the tarball? > > The upstream tarball on savannah is broken, it should be updated. Ah, ok. > > In any case, I strongly disagree that build-depending on autotools is wrong. > > The autotools were created to make platform-independant building possible on > > platforms with no special programs (such as the autotools) installed. > > However, if they _are_ available, then it's a good idea to regenerate all > > the > > files, because old versions of the autotools can have bugs (and it makes > > sure > > that the source files such as Makefile.am are actually the versions which > > produced the Makefile). It's a good idea to use the output from the newest > > autotools if possible, and on a Debian system that is easily possible, > > namely > > by build-depending on them. > > It's a matter of taste. I prefer a bootstrapped tarball, because > re-bootstraping on the autobuilders can cause all kinds of funny build > failures that weren't there otherwise. If you get build-failures from re-running the autotools, the IMO the source is broken. Not building that part of the package, but shipping pre-built (however that was done) files, doesn't sound good to me. Policy doesn't dictate that everything (or even anything) must be compiled, but I think the intention is that things should be compiled from source whenever possible. Makefile and configure are not source, Makefile.am and configure.ac are. > (And in most cases it's a waste of build time.) With that argument we could as well put binaries in the source packages and just move them to the right place with debian/rules. I'm sure you agree that that would not be a good idea. :-) IMO the fact that upstream put those precompiled versions in the tarball doesn't change that. After all, they're only in the tarball to support "obscure" systems which don't have the means to compile those sources. Debian is not an obscure system in that sense, so there's no need to use the precompiled versions. > > I agree that real files should be shipped in the tarball. However, to make > > sure the diff doesn't get too large, remove such files in the "clean" target > > (in debian/rules). > > If there are real files in the tarball, they shouldn't be in the > diff.gz anyway. If you re-run the autotools, they get overwritten. It isn't unusual that the new version of the autotools produces different output, which results in huge differences between them. Removing the generated files makes sure they are ignored for the diff. And by the way, the fact that the differences are so large is a strong argument for rerunning the autotools, because the new output is presumably better than the old. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Removing non-free documentation from a package
On Thu, Sep 15, 2005 at 05:12:06PM +0200, Rafael Laboissiere wrote: > * Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2005-09-15 10:07]: > > > On Thu, 15 Sep 2005, Rafael Laboissiere wrote: > > > I buy Sven's arguments in favor of adding -nonfree. I would also strip > > > the > > > "lib" at the beginning of the name. The upstream Perl module is called > > > Parse-RecDescent, so I would call the package > > > parse-recdescent-doc-nonfree. > > > What do you think? > > > > Stick to the perl package naming convention. Please. > > Well, the new package will not contain a Perl module, so I do not see the > need to sticking to the conventions (cf section 4.2 of the Debian Perl > Policy). The package containing the Parse::RecDescent module with the > tutorial stripped is still called libparse-recdescent-perl. Doc packages are usually called package-doc. I see no reason to change that here, except that adding non-free seems to make sense. Removing "lib" would just confuse the name, because it would be less clear which package the doc is for. > At any rate, I guess you are suggesting the name > libparse-recdescent-perl-doc-nonfree, aren't you? That's what I'd suggest. > Good chances to win the longest-package-name contest in Debian :-) Non-free isn't technically "in Debian" :-P Anyway, I don't see any problem with having a long name. Debian is high quality software, which will not stop working because of it. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Looking for a mentor for 'arno-iptables-firewall' package
On Sat, Sep 17, 2005 at 02:55:55PM +0200, Michael Hanke wrote: > That's it! Thanks. One question left: Is there any situation you can > think of where an external interface would have no hardware address? > If there is no such situation one could grep for 'HWaddr' instead. Lots of them. Ppp connections and loopback for example. Bye, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Debian package creation scripts
Hello,
In order to easily build Debian packages, I wrote a script called mkdeb. I
use it for projects where I am upstream, to make a package without doing a
release first (this is just for testing, when I build an official package I
use a real release as orig.tar.gz). It's a fairly simple script, which
creates an orig.tar.gz from the current directory, and calls debuild using it.
I also made a new version of it which renames the package to -dbg and builds
the package with debugging symbols. This works for the few packages I tested,
but probably not for all, as changing the package name has quite some
implications.
Anyway, the question I have about this: Is something like this useful for
others? Is it worth putting it in a Debian package, for example? I find it
very useful, and feel that it is missing from the current helper scripts. Or
did I just duplicate some effort? :-)
Since the scripts aren't very large, I included the non-debug version as an
attachment.
Thanks,
Bas Wijnen
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
#!/bin/bash
if [ ! -d debian ] ; then
echo >&2 "No debian directory found. Aborting."
exit 1
fi
# first check for cvs conflict files, otherwise you'll be notified by lintian,
# which is very late.
cvs_conflict_files="`find . -name '.#*'`"
if [ "$cvs_conflict_files" ] ; then
echo >&2 "You still have cvs conflict files in your directory:"
for i in $cvs_conflict_files ; do echo $i ; done
exit 1
fi
dir=/tmp
name="$(basename "$(pwd)")"
debversion="$(head -n 1 debian/changelog | cut -f2 -d\( | cut -f1 -d\) )"
version="${debversion%-*}"
echo name=$name, version=$version
temp="`mktemp -d "$dir/mkdeb.XX"`"
mkdir "$temp/$name-$version.orig"
tar -czf - . | tar -C "$temp/$name-$version.orig" -xzf -
find "$temp" -name CVS | xargs rm -rf
pushd . >/dev/null
cd "$temp/$name-$version.orig"
fakeroot debian/rules clean
popd
rm -rf "$temp/$name-$version.orig/debian"
tar -C "$temp" -czf "$dir/${name}_$version.orig.tar.gz" "$name-$version.orig"
rm -rf "$temp"
rm -rf "$dir/$name-$version"
mkdir "$dir/$name-$version"
tar -czf - . | tar -C "$dir/$name-$version" -xzf -
find "$dir/$name-$version" -name CVS | xargs rm -rf
cd "$dir/$name-$version"
debuild "$@"
signature.asc
Description: Digital signature
Re: Debian package creation scripts
On Sat, Sep 17, 2005 at 04:38:10PM +0200, Joost van Baal wrote: > Hoi Bas, Hi, > On Sat, Sep 17, 2005 at 04:23:22PM +0200, Bas Wijnen wrote: > > > > In order to easily build Debian packages, I wrote a script called mkdeb. > > > > > Anyway, the question I have about this: Is something like this useful for > > others? Is it worth putting it in a Debian package, for example? I find it > > very useful, and feel that it is missing from the current helper scripts. > > A wishlist bug against devscripts might be more appropriate. The reason I posted here was to see if this would be useful at all, and if so what to do. You answered the second question, but unfortunately I still don't know if it is useful to include it in there. I'm not in favour of adding stuff to it if there are better alternatives. Well, maybe this should be a question to the devscripts maintainers, in which case a wishlist bug seems appropriate as well. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: ported package versioning
On Wed, Sep 21, 2005 at 03:58:15AM -0500, Rudy Godoy wrote: > El d?a 20/09/2005 a 02:41 W. Borgert escribio ... > > > On Tue, Sep 20, 2005 at 01:24:20AM -0500, Rudy Godoy wrote: > > > Hi, I've almost finished the port to gtk2 of one of my packages[0], my > > > question is regarding to the package versioning since upstream seems > > > pretty MIA and I'm unlikely to push it upstream but I'd like to have > > > this on Debian. So how should I go add a -gtk2, as I'm doing now, to > > > the version number or put this as another package and replace the > > > former? > > > > Is there a need to keep the GTK+ 1 version anyway? I would > > throw the old stuff away... > > No, I missed to tell that the Debian source package[0] has been > heavily modified so it differs with upstream's latest release. > I was thinking just to have the gtk2 port inside diff.gz as another > Debian source hack, probably I'll go that way. With upstream MIA but need for them anyway (since there is a large diff.gz), it may also be an option to fork the code and become upstream yourself. Bye, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: diff.gz contains more than just debian directory
On Thu, Sep 22, 2005 at 08:51:44PM +0200, Vedran Fura? wrote: > Is it OK to have more than debian directory (and files under it) in > package_version-rev.diff.gz? I have a lot of other diffs outside debian/ > (in aclocal.m4, Makefile.in,...). The problem is that after I run > ./configure and then make distclean, I don't have the same directory (as > it was before ./configure). Can I ignore this? It is no problem to have changes outside the debian/ directory, if they are really changes you want to make (in which case you will often want to send them upstream as well, for inclusion in a future version). However, files generated during the build should be removed in the clean target of debian/rules. It does not matter if they were present in the original tarball. The important part is: - It's best if the diff.gz is readable. That means you should avoid getting generated stuff from autotools in it. Remove it instead during clean, that will make sure it will be ignored for the diff. - running debian/rules clean (as (fake)root) should always return the package to a state where running debian/rules binary can handle it again. This must be true even if a previous clean or build was aborted. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: there was php4-eaccelerator ?
On Fri, Sep 23, 2005 at 04:04:12PM -0300, Jose Carlos do Nascimento wrote: > Hi, Roberto > > But this package can be put in non-free ? No. The code links to non-free stuff, and doesn't have an exception for that in the license. Distribution of binaries (modified or not) is only allowed if they don't link to the PHP things (which of course excludes non-modified binaries). This is the FSF's interpretation of the scope of the GPL. Some people disagree, though. But AFAIK Debian follows this interpretation when it comes to including thingsin non-free. > >Please see the following threads: > > > >http://lists.debian.org/debian-mentors/2005/05/msg00148.html > >http://lists.debian.org/debian-legal/2005/01/msg00130.html > >http://lists.debian.org/debian-devel/2005/05/msg00681.html > > > >Check the news statements for 2005/07/11: > > > >http://eaccelerator.net/HomeUk > > > >Probably not a possibility. IANAL, TINLA. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: duplicate library code in a package
On Thu, Sep 29, 2005 at 06:22:43PM +0200, Thomas Viehmann wrote: > Sorry, but I have to point out that your recommendation describes the > very opposite of Debian best packaging practices. > > - Basically, the only reason to repackage upstream is to avoid license > problems. Dropping unneccessary stuff might be OK if hundreds of > megabytes can be saved, but is generally not OK. Agreed. > - Specifically, if you need to update autotool output, this belongs 100% > in the diff.gz (directly or via dpatch et al). Agreed. > It is frowned upon (for good reasons by the qa people) to regenerate > at runtime [1]. I don't agree with the frowning, and I'm not sure if the referenced slide proves your point: > drawbacks: > - Often creates a huge diff > - You will need to take care of timestamps > - Bugs in the autotools are not automatically fixed In particular the last point is something Which I think is important. And what I would also consider a drawback: - It doesn't allow the user to make changes to all source files and have them compiled. Make will try to rerun automake when the Makefile.am changed (I think), but it may not work. > drawbacks of running the autotools during the build: > - Does not require insane build-depends I don't see any problem at all in this. We have Debian, which is full of great software. Why should we be afraid to use it? And really, autotools are not an "insane build depend". Anyone changing and building packages will have them installed anyway. > - You know exactly what is in the autotools files whatever the build > environment Well yes, but at the cost of autotools bugs not being fixed. In general, I would think that if the autotools are going to generate different output, then it's probably because of bugs being fixed. Nothing wrong with using that. However, it does make sense to Build-Depends: on and explicitly call a specific version of aclocal/automake, because different versions of that can have quite different output (or fail to parse input). > Also note that deletion of files is ignored for diff.gz creation. Right, I do delete all generated files (including config.sub, configure, Makefile.in) in the clean target for that reason. > 1. http://sam.zoy.org/lectures/20050910-debian/img17.html Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Oracle 10g installer anyone?
On Tue, Oct 25, 2005 at 10:22:43AM -0400, Justin Pryzby wrote: > /opt/ is okay, but maybe you should provide the mechanism by which a > local admin can change the installation root. > > FHS: > >Distributions may install software in /opt, but must not modify or >delete software installed by the local system administrator without >the assent of the local system administrator. Sounds like if you want to use it, you need to check if there already was something there (manually installed by the sysadmin) and fail to install if there was. Doesn't sound like a very nice way to install to me, but appearantly it is allowed. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Question about skim.
On Sun, Nov 13, 2005 at 01:18:12AM +, Sune Vuorela wrote: > A chroot is a nice solution - I use it for many things. > > the program 'debootstrap' can help you building a chroot. > > just: > mkdir sid-chroot > sudo debootstrap sid sid-chroot http://yournearestmirror. > sudo chroot sidchroot I always mount proc (and sometimes /dev, at least when I used devfs). Without it, the system is handicapped, although package installs should work. sudo --bind /proc sid-chroot/proc Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: repack upstream sources or overrides ?
On Tue, Nov 15, 2005 at 12:59:49PM +0100, Frank K?ster wrote: > > So you suggest that I do not repack source and do not add overrides ? > > > > http://ftp-master.debian.org/REJECT-FAQ.html > > about lintian in the serious violations-part > > "Sometimes there are valid reasons, but then you should either file a > > bug against lintian if it's generally wrong or include an override in > > your package, giving a reason in the changelog for it" > > I don't know how communication with the ftp-masters works these days; > ideally they would read through files in the debian dir (what about > README.ftp-masters :-)...) and find your note about the reasoning. I > would not just add a lintian overrides without having the package > double-checked by a person who really understands the issues and > verifies that the files will really be out of effect. I am confused about the purpose of lintian overrides. Can someone explain it to me, please? I thought an override would be in order when lintian complains, but there isn't really a bug. In other words, in case of a false positive. A lintian bug report may be in order as well, as the reject-faq says. In this case, the warning is not wrong at all. It is a bug, and it needs to be fixed. In this case, it can only be fixed upstream (I'm assuming here that this is not enough reason to repackage the tarball). Upstream has also agreed to fix it in the next release. So I thought that a lintian warning/error should be seen as a bug in the package. An override would be a WONTFIX tag on it, effectively closing the bug. Obviously, this needs a rationale. Here, the bug will be fixed, but isn't yet. Forcefully closing it for that reason doesn't seem like a good idea. Better file a real bug report on the package and tag it PENDING (or not, depending on the details upstream). Am I misunderstanding what overrides are for? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Problem with removing rc script
Hello Lars, Thank you for reporting this problem. Hello mentors, I received bug report #339387, and want to solve it in an elegant way. The problem is that gnocatan-meta-server used to have an rc script to start it, but now it's a transitional package (and the script moved with the rest to pioneers-meta-server). Appearantly not having the scripts anymore is no reason for dpkg to remove the symlinks. So I should do that by hand. The question is how. The bug report suggests to manually do it in the postinst, is that a good idea? I was thinking of adding an empty script so it will be removed at package purge. That way I would be sure debhelper can do all its magic, and I would be more sure that the Right Thing(tm) is done. What is the usual way to solve this situation? Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Rationale behind script-not-executable lintian warning
On Wed, Dec 21, 2005 at 05:45:43PM +0100, Frank K?ster wrote: > It's of course clear that any script in the path should be executable. > But if a script is in /usr/share/somewhere, and meant to be used as a > "library", it could be that upstream wants to allow both to source and > to execute it. > > So to make lintian happy, I would have to make it executable although I > know it will never be executed by Debian programs. Or I would have to > patch the file to remove the shebang line. If it is meant to be executed, it should be executable. If it is not, it should not have the shebang line. I don't see the problem. Indeed, if upstream wants to allow both to source and to execute it, then it is meant to be executed and thus should be executable IMO, even if the script is never executed from the Debian package (but only sourced). > Therefore I'd rather keep things as they are, but there must be a reason > for the lintian warning. In the Policy section on permissions I > couldn't find anything specific. I haven't seen anything in policy either, but I can't see any use for having a shebang line without execute permissions. Can you give an example? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Rationale behind script-not-executable lintian warning
On Thu, Dec 22, 2005 at 10:21:46AM +0100, cobaco (aka Bart Cornelis) wrote: > On Wednesday 21 December 2005 18:41, Bas Wijnen wrote: > > If it is meant to be executed, it should be executable. > agreed > > > If it is not, it should not have the shebang line. > > I disagree, there's nothing wrong with clearly documenting what shell > variant a script is written in, on the contrary IMHO > > Also note that lintian already excludes several locations from this warning > (such as /etc/X11/Xsession.d/). Hmm, in that case the lintian maintainers appearantly agree that scripts which are only sourced may have the shebang. Then it seems logical to me that an override would be in order. However, I don't understand what the check is for, if not for cases like these. So my logic may very well be incorrect. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFS: knmap -- Kde interface to nmap [uploaded]
On Sat, Jan 14, 2006 at 08:45:07AM -0200, Henrique de Moraes Holschuh wrote: > On Fri, 13 Jan 2006, Steve Langasek wrote: > > There are *always* libraries in a state of transition in Debian. Using the > > Debian libtool means limiting those transitions to packages which have a > > valid reason for depending on the transitioning library, instead of giving > > us transitions that ripple through all the indirect reverse-dependencies. > > > > Just to be clear, relibtoolizing should only need to be a one-time thing. > > We differ in opinions, here. I'd rather people wrote a proper > autogen.sh-like script for their packages, so that they could easily and > PAinlessly autoreconf (or the equivalent) their packages often. I completelely agree. When I read Steve's e-mail about libtool (referenced earlier in this thread), I was again confirmed in my position (although I think Steve doesn't agree with it) that running the autotools (and that includes libtoolize) from debian/rules is a very good idea: It makes sure that the latest (and presumably best) version of everything is used. And that "everything" includes libtool and autoconf, but also Makefile.am and configure.ac. Of course I know the classical argument against this: To build a program, you should only need to do "./configure;make;make install". configure is the platform independant script, autoconf should only be used by upstream. I strongly disagree with this line of argument. Autoconf was indeed created to allow building on platforms which don't have any special portability tools installed. In particular, they don't need to have autoconf installed. However, this is completely irrelevant if we _do_ have them (and on Debian we do, of course). So the distribution of the program is in such a way that it can be built on half-broken architectures? What do we care, we can just build the thing from source, thus ensuring we don't have a FTBFS, and ensuring that the sources we have in the source package are actually the sources of the binary package. The user who only downloads the tarball needs to do nothing more than "./configure;make;make install". But running "./autogen.sh;make;make install" (if available, otherwise running "libtoolize --force;aclocal-1.9;automake-1.9 -a;autoconf;./configure;make;make install" ) gives better results in many cases, and should IMNSHO always be done to avoid accidental use of old versions of anything. The thing is, in the ideal world relibtoolize would be a one-time thing, and autotools should only be needed by upstream. Come to think of it, relibtoolize wouldn't be needed at all of course. But in this not se ideal world, bugs are fixed, both in Makefile.am/configure.ac and in the autotools themselves. The best way to handle that is to rebuild everything from source, and that includes ./configure and ./libtool. > For most up-to-date packages re. autotools, this is just a call to > autoreconf. autoreconf has the annoying property of preferring automake 1.4 if it is installed. So you need to set the environment to the proper versions for it to work. I prefer directly calling the correct version of it. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Extra debian repository
On Fri, Jan 13, 2006 at 08:04:01PM +0200, Mugurel Tudor wrote: > So what am I doing wrong? If apt has two versions available for a > package,one from it's own repository, and one from a third party > repository, it doesn't install automaticaly the one with the higher > version? If not, what should I do in order to complete this kind of > setup? I think this is because of the signing of packages which happens and is checked nowadays. If two versions are available, of which only one is trusted, it chooses the trusted one, no matter what the versions are. You should somehow sign your own archive and add your public key to apt's keyring (I'm guessing it's in /usr/share/keyrings or /usr/share/apt). I haven't done anything like that though, but I suppose the internet can tell you a bit more. :-) Bye, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: [Update] Re: What to do if the upstream keeps debian directory in original tarball?
On Thu, Jan 26, 2006 at 07:30:22PM -0800, Stan Vasilyev wrote: > From the last e-mail I got from Thierry it looks like he wants to make a > compromise. Since I annoyed him so much with my e-mails, he proposed to start > releasing Xdialog in two versions: Xdialog-version.tar.bz2 file with debian > directory and Xdialog-version.orig.tar.gz without the debian directory. Is > that such a good idea? I don't see a reason to have a version with a debian directory, but if he insists on having that, this sounds like a good compromise. > At this point he thinks that Debian developers are a bunch of political > fanatics who only care about the holy Debian Policy Manual and don't care > about other distros. Oh, misunderstandings... Well, some of us[1] are. ;-) Anyway, personally I think that Debian users benefit a lot from the policy, because they know what to expect from packages. I really don't see why the (unwritten) policy of "don't bother others with your distribution-specific stuff" is offensive for those others.[2] Well, it would be nice if you could make him think less negative about us. :-) You seem to be doing a good job at least in getting results. Keep it up! Thanks, Bas [1] I'm not an official Debian Developer, but I do consider myself a Debian developer (mind the lowercase 'd'). [2] Note that I do think having a debian directory in cvs (or svn, or whatever they use) is useful, if it is maintained. It just shouldn't be in the release tarball. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Re-libtooling + automake
On Mon, Jan 30, 2006 at 01:19:08PM +, Martin Meredith wrote: > I do know of this - but looking for a solution for now so I dont have to go > down that road unless absolutely neccesary :d (for example - the lsdiff | > touch -r) Do I understand correctly that you want to avoid running automake from debian/rules, even at high cost? Personally I think using touch is very high cost, as it seems quite fragile and may easily result in a broken compile (that is, some things may be forgotten or so). And I may be becoming repetitive, but I still haven't heard any reason why running autoconf/automake from debian/rules would be bad. Obviously you need to depend on the correct version and explicitly call it (Depends: automake1.9 ; export AUTOMAKE=automake-1.9), but I don't see a problem in that either. Many problems solve themselves when you compile from source instead of using pre-built files. That is true for executables, it is true for Makefile.in and configure as well. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Re-libtooling + automake
On re-reading this message, it seems to have a harsh tone. Sorry about that,
that was not my intention. Also I don't want to start a flame-war or
anything, but I do want either me or "the others" (whoever that includes)
convinced about the proper way of packaging programs with autotools. Or else
I want to be convinced that that's not going to happen. ;-)
On Fri, Feb 03, 2006 at 12:16:08AM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 02 Feb 2006, Damyan Ivanov wrote:
> > Bas Wijnen wrote:
> > > Many problems solve themselves when you compile from source instead of
> > > using pre-built files. That is true for executables, it is true for
> > > Makefile.in and configure as well.
> >
> > QA team seem to disagree. See
> > http://sam.zoy.org/lectures/20050910-debian/img0.html
>
> So, yes, *do* build everything from source (i.e. bootstrap all autotools
> from known-good Debian packaged autotools). You just don't need to do it at
> dpkg-buildpackage time, you can also do it before that.
The slides mention a number of possible problems when packaging programs which
use the autotools. Every single one of them can be solved by running auto*
from debian/rules (this is also pointed out in the slides). Still they claim
that this is not a good idea, for the following reasons:
1 You will need to build-depend on the proper version of each tool
2 The clean rule will be a nightmare to write
3 It creates useless build-dependencies
4 Unless you really know what you are doing, you will simply get it wrong
In my opinion, none of them are valid:
1: What's the problem with build-depends? We have a Debian system, all those
things are available. Yes, you need the correct version, so? We have the
correct version. Pbuilder will scream at you when you got it wrong.
2: I've seen worse nightmares, but I agree that it would be a good idea if
automake would generate an "autoclean" target, cleaning up all the stuff
that they leave. Anyway, once you've written the clean rule, it's always
the same: rm -f configure config.guess config.sub libtool ; find .
-name Makefile.in -exec rm {} \;
Since writing the clean rule needs to be done only once, it is much easier
than rerunning the autotools before every release, as is suggested.
3: See 1
4: If you're going to get it wrong, then why don't you get it wrong when doing
it manually before building the package? Of course you need to know what
you are doing, if not then you should orphan the package.
Apart from these points, which I hope we now all agree on (although I fear
this isn't the case), there are some other things:
- All the positive effects of running them before building the package of
course apply when running them during package-build. (using the latest
version and so on.)
- The .diff.gz becomes readable (a big advantage IMO, I usually check the diff
before sending a package to my sponsor, to see if I didn't accidentily put
things in that don't belong there).
- It is impossible to accidentily forget to rerun the autotools.
In other words, it prevents mistakes in the packaging. This is a Good Thing.
And the only bad thing about it seems to be resource consumption on the
buildds. Compiling will cost more time, and the build-depends need to be
retrieved and unpacked as well. Personally I think that if this becomes a
problem, it should be solved by finding more resources, not by using
pre-compiled parts of the source. But this is really the only valid concern I
can think of.
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
Removing former conffiles
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. 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? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Removing former conffiles
On Tue, Feb 07, 2006 at 12:28:39AM -0800, Don Armstrong wrote: > On Tue, 07 Feb 2006, Frank K?ster wrote: > > Don Armstrong <[EMAIL PROTECTED]> wrote: > > > Just a word of caution here: If the administrator has modified the > > > file, you should not rename or move it, as they may know better > > > than you what they're doing. A proper course of action would be > > > warning them, and/or offering to remove the files in question via > > > debconf. > > > > If I know that the file will no longer be read at all, there's no > > point in pretending that it still have an effect. Renaming it makes > > this completely clear. > > Right. The problem is that it's not always easy to know if the file > will no longer be read at all; you can't assume that the administrator > has left in place your default configuration system. [Likewise for > failure modes on the presence of an obsolete configuration file; > unless you know for certain that it will fail, you should give the > administrator some way to override your guess.] The package is a dummy transition package. When this version of gnocatan is installed, no gnocatan config files will be read at all anymore. It might have been a good idea to try and convert it into a pioneers config file (the new name of the package), but as long as the name includes "gnocatan", it's not going to have any effect, since there are no binaries in the gnocatan-* packages anymore (well, except this maintainer script). Would that mean it's ok to remove it? Or should I better rename it so they can use it to convert to a pioneers file by hand? Perhaps that's the best... I could make a NEWS message about that as well. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
RFS: sdljump
Hello mentors, In the games team, SDLjump was mentioned as a candidate for the graphical installer. However, it was not packaged yet. So I've done that (but left out the udeb-parts for now). I'm looking for a sponsor to check and upload the package. Package: sdljump Section: games License: GPL Description: a platform game where you have to jump up to survive The goal in this game is to jump to the next floor so you don't fall down. As you go higher in the falling tower the floors will fall faster. Try to survive longer than anyone, or, in single player mode, try to get as high as you can. . This game is a clone of xjump, and provides all its features, plus some more: * Multiplayer mode (up to four players, not networked) * Smooth graphics possible (but xjump style as well) . Home page: http://sdljump.sourceforge.net The package can be found at http://pcbcn10.phys.rug.nl/~shevek/sdljump/. The .udeb which is there is not part of it. The udeb-generating parts are commented out. That file is just there because I referenced it in linda-bug #352250. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFS: sdljump
Hi, On Sun, Feb 12, 2006 at 12:42:54PM +0100, Alexander Schmehl wrote: > * Bas Wijnen <[EMAIL PROTECTED]> [060212 12:08]: > > . > > Home page: http://sdljump.sourceforge.net > > Pointing to [1] I would suggest to change that to ".\n Homepage:" Thanks, fixed. > > The package can be found at http://pcbcn10.phys.rug.nl/~shevek/sdljump/. > > No, it can't ;) Oops, sorry. That should be http://pcbcn10.phys.rug.nl/~shevek/debian/sdljump/. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFS: sdljump
On Sun, Feb 12, 2006 at 12:42:26PM -0300, Margarita Manterola wrote: > So, why run aclocal and delete all those files unnecesarily? Even > though the package is exactly the same as with the simpler rules, it > smells like a source of bugs to me. Like if in the future aclocal-1.9 > stops being present in Debian, this will fail, even if the package > would compile otherwise. I expected this question. :-) There are several reasons for it. First of all, and most importantly IMO, I want all files to be compiled from source. As you can see from the rules (in particular the autoconf-archive part), it isn't actually a trivial matter to find out how to do that. I want users who feel like modifying the source to be able to recompile. That includes when they modify configure.in. For that, the autotools must be run, and I think it makes sense to have the "machine-readable build instructions" in debian/rules. There are a few more reasons, but I wrote about them on this list recently, and would probably bore many people when repeating, so I'll give a link to it instead: http://lists.debian.org/debian-mentors/2006/02/msg00037.html > By dropping this, you could drop the dependencies on automake1.9, > libtool, autoconf-archive. (This is the linda warning. It's not > usually a good idea to depend on autoconf and the rest of the family). I know linda used to warn about this, but they stopped doing so after I asked them to. See bug #327057. At least on my system, it doesn't warn about it anymore. > About the description: > > This game is a clone of xjump, and provides all its features, plus some more: > * Multiplayer mode (up to four players, not networked) > * Smooth graphics possible (but xjump style as well) > > It also provides different themes, and OpenGL support is optional. Yes, these are good to include as well. Thanks. > Finally, the ELF file uses only 68KB, while the whole package uses 1,5 > MB of arch-independent files. It certainly looks as a candidate for > package and package-data splitting. What do you think about that? Sounds like a good idea, I hadn't thought about it. > BTW, I'm willing to sponsor the package just as it is right now, but > I'd like you to take into consideration this comments. I've just changed the package to include the comments. The new version is in the same place (http://pcbcn10.phys.rug.nl/~shevek/debian/sdljump/). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Proper way of cleaning packages with autotools
On Sun, Feb 12, 2006 at 07:43:43PM -0500, Justin Pryzby wrote:
> On Sun, Feb 12, 2006 at 12:42:26PM -0300, Margarita Manterola wrote:
> > On 2/12/06, Bas Wijnen <[EMAIL PROTECTED]> wrote:
> > -$(MAKE) maintainer-clean
> > rm -f config.guess config.sub configure depcomp INSTALL install-sh \
> > ltmain.sh missing mkinstalldirs config.log aclocal.m4
> > -find . -name Makefile.in -exec rm {} \;
> Sorry to bring up an old thread;
I hadn't seen it before, but that may be because the subject wasn't very
descriptive (like this time). I changed it so people ignoring the thread may
read this anyway.
> -$(MAKE) clean is considered bad; see #325372: 'lintian: please add
> check for careless usage of "make clean" and the like'.
Although I don't agree that it's like "swatting a fly with a neutron star", I
can see that it's not really nice. :-)
I changed it, and I also changed the rm -f into a rm $(wildcard ...) (with a
check if that isn't empty). And I changed -find into find, which it should
have been anyway (since it doesn't fail if it doesn't find anything).
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
Re: RFS: sdljump
On Mon, Feb 13, 2006 at 01:16:34AM +0100, Bas Wijnen wrote: > On Sun, Feb 12, 2006 at 12:42:26PM -0300, Margarita Manterola wrote: > > Finally, the ELF file uses only 68KB, while the whole package uses 1,5 > > MB of arch-independent files. It certainly looks as a candidate for > > package and package-data splitting. What do you think about that? > > Sounds like a good idea, I hadn't thought about it. A small problem with it though: When I put all architecture independant data in its own package, lintian starts complaining that the binary lacks a manpage. For the moment, I moved the manpage back in the arch:any package (it's small anyway), but that doesn't seem to be a good solution. Is an override in order for this? Or is there a better solution? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Finding dependencies
On Tue, Feb 21, 2006 at 03:19:30PM +0200, Eddy Petri?or wrote: > grep -r -e "\s*#include\s\s*<" . |sort -u At least gcc doesn't have a problem with anything which matches '^\s*#\s*include\s*<' So that may be a better expression. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: first package pcftisio
On Tue, Feb 21, 2006 at 02:22:05PM +0100, Cedric BRINER wrote: > And I still have some questions > > - Do you know in which sections shall I put this package which is related > to python, astronomy ? (how should I proceed to know in which section to > put it) Programs which happen to be written in python don't belong in the python section. Only things which are interesting for people who use python should be there. That is mostly libraries which can be used by python programs. In general, it is a problem that a package can be in only one section. Some packages fit in more than one. You have to choose the one where it fits best. > - After trying to make the debian source with the help of the book:"the > Debian System". I'm getting some errors after doing: > dpkg-source -b python-cfitsio-0.99.2/ >dpkg-source: building python-cfitsio using existing > python-cfitsio_0.99.2.orig.tar.gz >dpkg-source: building python-cfitsio in python-cfitsio_0.99.2-1.diff.gz >dpkg-source: cannot represent change to > debian/python-cfitsio/usr/lib/python2.3/site-packages/pcfitsio.so: binary > file contents changed When building a package, the source tree must be clean. Usually, the cleaning is done automatically (that is, fakeroot debian/rules clean is called). There are some options: - You used a build method which didn't include cleaning. I find this unlikely. - Your clean target doesn't properly clean up. In particular, it doesn't call dh_clean. - You had some packages in your control file before which aren't there anymore, so dh_clean doesn't remove the debian/packagename directories. In that case, you need to do this by hand. Actually, "doing it by hand" will work anyway. Just call "fakeroot debian/rules clean", then remove all files and directories from the tree (in particular debian/) that shouldn't be there, then build. When you call debuild, you don't need to do all that (unless you have changes in the tree which shouldn't be there.) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: first package pcftisio
On Wed, Feb 22, 2006 at 01:42:18PM +0100, Cedric BRINER wrote:
> the error that I've mentionned in my previous email, was that after making a
> cd python-cfitsio-0.99.2/
> fakeroot debian/rules binary
> fakeroot debian/rules clean
> cd ..
> dpkg-source -b python-cfitsio-0.99.2
> and that I was having thi directory : python-cfitsio-0.99.2/build
> -sould this one be located here after the compilation
It depends on the program's build process. If it is created by the build
process, then it is correct that it is still there.
> -or should this one be deleted adfer fakeroot debian/rules clean
Yes. The clean target should leave the tree in the state it was before the
build started. This means:
- Any debian-specific patches are applied (they end up in the .diff.gz).
Usually this includes the whole debian/ directory.
- Any generated files which were present in the original tarball, to which the
(generated) changes should not be in the diff.gz should be deleted. That
way they are ignored by the diff. This can be used for example for
Makefile.in (and the rest of the autotools junk) when running the autotools
from debian/rules.
> now I'm having an other problem that I hope I solved..(is that correct?)
> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
dpkg-gencontrol substitutes some stuff from debian/control to be their actual
values. In the build process, these values can be defined. In some cases,
they aren't, which leads to this kind of warnings. Personally I prefer to
leave the parts in, so when the build process changes and they would have a
value, it is automatically used. If you think you will remember, you can
remove them and put them back when they are needed.
> so, what I've understand is that there is no such way do this for python
> package. Even for a shared object used by
> this module( /usr/lib/python2.3/site-packages/pcfitsio.so) ??
> so I've modified the control file by adding a key to Depends:
> Depends: ${shlibs:Depends}, libcfitsio2 #${misc:Depends}
I haven't done any python packaging, so I'm not sure about this. But in
general, dh_shlibdeps should fill in shlibs:Depends to be all the libraries
you need. In case of python, perhaps dh_python does this instead. It seems
unlikely that the list is not generated (if it can be, which I assume perhaps
incorrectly).
> I've got also:
> gpg: skipped "cedric briner
> is that mandatory to make it work ?
In order to upload the package, it must be signed by a Debian Developer. It
is a good idea to sign your packages anyway, even if you are not a Debian
Developer. That way your sponsor knows it was really you who made the
package. For that, you need gnupg installed, and you need to have a gpg key
(which you can generate with it).
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
Re: RFS: b5
Hi, On Tue, Feb 28, 2006 at 07:18:31PM +0200, Panu Kalliokoski wrote: > On Wed, Mar 01, 2006 at 03:52:04AM +1100, skaller wrote: > Thank you for this explanation. Although I still have some issues with > it, it seems I should build infrastructure for building source packages. > (Earlier, one just needed dpkg-source -b; now it seems there must be > some script or makefile target to construct a fake .orig directory and > then build the source with that.) It feels funny that I have to make a > dummy "pristine" source for the Debian project while I've been releasing > the "debian-specific" source outside Debian for ages. I see what you mean. However, both from a technical point of view, and from a philosophical point of view, it makes sense: People who are getting your release tarball will not want to build a Debian package (if they did, they'd get your Debian (source) package directly). Also, people who want to use the package on other distributions should not be bothered with debian-specific stuff. The fact that they bother us with their .spec files doesn't mean we shouldn't be nice to them. ;-) Having the debian/ directory under version control is useful. But it shouldn't be included in the tarball when you run "make dist". Of course, if the debian/ directory is not in the release tarball, you'll need a patch to put it in the Debian source. I'm upstream for most of my packages, and it's normal that the diff.gz only contains the debian/ directory. For non-native packages, there is a technical reason not to include the debian/ directory in the tarball as well: the build system doesn't support removal of files from the source (AFAIK). That means that if there's a file in there that shouldn't be there, it can only be made empty. Since some tools react on the existance of files, this can be a problem. Of course that is just a technical issue which can be solved, but since the debian directory shouldn't be in the upstream tarball anyway, there's no hurry. :-) > > Debian tries to maintain standards of packaging quality. > > This may mean someone else may wish to fix bugs in your > > packaging. If your packaging is part of the source tarball, > > that requires editing the tarball. If the packaging is > > separate, the tarball doesn't change, only the packaging. > > This is true, even for bug fixes to the source itself: > > they're diffs in the packaging, your tarball remains > > invariant. > > Okay, this seems to be the same (probably?) as the "transparent NMU" > thingy. It is indeed. > It is imaginable that we can derive some benefit from > separating the "source distribution" into different bits like packaging > and everything-else -- maybe less stuff to upload, although it won't > make any difference with project sizes like this... The benefits are in size only for large projects, indeed. But there are benefits in readability for all packages (in particular when a new Debian version comes out without a new upstream version, such as usually happens in the case of an NMU). > But I still wonder -- if it is beneficial to separate the packaging from > the other source, would it not be beneficial to separate other > components of the source that are not circularly dependent on each > other? Is it, for instance, a problem that if the _documentation_ of a > piece of software changes, the whole .orig.tar.gz gets updated? Is > there something special about packaging information that makes it > especially vulnerable to separate changes, even when the packager and > the upstream author are the same person? No, it's not especially vulnerable, but because of the strong advise to use pristine sources, it's the only part that can actually be split off. Also, splitting the package in many pieces makes it very hard to get and install all the pieces, and you probably don't want to inflict that on your users. ;-) (Remember that we're talking about the release tarballs here, not about the internals behind the Debian packaging. Some people actually use those release tarballs directly.) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFS: b5
On Tue, Feb 28, 2006 at 08:12:45PM +0200, Panu Kalliokoski wrote: > On Tue, Feb 28, 2006 at 06:57:38PM +0100, Bas Wijnen wrote: > > Having the debian/ directory under version control is useful. But it > > shouldn't be included in the tarball when you run "make dist". > > I've never used "make dist", Well, whatever command you use to create the release tarball then. ;-) > because there has been nothing I deemed worth purging from the distribution. Version control crap should not be in the tarball at least. Lintian will warn about it, too. > > No, it's not especially vulnerable, but because of the strong advise to > > use pristine sources, it's the only part that can actually be split off. > > Also, splitting the package in many pieces makes it very hard to get and > > install all the pieces, and you probably don't want to inflict that on > > your users. ;-) > > Well, that's exactly the reason I'm reluctant to split the source: if > you can do perfectly well with one source tarball (for debian users, > non-debian users, and the build system), why not do that? Users of a distribution and users of tarballs are very different. Debian users don't need the tarballs, the tarball users don't need the debian stuff. So the people either download your debian package, or the tarball (and in that case they don't care about the diff.gz). So it doesn't actually get harder for them. > Note that I'm not going to take the debian/ dir away from my _real_ release > sources; just from the Debian source packages, if Debian really strongly > encourages that. Oh no, please don't. You should use the same release tarball for Debian that you actually release. That's what "pristine source tarball" means. If you decide that you want to release the debian/ directory, then it should be in the tarball (and you probably end up with an empty diff.gz). I would advise against it, but not strongly. ;-) I would advise strongly against a native package, though. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Wed, Mar 01, 2006 at 04:55:40PM +, Jon Dowland wrote: > On Tue, Feb 28, 2006 at 12:50:42PM +0100, Andrea Bolognani wrote: > > On Mon, 27 Feb 2006 21:03:06 -0500 > > Removed the useless scripts. Files are at the same place: > > > > http://www.kiyuko.org/pool/beef_0.0.3.orig.tar.gz > > http://www.kiyuko.org/pool/beef_0.0.3-1.diff.gz > ^^^ > > I suggest bumping the package version and making a note of > your changes in debian/changelog when you make a change: the > tool 'dch -i' from the package source dir will help you do > this. Personally, as long as the previous version wasn't released with Debian, and not made public on a large scale either (and advertising to this list isn't a large scale), I don't bump the debian version, but just keep it at -1. As far as I've understood many e-mails here, that seems to be common practice. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Wed, Mar 01, 2006 at 10:56:55PM +0100, Andrea Bolognani wrote: > The package has never been in Debian, and even if it had, no one would want > to update it just because of a change in the mantainer scripts: the content > of the package is exactly the same. If you would upload it while the previous version was in Debian, you would need a new version. Debian doesn't support uploading a version of a package which isn't higher than the one currently in the archive. If you mean you wouldn't want it uploaded at all for such a change (but let the change come in with the next version), then I agree with you. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
On Fri, Mar 03, 2006 at 11:41:59PM +0100, Andrea Bolognani wrote: > > * W: The program is licensed under GPL version 2. > > Will not fix. From the Policy, section 12.5: > > "Packages distributed under the UCB BSD license, the Artistic license, > the GNU GPL, and the GNU LGPL should refer to the files > /usr/share/common-licenses/BSD, > /usr/share/common-licenses/Artistic, /usr/share/common-licenses/GPL, and > /usr/share/common-licenses/LGPL respectively" > > So /usr/share/common-licenses/GPL is the right file to point to. Perhaps Policy needs an upgrade here... It seems logical to me that you must always point to the license which is used. In case of "GPL version 2 or later", that is usually understood as "the latest version of the GPL" (although of course the user may choose to use an earlier version, as long as it's at least version 2). This is what the GPL symlink is for: it always points to the latest version. A program which is "GPL v2 only" is of course not licensed under "the latest version", but under v2. The fact that they are currently the same is irrelevant: they are conceptually different. So the GPL symlink is simply the wrong thing to point at, because it isn't the license which is used (because it's "the latest version", not "version 2"). Appearantly policy isn't so clear about the /usr/share/common-licenses/GPL-2, but it being there strongly suggests that it should be used for programs which are licensed under "GPL v2 only". Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Non-Debian packaging practice
On Fri, Mar 10, 2006 at 10:35:22PM -, StealthMonger wrote: > Is there a document describing software packaging good practices for > general use, not specific to Debian, preferably in electronic form? Policy describes how Debian packages should look. If you don't intend to get the package into Debian, it's still a good idea to follow those rules, because the users which will install the package want a consistent system (and the fact that Debian packages follow Policy is the reason that they usually get it, too). > Debian discourages creating Debian-native packages: "This type of > packaging is only appropriate for the debian-specific packages, which > will never be useful in another distribution." [1] That's right. The idea is that packaging is Debian's business, and upstream shouldn't need to bother with it. Also, non-Debian users shouldn't be confused by a bunch of extra files in the source that do nothing for them. So the "release tarball" should not contain any packaging stuff, as far as Debian is concerned. (Yes, I know other distributions have different opinions about this.) > But creating it for other distributions requires some knowledge of what > those other distributions expect of a package. I don't know what you mean with that exactly. If you're referring to the fact that they need files in your release tarball, that's IMO a bug in their packaging process. What should be in that file? I don't know, ask them. ;-) Debian tries not to put any limits on the way you wish to release your source. So if you make a proper Debian package, then the foo_version.orig.tar.gz should be usable directly for any other distribution as well. (In fact it is of course the other way around: you use your release tarball directly for Debian.) There currently is a limit that it must be .tar.gz, and not .zip or .tar.bz2. I think this is something that will be fixed in the new (not yet working) package format. > The current interest here is primarily in packages consisting of shell > scripts, as opposed to compilable code, but presumably the question > arises in either case. For packaging it doesn't matter much what it is. In case of shell scripts, your compile rule will be short. ;-) As an aside: remember to use Architecture: all, not any, for such architecture-independent packages. Not that it matters much if you don't upload them to the archive. :-) I hope this answers your question. If not, please rephrase it. ;-) Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Non-Debian packaging practice
On Sat, Mar 11, 2006 at 02:04:32PM -0500, Justin Pryzby wrote: > > 3. Version differences: This is a legitamate gripe. The autotools don't > > work nearly as wel as they could when developers > > are using different versions. However, I see no way to easilly fix this. They could have done more for backward compatibility, but as it is, you need versioned depends, and you need to call them with explicit versions. That's not too hard though, and it solves the problems. > > So I must ask why do people dislike the autotools? > I've never been able to figure out what they do for me. > > The possible exception is in combination with gnulib, but this seems > inconsistent, since most people I've asked, who know "about" autofoo, > don't know what gnulib is. But I'd love to understand more than I do. I've been using gnulib without autotools without problems. For me they are completely orthogonal, really. Then again, I never really used autoconf, so I may be missing something. :-) > Correct me if I'm wrong .. but thats now how it works. autoconf seems > to provides a kind of a framework to facilitate portability, It does provide a framework, but you still need to do a lot more than just write a configure.ac if you actually want portable code. > and automake provides a framework for creating makefiles with common and > useful targets. > Just stuffing autotools into an existing project just adds crud, with no > benefits. I see a contradiction here. At least I think having "common and useful targets" in a Makefile is a benefit. ;-) Personally, I use automake, not autoconf. Since automake only produces Makefile.ins, not Makefiles, I need to add some autoconf junk, but I don't actually do any tests in there that aren't needed for automake variables. And it does really have a function, because I don't want to know what compiler flags I need to use libfoo, and I don't want to know if there is perhaps a foo-config script either. But I'm not going to test for a library just to find out about build depends. They are documented in the README or INSTALL, and people should read those (at least after they find out the build fails). I'm pretty sure this doesn't produce portable code, but I wasn't aiming for that, so I don't mind. It does give me Makefiles with "common and useful targets", as you say, and I think that is very valuable. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: [Q:] Which tool creates the DEBIAN subdirectory
On Mon, Mar 13, 2006 at 10:21:35AM +0100, Rainer Dorsch wrote: > Am Montag, 13. M?rz 2006 02:28 schrieb Joe Smith: > > "Rainer Dorsch" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > > > Hello, > > > > > > I tried to package cpuinfo but it seems that the files in debian/tmp did > > > not make it into the .deb file: > > > > debian/tmp is only used if debian/compat does not exist or contains '1'. > > My guess is that your package has some other value in debian/compat. > > If that is the case, install to to debian/ (replacing package > > with the name of the binary package) instead of debian/tmp. When using debhelper, dh_install will do that for you sortof automatically. If you have defined a binary package foo in debian/control, and there is a file debian/foo.install, then putting this in dh_install: debian/tmp/usr/bin/bar will install that file to the same path, minus "debian/tmp/", if it is at the start, in debian/foo. Of course there's nothing against doing that by hand, but I like this approach, so I think it's good that it is mentioned. :-) In fact, your build must have warned you about all the files in debian/tmp, because you use the --list-missing option. For more details, see the dh_install manpage. > That was a hit, many thanks. debian/compat contained 4, installing to > debian/cpuinfo solved the problem. > > Is there documentation on debian/compat? Apparently dh_make generated this > file... It's the compatibility level used by debhelper. In general, it's a good idea to use the latest version (which is currently 5) or at least the version in stable (which is currently 4). Older versions are less featureful, and since few people use them they may not actually work as they should. :-) See the debhelper manpage for details. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: [Q:] Which tool creates the DEBIAN subdirectory
On Mon, Mar 13, 2006 at 11:18:15AM -0500, Justin Pryzby wrote:
> > > > > If that is the case, install to to debian/ (replacing
> > > > > package with the name of the binary package) instead of debian/tmp.
> > >
> > > When using debhelper, dh_install will do that for you sortof
> > > automatically. If you have defined a binary package foo in
> > > debian/control, and there is a file debian/foo.install, then putting
> > > this in dh_install:
> >
> > I did not have a debian/foo.install. I am wondering, if I need to all all
> > files manually in debian/foo.install... So I would put the files in
> > debian/tmp (using the DESTDIR variable in the makefile) and the copy it
> > from debian/tmp to debian/foo by listing all files in debian/foo.install
> > and running dh_install? Installing directly into debian/foo looks like a
> > shortcut to me and listing all files in debian/foo.install looks like
> > tedious work to me, but maybe I miss something...
You can use wildcards in the *.install files. For example, you can put a line
with "debian/tmp/usr/bin/*" (or just "debian/tmp/usr/bin") in it and it will
recursively install all those files into the package.
> No; if possible, you probably want to $(MAKE)
> DESTDIR=$(CURDUR)/debian/package/ install, and then add/remove some
> special-case files from there. But sometimes there are just too many
> files to do this well, expecially for splitted packages ("multiple
> binary") in which case it can make sense to install to ./debian/tmp/
> (or any other arbitrary directory, tmp has no relation to the previous
> DH_COMPAT=1 use of tmp), and then use foo.install to the real
> locations.
AFAIK, there can be a few reasons to use *.install files instead of directly
installing things into the package directory:
- Multiple binary package. One source produces multiple binary packages, and
the files must be distributed over them. Installing in one of the packages
and moving files for other packages out seems hackish, although it would
work as well. dh_install is more clean in such a situation IMO.
- Detect upstream changes. In that case, use --list-missing (or better,
--fail-missing), possibly with -X to explicitly say that some files should
not be installed (by dh_install: when installing manpages with
dh_installman, --*-missing will not know about it for example).
- Have the same rules file everywhere. I don't think this is a very good
reason, but some people may like the idea of not having different rules
files for different packages.
Note that all of these reasons are a matter of taste: if you want to use
dh_install, go ahead. But if you prefer manually moving files around, or
directly installing into the package directory, there's nothing wrong with
that.
> > > debian/tmp/usr/bin/bar will install that file to the same path, minus
> > > "debian/tmp/", if it is at the start, in debian/foo. Of course there's
> > > nothing against doing that by
> >
> > Hmm... what you do mean with if it is at the start, the start of what?
> I guess this is the stuff talked about in dh_install(1).
Yes.
> > > In fact, your build must have warned you about all the files in
> > > debian/tmp, because you use the --list-missing option.
> This seems like a good idea to use ..
>
> There's also a bug which I can't find right now requesting that ./tmp/
> be empty otherwise some command triggers a warning/failure, the idea
> being that upstream changes can be more easily detected.
As far as I know, that's what --fail-missing is for. It wouldn't work with
dh_install anyway, since that copies the files. So they will still be in
debian/tmp after they are installed in the package directory. I suppose this
was a request for an extension to dh_movefiles (which is now deprecated).
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
Re: Regarding co-maintaining a package
On Sun, Mar 19, 2006 at 01:06:42PM +0530, Kumar Appaiah wrote: > Hello! I wanted to know what the procedure to add someone as > co-maintainer is. I am the maintainer of a package, and would like to > add the name of another person (actually upstream author) as > co-maintainer. I guess I will have to file an RFH bug in wnpp, but how > do I add the co-maintainer and close it? Hi, No, you don't need to file a wnpp bug. Those bugs are there for informational reasons, and there's no important (in the sense that it avoids double work) information in "this guy is going to help me". You can add a co-maintainer by putting his name (and e-mail) in the "Uploaders:" field in debian/control. The result of that is that uploads which have him as the changelog author will not be considered NMUs. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Checking if another package is upgraded at the same time
On Thu, Mar 23, 2006 at 10:50:38AM +0200, Kari Pahula wrote: > Restarting crossfire-server will cause any remote players to have their > connection abrubtly broken and to lose any progress that they've had since > their logon. That's not quite what I'd call a smooth upgrade. I don't know if you are upstream yourself, or if upstream is likely to accept large patches from you, but there is a real solution to this problem. I'd say the problem really is that you cannot upgrade your maps without the players being disconnected. First of all, I point out that you will want the newly installed maps to be usable, so not restarting the server because there are still players on it is not acceptable. There are some options to really solve this: - If you can change the server so that it can use the new maps without a restart, that would obviously solve the problem. You can either do this by always looking on disk, so the new maps are found when needed, or in the way inetd does it, by rereading config files at SIGHUP. - You can also do it like ssh: every connection is forked off when established. Then when the server restarts, the connections continue to exist. If you need clients to talk to each other, then this is probably not an option. It also won't work if existing clients need the new maps. - The coolest approach IMO (but probably not the least error-prone) is to use execv's behaviour of keeping fd's open. It is a huge security design bug that this is the default, but the possibility is nice. ;-) What it means is that you can restart the server without losing your connections. You need to tell the new executable about the open file descriptors (for example via some temporary file). Then if started with a "use this temporary file for state" option, it reads the file descriptors from there and uses them. > Is it reasonable to expect users to expect this behavior on upgrading the > maps? I don't think so, but it's acceptable if fixing it is not feasable. > Would it be enough to put in crossfire-maps description that upgrading maps > will cause the server to restart? It depends on how you think the package will be used. I think in most cases it is better to do the restart, but perhaps you want to add a debconf low priority question if the user really wants this. Then the default is to restart, and people running huge servers which want to keep their clients can use dpkg-reconfigure and manually restart when it is appropriate for them. > At least I think I can safely assume that users will know to expect > that upgrading the crossfire-server package itself to cause the server > to restart. Yes, but even in that case it would be nice if the clients don't get disconnected. ;-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: i18l, gettext and (X)dialog
On Tue, Apr 25, 2006 at 11:52:14PM +0200, Michelle Konzack wrote: > Xdialog --title "sampleprogi" --screen-center --no-cancel --wrap \ > --backtitle "Here a text which show $FOO BAR" --fixed-font \ > --textbox $FILE 30 $DLGW > > this is working fine, but I want the Backtitle i18n. > So I have tried: > > BACKTITLE=`eval_gettext "Here a text which show \$FOO BAR"` > Xdialog --title "sampleprogi" --screen-center --no-cancel --wrap \ > --backtitle "$BACKTITLE" --fixed-font \ > --textbox $FILE 30 $DLGW What do you want to achieve? Is the value of the variable already translated, or untranslatable? Or should the string be translated including the substituted value? In the latter case, you should remove the \ before the $. What string should eval_gettext see as its argument? You need to make sure that it gets that. > Xdialog --title "sampleprogi" --screen-center --no-cancel --wrap \ > --backtitle "`eval_gettext \"Here a text which show \$FOO BAR\"`" \ > --fixed-font --textbox $FILE 30 $DLGW This gives eval_gettext several arguments instead of one, which is very unlikely to be what you want. Also, you actually give the quotes to it, which also doesn't seem to be what you want. A good way of debugging this is by using echo instead of eval_gettext. It will show you exactly what string is given to it. I hope this helps, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: i18l, gettext and (X)dialog
On Sun, Apr 30, 2006 at 03:39:34PM +0200, Michelle Konzack wrote: > > What string should eval_gettext see as its argument? You need to make sure > > that it gets that. > > "Here a text which show \$FOO BAR" I'll assume you mean literally that, without the double quotes. In that case, you should use single quotes instead of double quotes. This is because double quotes still let most substitutions happen, including \$ -> $. That means that the string that eval_gettext will see is: Here a text which show $FOO BAR > > This gives eval_gettext several arguments instead of one, which is very > > unlikely to be what you want. Also, you actually give the quotes to it, > > which also doesn't seem to be what you want. > > > > A good way of debugging this is by using echo instead of eval_gettext. It > > will show you exactly what string is given to it. > If I try > > Xdialog --title "sampleprogi" --screen-center --no-cancel --wrap \ > --backtitle "`echo \"Here a text which show \$FOO BAR\"`" \ > --fixed-font --textbox $FILE 30 $DLGW > > it is outputed correctly, 1. It is output including the quotes, which is probably not what eval_gettext needs. 2. It is output without the \, which may not be what eval_gettext needs (at least above you seem to say that it wants the \ as well). 3. You can't see it, but echo received the words as separate arguments. It outputs them by putting spaces in between. eval_gettext may not accept that at all (I'm not actually familiar with it, so I don't know). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: help with seamonkey
On Fri, May 12, 2006 at 09:46:06AM -0600, Joseph Smidt wrote: > However I am having trouble writing the rules file. First, there is > no 'make clean' aor 'make distclean' that initially works. You have to > configure one like 'make -f client.mk distclean build'. After typing that > command distclean works. You have two options then. Either you assume a clean tree if no Makefile exists, or you create one and use it. Personally I usually choose the former, because otherwise the buildds are wasting their time on clean sources. Of course the latter is more correct, though. > Also, the Makefile wants the directory all the files are in to be named > mozilla but I want it to be named seamonkey-1.0.1. Two options again. :-) Either you change the source (via the diff.gz, but you will want to submit it upstream, I suppose) to not care about the directory name, or you create a "mozilla" directory for your build and copy all the files there. Then you can build in there. That has the added bonus that the previous problem is also solved, because the clean target simply becomes ifneq (,$(wildcard mozilla)) rm -r mozilla endif (You can also use "-rm -r mozilla", or "rm -rf mozilla", but both ignore real errors, which is wrong.) > I was wondering how I can alter the debian/rules file to account for > these issues. You can do that as I described above, but it may be preferrable to patch the sources so they behave better. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
