Re: presumable last policy change before releasing Squeeze?
On Sun, 4 Oct 2009, Paul Wise wrote: Write an article for debaday.debian.net about lbzip2 to promote it and get more users/testers. The DebADay Team has reviewed and published my article under [0]. Many thanks to Ana Guerrero, Martín Ferrari, and the rest of the DebADay Team! Also thank you, Paul, for the suggestion. Cheers, lacos [0] http://debaday.debian.net/2009/11/12/lbzip2-parallel-bzip2-utility/
Re: presumable last policy change before releasing Squeeze?
* ERSEK Laszlo la...@caesar.elte.hu [091006 04:48]: On Mon, 5 Oct 2009, Bernhard R. Link wrote: Note that you might do without a patch. make is build for cases like that in mind, so replacing variables in a makefile you do not like just needs those variables as command line arguments. so just changing debian/rules to $(MAKE) CFLAGS=$(CFLAGS) LDFLAGS=$(LDFLAGS) LIBS=$(LIBS) might do the same without needing to edit the Makefile. Those compiler options must be in the upstream Makefile(s). There isn't anything in the upstream release that would pass those compiler options to the Makefile from the outside. The upstream release is meant to be self-sufficient for any SUSv2 platform. So any port has to move those flags if they aren't in the right place for that port as shipped in upstream. Perhaps I am misunderstanding something here. Let's see if I got anything wrong: 1) we are speaking about lbzip2, aren't we? 2) that one has exactly one Makefile in the upstream tarball not calling any submakes in any strange way. 3) you patch that Makefile to no longer set CC CFLAGS LDFLAGS and LIBS What I am saying is that this patch is unnecessary. you can do that totally in debian/rules by placing those variables in the make invocation within your build-stamp target. Looking at the definition of those variables in your debian/rules also looks very complicated. Unless there is a reason to rerun this script all the time? There is none, but lbzip2 consists of only 5 .c files, so it's not very wasteful when building. Otherwise e.g. some LDFLAGS := $(shell ./lfs.sh LDFLAGS) might be a bit more efficient and easier to look at... := would be certainly easier on the eyes, but it's not supported by SUSv2 make [0], so := is avoided in the upstream version. I could use := in debian/rules, but the examples in the Policy [1] and other stuff I looked at originally IIRC don't use it, so I'm not convinced it wouldn't have side-effects. (Try it out and see if it works is not good enough :)) = and := are exactly the same, except that := is evaluated once and then stored, whereas = is evaluated later. If I were you I would be more worried that all the parsing and reparsing (which causes the need for the extra $) has some side effects. Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Tue, 6 Oct 2009, Bernhard R. Link wrote: 3) you patch that Makefile to no longer set CC CFLAGS LDFLAGS and LIBS What I am saying is that this patch is unnecessary. you can do that totally in debian/rules by placing those variables in the make invocation within your build-stamp target. You're right, of course; macro definitions passed on the command line take precedence. I was very tired and didn't get your point, sorry. The makefile patch is for other reasons necessary, but I can make it shorter by removing this part. = and := are exactly the same, except that := is evaluated once and then stored, whereas = is evaluated later. If I were you I would be more worried that all the parsing and reparsing (which causes the need for the extra $) has some side effects. Okay, since you insist, I'll try to switch to :=. Cheers, lacos -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Sun, 4 Oct 2009, Paul Wise wrote: Talk to the upstream tar maintainers about ways to make tar detect if lbzip2 is available and use it instead of bzip2. I made a proposal under [0]. I amended it under [1]. Please look at [1], it also summarizes how (I think) Debian would be affected. Comments appreciated. Thank you, lacos [0] http://lists.gnu.org/archive/html/help-tar/2009-10/msg0.html [1] http://lists.gnu.org/archive/html/help-tar/2009-10/msg1.html -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Tue, 6 Oct 2009, Bernhard R. Link wrote: 3) you patch that Makefile to no longer set CC CFLAGS LDFLAGS and LIBS What I am saying is that this patch is unnecessary. you can do that totally in debian/rules by placing those variables in the make invocation within your build-stamp target. I tried to do this, but I didn't like the result. I think I could identify with this approach if it wasn't necessary to patch the upstream Makefile at all. Since I have to patch the upstream Makefile, I have to edit it, look at it, and it is very disturbing that I do see (according to the suggestion above) macro definitions at the top, and have to remind myself, yes, those will be overridden by debian/rules. So maybe the Makefile patch is a little bit bigger, but the patched Makefile shows a much cleaner picture this way: no definitions for the macros used all over the place? They *must* be coming from the outside. Why I have to patch the upstream Makefile: the target debian-sanity, which is optionally depended upon, and was developed (IIRC) because my sponsor asked for it, definitely belongs to the Makefile, not debian/rules. This target does real stuff, and in my mind debian/rules should be minimal and mostly contain debhelper invocations; IOW it should be a thin wrapper. = and := are exactly the same, except that := is evaluated once and then stored, whereas = is evaluated later. If I were you I would be more worried that all the parsing and reparsing (which causes the need for the extra $) has some side effects. Wherever lfs.sh is called, I now use := and $(shell), as you suggested. Thanks, lacos -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Tue, 6 Oct 2009, ERSEK Laszlo wrote: On Tue, 6 Oct 2009, Bernhard R. Link wrote: = and := are exactly the same, except that := is evaluated once and then stored, whereas = is evaluated later. If I were you I would be more worried that all the parsing and reparsing (which causes the need for the extra $) has some side effects. Wherever lfs.sh is called, I now use := and $(shell), as you suggested. I'm embarrassed to admit that I can't do even that. I have to temporarily patch lfs.sh (until a new upstream release) because of the move to EGLIBC. If I don't use the original macro definitions, then lfs.sh is called from debian/rules before it is patched by quilt, which is called only later from debian/rules. lacos -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
* ERSEK Laszlo la...@caesar.elte.hu [091004 21:54]: Take a look at the FreeBSD port and see if the Makefile patch is appropriate to include upstream or if not, contact the port maintainer about it. The FreeBSD port creator/maintainer, Gábor Kövesdán, personally offered to do the port [0], and I gratefully accepted (obviously). We already discussed the Makefile patch and concluded that the FreeBSD port needs it, and that upstream can't merge it. A minimal justification sounds like: (1) the port doesn't compile with -D _XOPEN_SOURCE=500, (2) SUSv2 requires -D _XOPEN_SOURCE=500 [1], and upstream is written against SUSv2. No changes are planned for the upstream Makefile, so maintaining the patch shouldn't be much of a burden, hopefully. Note that you might do without a patch. make is build for cases like that in mind, so replacing variables in a makefile you do not like just needs those variables as command line arguments. so just changing debian/rules to $(MAKE) CFLAGS=$(CFLAGS) LDFLAGS=$(LDFLAGS) LIBS=$(LIBS) might do the same without needing to edit the Makefile. Looking at the definition of those variables in your debian/rules also looks very complicated. Unless there is a reason to rerun this script all the time? Otherwise e.g. some LDFLAGS := $(shell ./lfs.sh LDFLAGS) might be a bit more efficient and easier to look at... Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Sun, 4 Oct 2009, Paul Wise wrote: Write an article for debaday.debian.net about lbzip2 to promote it and get more users/testers. Should be in their queue now. Have the package description and manual page reviewed by the Smith Review Project: http://wiki.debian.org/I18n/SmithReviewProject People were kind enough to dissect the package description, I'll start to process their comments now. Talk to the upstream tar maintainers about ways to make tar detect if lbzip2 is available and use it instead of bzip2. Sergey Poznyakoff says he'll accept a patch and guide me, so I'll look into it soon. Thanks, lacos -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Mon, 5 Oct 2009, Bernhard R. Link wrote: Note that you might do without a patch. make is build for cases like that in mind, so replacing variables in a makefile you do not like just needs those variables as command line arguments. so just changing debian/rules to $(MAKE) CFLAGS=$(CFLAGS) LDFLAGS=$(LDFLAGS) LIBS=$(LIBS) might do the same without needing to edit the Makefile. Those compiler options must be in the upstream Makefile(s). There isn't anything in the upstream release that would pass those compiler options to the Makefile from the outside. The upstream release is meant to be self-sufficient for any SUSv2 platform. So any port has to move those flags if they aren't in the right place for that port as shipped in upstream. Looking at the definition of those variables in your debian/rules also looks very complicated. Unless there is a reason to rerun this script all the time? There is none, but lbzip2 consists of only 5 .c files, so it's not very wasteful when building. Otherwise e.g. some LDFLAGS := $(shell ./lfs.sh LDFLAGS) might be a bit more efficient and easier to look at... := would be certainly easier on the eyes, but it's not supported by SUSv2 make [0], so := is avoided in the upstream version. I could use := in debian/rules, but the examples in the Policy [1] and other stuff I looked at originally IIRC don't use it, so I'm not convinced it wouldn't have side-effects. (Try it out and see if it works is not good enough :)) Thanks, lacos [0] http://www.opengroup.org/onlinepubs/007908775/xcu/make.html [1] http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Sun, 4 Oct 2009, Paul Wise wrote: So as long as it is uploaded before the freeze date you should be fine. Thank you. Most Standards-Version updates are of the form Bump Standards-Version, no changes needed and such updates should not be done unless they accompany some other update like fixing bugs or adding a new upstream version. I'm thinking about the whole thing only because a new upstream version is not impossible (documentation changes only). Write an article for debaday.debian.net about lbzip2 to promote it and get more users/testers. I didn't know about debaday. I'll do this. Have the package description and manual page reviewed by the Smith Review Project: http://wiki.debian.org/I18n/SmithReviewProject Definitely. Take a look at the FreeBSD port and see if the Makefile patch is appropriate to include upstream or if not, contact the port maintainer about it. The FreeBSD port creator/maintainer, Gábor Kövesdán, personally offered to do the port [0], and I gratefully accepted (obviously). We already discussed the Makefile patch and concluded that the FreeBSD port needs it, and that upstream can't merge it. A minimal justification sounds like: (1) the port doesn't compile with -D _XOPEN_SOURCE=500, (2) SUSv2 requires -D _XOPEN_SOURCE=500 [1], and upstream is written against SUSv2. No changes are planned for the upstream Makefile, so maintaining the patch shouldn't be much of a burden, hopefully. Document in the manual page or README the TAR_OPTIONS environment variable and how to make tar use lbzip2 by default. I'm not sure if adding --use=lbzip2 to TAR_OPTIONS was any more useful than adding any --use=compressor option; you'd lose the ability to create non-compressed tar files. (Or you'd have to explicitly pass --use=cat on the command line.) You'd also be unable to extract plain tar archives. (Or you'd have to explicitly pass some identity filter with --use on the command line that doesn't choke on -d.) Talk to the upstream tar maintainers about ways to make tar detect if lbzip2 is available and use it instead of bzip2. In that case, tar should support pbzip2 as well. I'll try. Much obliged, lacos [0] http://hup.hu/node/66857#comment-714251 [1] http://www.opengroup.org/onlinepubs/007908775/xsh/compilation.html
Re: presumable last policy change before releasing Squeeze?
ERSEK Laszlo la...@caesar.elte.hu writes: This is tedious and doesn't bring anything to users, so instead of rushing it and possibly making several Policy rounds until Squeeze ships Don't do that. It's deprecated practice to have an upload that *only* addresses Standards-Version; it should only ever be updated as part of a new release being made for *other* reasons, since there's nothing wrong with a package conforming with a slightly out-of-date Standards-Version. I'd like to concentrate it into one session/upload. In this case package tidyness through less work is more important to me than package availability, since it won't bring anything to users, just keep my stuff neat. I only ever consider updating the Standards-Version of a package when I'm already working on the package anyway. From reading other package changelogs, it seems this is the normal way to do it. Are you saying that I should update the package as soon as said external stuff allows, and go with the then-current Policy version into Sqeeze, leaving my sponsor and the build network more time as well? Yes, make a release whenever you think a new release is justified by significant changes in either a new upstream version or the packaging work. Conformance with latest Policy is not by itself sufficient motivation for a new release. Whenever you're already working on the package for other reasons, check the latest version of Policy each time and make any changes necessary to comply with the latest Standards-Version. Each new Policy release has a helpful summary of changes that Debian package maintainers need to be aware of; read them thoroughly and understand what changes you need to make as a result. You should be using the ‘lintian(1)’ tool in some kind of automated test each time you build your package, which will test your package for various problems including many that would be Policy violations (among many other checks). The maintainer of that tool is also involved in administration and development of Policy, so the tool is usually quite up-to-date with the latest Policy. If you routinely follow best practices as found in the various developer documents for Debian (URL:http://www.debian.org/doc/#righthalfcol or the corresponding document packages installed to your system), then you will commonly find that your package needs no special changes even when there is a new Policy version released. My ‘debian/changelog’ entries frequently have items like: * Conform to ‘Standards-Version: 3.8.3’. No additional changes needed. This allows readers (including those involved in getting the package into the official archive) to know that I'm aware of the new Policy version, that I assert the package conforms with it, and exactly what changes were needed to bring the package into conformance. -- \ “[T]he speed of response of the internet will re-introduce us | `\to that from which our political systems have separated us for | _o__)so long, the consequences of our own actions.” —Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
presumable last policy change before releasing Squeeze?
Hi, what's the earliest event or point in time after which event/point but before Squeeze shipping as stable the policy won't be changed anymore but I as a sponsored maintainer will still be able to upload (ask my sponsor Paul Wise to upload) my lbzip2 package? I'd like to update the package to the (then) current policy version at that point. Thanks, lacos -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
ERSEK Laszlo la...@caesar.elte.hu writes: what's the earliest event or point in time after which event/point but before Squeeze shipping as stable the policy won't be changed anymore but I as a sponsored maintainer will still be able to upload (ask my sponsor Paul Wise to upload) my lbzip2 package? I'd like to update the package to the (then) current policy version at that point. What's your motivation for this? It's not a problem if packages included in a Debian release are conformant with a slightly outdated version of Policy. I don't see that as a good reason for delaying the upload of an otherwise-ready release of your package. -- \ “If we don't believe in freedom of expression for people we | `\ despise, we don't believe in it at all.” —Noam Chomsky, | _o__) 1992-11-25 | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Sun, 4 Oct 2009, Ben Finney wrote: It's not a problem if packages included in a Debian release are conformant with a slightly outdated version of Policy. I don't see that as a good reason for delaying the upload of an otherwise-ready release of your package. -q: - I don't have anything to upload yet, - when I will, it won't really affect end users, - I like a fresh Standards-Version, - I'd like to work on the package in a single focussed session. -v -v -v: The version in Squeeze (0.15-1) corresponds to the current upstream version, so there's no new Debian package to release as of now. 0.15-1 conforms to Policy version 3.8.1, supposedly not very far behind 3.8.3.0. Although as upstream I consider the utility finished, I expect a small change in the documentation. (It depends on external stuff, so I can't do it just yet.) Once I cover that, I'd like to merge it into the Debian package, also updating the packaging itself to newest guidelines. This is tedious and doesn't bring anything to users, so instead of rushing it and possibly making several Policy rounds until Squeeze ships, I'd like to concentrate it into one session/upload. In this case package tidyness through less work is more important to me than package availability, since it won't bring anything to users, just keep my stuff neat. Are you saying that I should update the package as soon as said external stuff allows, and go with the then-current Policy version into Sqeeze, leaving my sponsor and the build network more time as well? Thanks, lacos -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Sun, Oct 04, 2009 at 01:34:12AM +0200, ERSEK Laszlo wrote: - I like a fresh Standards-Version, This is not a valid reason to make an upload to Debian. It is perfectly permissible to have a package with an outdated standards version, especially if the updates to policy do not apply to your package (which is the case in 99% of packages for a given change to policy, in my experience). - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Sat, Oct 3, 2009 at 6:55 PM, ERSEK Laszlo la...@caesar.elte.hu wrote: what's the earliest event or point in time after which event/point but before Squeeze shipping as stable the policy won't be changed anymore but I as a sponsored maintainer will still be able to upload (ask my sponsor Paul Wise to upload) my lbzip2 package? I'd like to update the package to the (then) current policy version at that point. Since the freeze date for squeeze hasn't yet been set, there is no way of knowing which version of policy will be current for squeeze. Usually the release team uses a mass freeze exception to allow anything uploaded to unstable before the freeze into testing regardless of the usual 10 days of waiting before testing migration. So as long as it is uploaded before the freeze date you should be fine. Most Standards-Version updates are of the form Bump Standards-Version, no changes needed and such updates should not be done unless they accompany some other update like fixing bugs or adding a new upstream version. Anyway, here are some ideas about what you could do to improve lbzip2: Write an article for debaday.debian.net about lbzip2 to promote it and get more users/testers. Have the package description and manual page reviewed by the Smith Review Project: http://wiki.debian.org/I18n/SmithReviewProject Take a look at the FreeBSD port and see if the Makefile patch is appropriate to include upstream or if not, contact the port maintainer about it. Document in the manual page or README the TAR_OPTIONS environment variable and how to make tar use lbzip2 by default. Talk to the upstream tar maintainers about ways to make tar detect if lbzip2 is available and use it instead of bzip2. Work on the bugs mentioned in the manual page if appropriate. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
