William G. Scott wrote:
> Hi Citizens:
>
> A number of packages, including fftw, depend on gcc43 instead of
> gcc44, which leads to the rather time-consuming and blood-pressure-
> elevating phenomenon of having not one but two interminable builds for
> packages that depend on fftw and gcc44.
I have a best practices question: if all I'm doing is updating the name
of the maintainer and some usage notes, should I bump the revision number?
thanks,
Robert
--
Enter the BlackBerry Developer Challenge
This is your
On 17-Jul-09, at 01:17 , William G. Scott wrote:
> Hi Citizens:
>
> A number of packages, including fftw, depend on gcc43 instead of
> gcc44, which leads to the rather time-consuming and blood-pressure-
> elevating phenomenon of having not one but two interminable builds for
> packages that depen
Chupacerveza wrote:
> I have a best practices question: if all I'm doing is updating the name
> of the maintainer and some usage notes, should I bump the revision number?
> thanks,
Yes. Anything that changes the contents of the *.deb file needs a new rev.
--
Martin
Okay, thanks Martin! --robert
Martin Costabel wrote:
> Chupacerveza wrote:
>> I have a best practices question: if all I'm doing is updating the
>> name of the maintainer and some usage notes, should I bump the
>> revision number?
>> thanks,
>
> Yes. Anything that changes the contents of the *
On 17/07/2009, at 09:37, Martin Costabel wrote:
> Chupacerveza wrote:
>> I have a best practices question: if all I'm doing is updating the
>> name
>> of the maintainer and some usage notes, should I bump the revision
>> number?
>> thanks,
>
> Yes. Anything that changes the contents of the *.d
This is good to know! Thanks!
monipol wrote:
> On 17/07/2009, at 09:37, Martin Costabel wrote:
>> Chupacerveza wrote:
>>> I have a best practices question: if all I'm doing is updating the name
>>> of the maintainer and some usage notes, should I bump the revision
>>> number?
>>> thanks,
>>
>> Ye
hmmm, when building in maintainer mode:
... has a preferred Depends on python25-socket, but python25-socket is
an obsolete package.
Now, another user has asked that I upgrade this to use 2.6, but I
wanted to get the quick maintainer change in first and then come back
and make those changes.
I'm
On Fri, Jul 17, 2009 at 12:00:51PM -0500, Chupacerveza wrote:
> hmmm, when building in maintainer mode:
>
> ... has a preferred Depends on python25-socket, but python25-socket is
> an obsolete package.
>
> Now, another user has asked that I upgrade this to use 2.6, but I
> wanted to get the quick
Daniel Macks wrote:
> On Fri, Jul 17, 2009 at 12:00:51PM -0500, Chupacerveza wrote:
>> hmmm, when building in maintainer mode:
>>
>> ... has a preferred Depends on python25-socket, but python25-socket is
>> an obsolete package.
>>
>> Now, another user has asked that I upgrade this to use 2.6, but I
If I'm making no change to the .patch file at this time, must I submit
it anyway with the new .info? I'm inclined to just submit the .info
file, but if this causes problems with the review process then I'll
post both.
Thanks,
Robert
Martin Costabel wrote:
> Chupacerveza wrote:
>
>> I have a best practices question: if all I'm doing is updating the name
>> of the maintainer and some usage notes, should I bump the revision number?
>> thanks,
>>
>
> Yes. Anything that changes the contents of the *.deb file needs a new r
We need to convert over to gcc44 in any case
so that all of the packages can build on x86_64
fink. The only problem child will be pdftk which
is still stuck on gcc42 because of its broken
coding (which mixes java and c++ exceptions that
is now forbidden in gcc 4.3 and later).
Jack
13 matches
Mail list logo
