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 t
ERSEK Laszlo 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 t
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
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 pa
On Sat, Oct 3, 2009 at 6:55 PM, ERSEK Laszlo 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
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
ERSEK Laszlo 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
* ERSEK Laszlo [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 grateful
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/SmithReviewProjec
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="$(CFL
* ERSEK Laszlo [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 changi
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'
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. Comm
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 tr
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
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 yo
16 matches
Mail list logo
