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 i
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 pkg-test)
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 i
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 maintainer
On 09/12/2016 10:46, Corinna Vinschen wrote:
On Dec 8 19:30, Jon Turney wrote:
On 30/08/2016 13:24, Jon Turney wrote:
(Note to self: why isn't this control labelled 'test', which is an actual
english word???)
Note to jturney, change it, don't be shy.
Patch sent :)
Versions marked as test
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 reup
On Dec 8 19:30, Jon Turney wrote:
> On 30/08/2016 13:24, Jon Turney wrote:
> > This file is called override.hint.
>
> While not a great deal of use is made of test versions, this mechanism
> doesn't seem to be working well for that, and there have been several
> requests to improve it.
>
> There
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 p
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 existence,
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 di
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
Unsubscrib
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: http://cygwin.co
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 i
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 need
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 unl
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,
A
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 dependenci
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 exist
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
> s
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 g
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 repla
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 the
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 a
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 an
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
> > > sourcewa
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" a
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 suff
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 th
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 sugg
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 uploa
33 matches
Mail list logo
