Ken Brown writes:
> What about just using a variable (say PKG_TEST) in the cygport
> file. For example, the line
>
> PKG_TEST=1
>
> would cause the 'test:' line to be added to the hint files.
That was booed down by Jon (and Yaakov earlier). It's become clear that
everyone does their packaging
On 4/8/2017 1:00 PM, Achim Gratz wrote:
Jon Turney writes:
cygport will be updated to (details TBC) accept a --test flag which is
significant to the cygport package stage, and adds this 'test:' line
to all the generated PVR.hint files.
I've opted to make it a command (package-test or
Jon Turney writes:
> cygport will be updated to (details TBC) accept a --test flag which is
> significant to the cygport package stage, and adds this 'test:' line
> to all the generated PVR.hint files.
I've opted to make it a command (package-test or pkg-test) instead, as
that seems to fall more
On 09/12/2016 11:10, Corinna Vinschen wrote:
On Dec 9 11:46, Corinna Vinschen wrote:
I don't think this is feasible. The maintainer should have control
over the promotion from test to curr. I'm not affected by this since
I generate new versions as soon as I promote, so this is more
On Dec 9 11:46, Corinna Vinschen wrote:
> I don't think this is feasible. The maintainer should have control
> over the promotion from test to curr. I'm not affected by this since
> I generate new versions as soon as I promote, so this is more maintainers
> like JonY, for whom a rebuild and
On 30/08/2016 13:24, Jon Turney wrote:
On 20/06/2016 16:28, Jon Turney wrote:
Currently, the setup.hint file is shared between all versions.
This means that manual intervention (by the package maintainer, or on
sourceware) is needed when versions have different dependencies.
To automate this
On 06/20/2016 10:28 AM, Jon Turney wrote:
>
> Currently, the setup.hint file is shared between all versions.
>
> This means that manual intervention (by the package maintainer, or on
> sourceware) is needed when versions have different dependencies.
>
> To automate this problem out of
On 19/09/2016 19:24, Achim Gratz wrote:
The attached patch attempts to extract two paragraphs from this for
the web page.
Thank you, Ken.
Great, thanks. I applied this.
> The attached patch attempts to extract two paragraphs from this for
> the web page.
Thank you, Ken.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
On 9/18/2016 12:28 PM, Achim Gratz wrote:
Achim Gratz writes:
Jon Turney writes:
I notice the section about postinstall scripts doesn't mention
permanent postinsall scripts at all.
Could you possibly provide a couple of paragraphs?
I had sent them to this very list at the time. I need to
On 18/09/2016 19:16, Achim Gratz wrote:
Marco Atzeri writes:
I suggest to remove the requirements.
The main list have in automatic:
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Marco Atzeri writes:
> I suggest to remove the requirements.
>
> The main list have in automatic:
>
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:
On 18/09/2016 18:41, Ken Brown wrote:
Another thing: The page still says that all release announcements should
contain information about unsubscribing from the cygwin-announce mailing
list. But it seems that many (most?) maintainers have stopped doing
this. And 'cygport announce' doesn't do
On 9/18/2016 11:14 AM, Jon Turney wrote:
On 18/09/2016 06:17, Marco Atzeri wrote:
On 17/09/2016 08:14, Achim Gratz wrote:
Jon Turney writes:
Currently, the setup.hint file is shared between all versions.
This means that manual intervention (by the package maintainer, or on
sourceware) is
Achim Gratz writes:
> Jon Turney writes:
>> I notice the section about postinstall scripts doesn't mention
>> permanent postinsall scripts at all.
>>
>> Could you possibly provide a couple of paragraphs?
>
> I had sent them to this very list at the time. I need to dig them out
> of the archive
Jon Turney writes:
> I notice the section about postinstall scripts doesn't mention
> permanent postinsall scripts at all.
>
> Could you possibly provide a couple of paragraphs?
I had sent them to this very list at the time. I need to dig them out
of the archive unless you're faster.
Regards,
On 18/09/2016 06:17, Marco Atzeri wrote:
On 17/09/2016 08:14, Achim Gratz wrote:
Jon Turney writes:
Currently, the setup.hint file is shared between all versions.
This means that manual intervention (by the package maintainer, or on
sourceware) is needed when versions have different
On 17/09/2016 08:14, Achim Gratz wrote:
Jon Turney writes:
Currently, the setup.hint file is shared between all versions.
This means that manual intervention (by the package maintainer, or on
sourceware) is needed when versions have different dependencies.
To automate this problem out of
Jon Turney writes:
> Currently, the setup.hint file is shared between all versions.
>
> This means that manual intervention (by the package maintainer, or on
> sourceware) is needed when versions have different dependencies.
>
> To automate this problem out of existence, I suggest replacing the
>
On 31/08/2016 20:13, Achim Gratz wrote:
Jon Turney writes:
calm will be changed so that:
* The requires: line written in setup.ini will contain the union of the
requires: from each pvr.hint
* The sdesc:, ldesc:, category: and message: lines in setup.ini will be
taken from the pvr.hint for the
Jon Turney writes:
>> calm will be changed so that:
>>
>> * The requires: line written in setup.ini will contain the union of the
>> requires: from each pvr.hint
>>
>> * The sdesc:, ldesc:, category: and message: lines in setup.ini will be
>> taken from the pvr.hint for the curr version
I've not
On 20/06/2016 16:28, Jon Turney wrote:
Currently, the setup.hint file is shared between all versions.
This means that manual intervention (by the package maintainer, or on
sourceware) is needed when versions have different dependencies.
To automate this problem out of existence, I suggest
On 21/06/2016 13:03, Corinna Vinschen wrote:
On Jun 20 16:28, Jon Turney wrote:
[...]
* 'curr', 'prev' and 'test' don't make sense on a per-version basis. So I
suggest a separate file for these version overrides (versions.hint?)
Ideally we wouldn't need something like "prev" at all since
Eric Blake writes:
> Except when upstream version numbers go backwards. We'd have to adopt
> something like Fedora's "epoch" numbering if we want our version numbers
> to always be increasing (by bumping the epoch any time upstream versions
> go backwards).
Oh please not. I've looked into this
On 21/06/2016 16:28, Corinna Vinschen wrote:
On Jun 21 15:49, Marco Atzeri wrote:
On 21/06/2016 14:03, Corinna Vinschen wrote:
On Jun 20 16:28, Jon Turney wrote:
Ideally we wouldn't need something like "prev" at all since the version
number itself is sufficient to specify what's curr
On Jun 21 15:49, Marco Atzeri wrote:
>
> On 21/06/2016 14:03, Corinna Vinschen wrote:
> > On Jun 20 16:28, Jon Turney wrote:
> > >
> > > Currently, the setup.hint file is shared between all versions.
> > >
> > > This means that manual intervention (by the package maintainer, or on
> > >
On Jun 21 08:08, Eric Blake wrote:
> On 06/21/2016 06:03 AM, Corinna Vinschen wrote:
>
> >> * 'curr', 'prev' and 'test' don't make sense on a per-version basis. So I
> >> suggest a separate file for these version overrides (versions.hint?)
> >
> > Ideally we wouldn't need something like "prev"
On 06/21/2016 06:03 AM, Corinna Vinschen wrote:
>> * 'curr', 'prev' and 'test' don't make sense on a per-version basis. So I
>> suggest a separate file for these version overrides (versions.hint?)
>
> Ideally we wouldn't need something like "prev" at all since the version
> number itself is
On 21/06/2016 14:03, Corinna Vinschen wrote:
On Jun 20 16:28, Jon Turney wrote:
Currently, the setup.hint file is shared between all versions.
This means that manual intervention (by the package maintainer, or on
sourceware) is needed when versions have different dependencies.
To automate
On Jun 20 16:28, Jon Turney wrote:
>
> Currently, the setup.hint file is shared between all versions.
>
> This means that manual intervention (by the package maintainer, or on
> sourceware) is needed when versions have different dependencies.
>
> To automate this problem out of existence, I
Currently, the setup.hint file is shared between all versions.
This means that manual intervention (by the package maintainer, or on
sourceware) is needed when versions have different dependencies.
To automate this problem out of existence, I suggest replacing the
setup.hint file in an
31 matches
Mail list logo
