Re: [PATCH cygport] Add a command to make a test release

[Yaakov Selkowitz]

On 2017-10-03 14:51, Jon Turney wrote:
> This patch (originally by Achim Gratz) adds a mechanism for generating
> packages marked as 'test' as described in [1].
> 
> I'm not committed to any of the details, but I would like to get
> something with this functionality in, so tell me how you'd like it
> implemented and I'll do it...

https://github.com/cygwinports/cygport/commit/515fc7caa1ccfd8ce3e67deeb6667be481f56e42

Please test.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

Re: [PATCH cygport] Add a command to make a test release

[Andrew Schulman]

> Andrew Schulman writes:
> > Ooh, how about this:
> >
> >   cygport lftp.cygport all
> >   cygport lftp.cygport override curr=4.7.7-1 test=4.7.8-1
> >   cygport lftp.cygport up
> >
> > That would create override.hint and upload it with the package, leaving the
> > cygport file and source package alone.
> 
> The command line parsing in cygport would become a lot more complicated
> for starters, so the syntax should be different.
> 
> But more to the point, some people want to do this on the command line,
> while others do not.  I for one don't want to do it from the command
> line because I have oodles of packages that I build semi-automatically
> and changing the commands issued for each individual package just
> doesn't work well for me.  So I do want this to be part of the file set
> I commit to my Git repository instead (yes, if forced I could wrap
> another layer of scripting or cygport patches around it).  In other
> words, in the end we likely need to have both.

That's fine.

> A separate issue is if those things should end up in the package
> archives.  I agree that often they should not, so again my suggestion is
> to record this simply in a separate file that does not get packaged and
> (as outlined above) to provide means to create the same effects from the
> command line.

Agree. The idea is that cygport can create override.hint, or the packager can
create it. Then cygport uploads it along with the package files. But it's a
separate file, not part of the package archive.

Re: [PATCH cygport] Add a command to make a test release

[Achim Gratz]

Andrew Schulman writes:
> Ooh, how about this:
>
>   cygport lftp.cygport all
>   cygport lftp.cygport override curr=4.7.7-1 test=4.7.8-1
>   cygport lftp.cygport up
>
> That would create override.hint and upload it with the package, leaving the
> cygport file and source package alone.

The command line parsing in cygport would become a lot more complicated
for starters, so the syntax should be different.

But more to the point, some people want to do this on the command line,
while others do not.  I for one don't want to do it from the command
line because I have oodles of packages that I build semi-automatically
and changing the commands issued for each individual package just
doesn't work well for me.  So I do want this to be part of the file set
I commit to my Git repository instead (yes, if forced I could wrap
another layer of scripting or cygport patches around it).  In other
words, in the end we likely need to have both.

A separate issue is if those things should end up in the package
archives.  I agree that often they should not, so again my suggestion is
to record this simply in a separate file that does not get packaged and
(as outlined above) to provide means to create the same effects from the
command line.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [PATCH cygport] Add a command to make a test release

[Andrew Schulman]

> On 10/5/2017 10:23 AM, Andrew Schulman wrote:
> > Sometimes more complicated situations come up. We have one with lftp right 
> > now:
> > 
> > prev: 4.7.7-1
> > curr: 4.8.0-1
> > test: 4.7.8-1
> > 
> > This happened because 4.8.0-1 turns out to be broken, and later versions 
> > won't
> > build in Cygwin yet. So I had to promote 4.7.8-1 to test.
> 
> I didn't pay close attention to the lftp bug reports, so what I'm saying 
> may be nonsense.  But wouldn't it make more sense to just remove 4.8.0-1 
> if it's broken? 

Maybe. It was partly broken.

> You could still make 4.7.8-1 a test version, leaving a 
> working 4.7.7-1 as current.
> 
> Doing it this way, you wouldn't need anything but the ability to mark a 
> release as "test".

No, it also requires the ability to remove 4.8.0-1. To do that I have to
either ask for help here, or upload an override.hint file with

curr: 4.7.7-1
test: 4.7.8-1

or

prev: 4.7.7-1
curr: 4.7.8-1

So it'd be nice if cygport could do that for me.

Obviously this is an unusual case, but every now and then for one reason or
another I need to upload an override.hint file. Any time I do that, it'd be
nice if cygport handled the details for me.

Ooh, how about this:

  cygport lftp.cygport all
  cygport lftp.cygport override curr=4.7.7-1 test=4.7.8-1
  cygport lftp.cygport up

That would create override.hint and upload it with the package, leaving the
cygport file and source package alone.

Andrew

Re: [PATCH cygport] Add a command to make a test release

[cyg Simple]

On 10/5/2017 2:16 PM, Achim Gratz wrote:
> Andrew Schulman writes:
>> This happened because 4.8.0-1 turns out to be broken, and later versions 
>> won't
>> build in Cygwin yet. So I had to promote 4.7.8-1 to test. Assuming it's okay,
>> shortly I want to promote it to current and dump 4.8.0-1, leaving
>>
>> prev: 4.7.7-1
>> curr: 4.7.8-1
> 
> Again, that won't automatically install 4.7.8 for anyone who already
> upgraded to 4.8.0 (unless the --force-current switch is given).
> 

This won't solve the current issue but shouldn't --force-current be the
default?  Maybe could be suggested in the hint file with another line
similar to:

force_curr: true

or

force: 4.7.8-1

-- 
cyg Simple

Re: [PATCH cygport] Add a command to make a test release

[Achim Gratz]

Andrew Schulman writes:
> This happened because 4.8.0-1 turns out to be broken, and later versions won't
> build in Cygwin yet. So I had to promote 4.7.8-1 to test. Assuming it's okay,
> shortly I want to promote it to current and dump 4.8.0-1, leaving
>
> prev: 4.7.7-1
> curr: 4.7.8-1

Again, that won't automatically install 4.7.8 for anyone who already
upgraded to 4.8.0 (unless the --force-current switch is given).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [PATCH cygport] Add a command to make a test release

[Achim Gratz]

Jon Turney writes:
> I'm not keen on the idea of including this transient information into
> the cygport, and thus baking it into the source package.

Fair enough.  If that's the only thing that bothers you, this
information could easily live in some extra file that doesn't get
packaged.  Deal?

> However, I also want to make package maintainers lives easier.  So,
> I'm all for automation to make things less tedious and error-prone,
> which this patch attempts to do.

I plan to modify the patch for test versions so that it automatically
produces one if the release starts with "0".  Thoughts?

> * I'm going to remove the restriction that you can only have 3
> versions. (I keep on putting this off only because it will break
> parsing setup.ini for setup prior to 2.877)

HOw about for after we roll in libsolv and move to setup-3.x?

> * (This also means that more than one test: version may be available)

That seems awkward to handle.

> * Changing curr: doesn't cause setup to downgrade (since 2.864)
> (unless --force-current is used, since 2.874)

We need to eventually solve that problem in a different way, I think.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [PATCH cygport] Add a command to make a test release

[Ken Brown]

On 10/5/2017 10:23 AM, Andrew Schulman wrote:

Sometimes more complicated situations come up. We have one with lftp right now:

prev: 4.7.7-1
curr: 4.8.0-1
test: 4.7.8-1

This happened because 4.8.0-1 turns out to be broken, and later versions won't
build in Cygwin yet. So I had to promote 4.7.8-1 to test.


I didn't pay close attention to the lftp bug reports, so what I'm saying 
may be nonsense.  But wouldn't it make more sense to just remove 4.8.0-1 
if it's broken?  You could still make 4.7.8-1 a test version, leaving a 
working 4.7.7-1 as current.


Doing it this way, you wouldn't need anything but the ability to mark a 
release as "test".


Ken

Re: [PATCH cygport] Add a command to make a test release

[Andrew Schulman]

> On 03/10/2017 21:01, Andrew Schulman wrote:
> >> This patch (originally by Achim Gratz) adds a mechanism for generating
> >> packages marked as 'test' as described in [1].
> >>
> >> I'm not committed to any of the details, but I would like to get
> >> something with this functionality in, so tell me how you'd like it
> >> implemented and I'll do it...
> >>
> >> [1] https://cygwin.com/ml/cygwin-apps/2016-12/msg5.html
> > 
> > Cygport needs a way to specify which versions are prev, curr, and test in
> > cygport files. David Rothenberger and I each proposed a method [1,2]. It
> > doesn't matter much to me which method is picked, but it's definitely a
> > missing feature.
> 
> I'm not keen on the idea of including this transient information into 
> the cygport, and thus baking it into the source package.
> 
> However, I also want to make package maintainers lives easier.  So, I'm 
> all for automation to make things less tedious and error-prone, which 
> this patch attempts to do.
> 
> A few points to consider:
> 
> * I'm going to remove the restriction that you can only have 3 versions. 
> (I keep on putting this off only because it will break parsing setup.ini 
> for setup prior to 2.877)
> 
> * (This also means that more than one test: version may be available)
> 
> * Changing curr: doesn't cause setup to downgrade (since 2.864) (unless 
> --force-current is used, since 2.874)
> 
> * prev: isn't a very significant label, since the only way to install 
> that version is by manually selecting it, i.e. all it means is "keep 
> this version around"
> 
> Taking a step back, as a package maintainer, what do you need to 
> control?  What features do we need here?

Thanks. 

Most commonly, I just want to make a version test, which this patch allows.

Sometimes more complicated situations come up. We have one with lftp right now:

prev: 4.7.7-1
curr: 4.8.0-1
test: 4.7.8-1

This happened because 4.8.0-1 turns out to be broken, and later versions won't
build in Cygwin yet. So I had to promote 4.7.8-1 to test. Assuming it's okay,
shortly I want to promote it to current and dump 4.8.0-1, leaving

prev: 4.7.7-1
curr: 4.7.8-1

I can do this by creating an override.hint file, but right now I have to upload
that manually. It'd be nice if I could tell cygport to handle it, in whatever
way is best.

I think it's fine to put the prev, curr, and test instructions in the cygport
file, and have it create and upload the override.hint. cygport files already
have version information in them (VERSION, RELEASE). 

But if you don't like that, we could ask maintainers to create override.hint
files separately, and just have cygport recognize and upload those. That's fine
too, as long as there's a way to allow different override.hint files by arch,
which is bound to be needed sometimes.

Andrew

Re: [PATCH cygport] Add a command to make a test release

[Jon Turney]

On 03/10/2017 21:01, Andrew Schulman wrote:

This patch (originally by Achim Gratz) adds a mechanism for generating
packages marked as 'test' as described in [1].

I'm not committed to any of the details, but I would like to get
something with this functionality in, so tell me how you'd like it
implemented and I'll do it...

[1] https://cygwin.com/ml/cygwin-apps/2016-12/msg5.html


Cygport needs a way to specify which versions are prev, curr, and test in
cygport files. David Rothenberger and I each proposed a method [1,2]. It
doesn't matter much to me which method is picked, but it's definitely a
missing feature.


I'm not keen on the idea of including this transient information into 
the cygport, and thus baking it into the source package.


However, I also want to make package maintainers lives easier.  So, I'm 
all for automation to make things less tedious and error-prone, which 
this patch attempts to do.


A few points to consider:

* I'm going to remove the restriction that you can only have 3 versions. 
(I keep on putting this off only because it will break parsing setup.ini 
for setup prior to 2.877)


* (This also means that more than one test: version may be available)

* Changing curr: doesn't cause setup to downgrade (since 2.864) (unless 
--force-current is used, since 2.874)


* prev: isn't a very significant label, since the only way to install 
that version is by manually selecting it, i.e. all it means is "keep 
this version around"


Taking a step back, as a package maintainer, what do you need to 
control?  What features do we need here?

Re: [PATCH cygport] Add a command to make a test release

[Achim Gratz]

Andrew Schulman writes:
> Cygport needs a way to specify which versions are prev, curr, and test in
> cygport files. David Rothenberger and I each proposed a method [1,2]. It
> doesn't matter much to me which method is picked, but it's definitely a
> missing feature.

My latest iteration on the original patch by David:

http://repo.or.cz/cygport/rpm-style.git/commitdiff/b169fec0a4a14e79a1d07bd0df300ef1f43b92a0


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

[PATCH cygport] Add a command to make a test release

[Jon Turney]

This patch (originally by Achim Gratz) adds a mechanism for generating 
packages marked as 'test' as described in [1].


I'm not committed to any of the details, but I would like to get 
something with this functionality in, so tell me how you'd like it 
implemented and I'll do it...


[1] https://cygwin.com/ml/cygwin-apps/2016-12/msg5.html
From f0e8ed8266da36fcf5ea0b648e91c1be5e793c6b Mon Sep 17 00:00:00 2001
From: Achim Gratz 
Date: Sat, 8 Apr 2017 17:00:34 +0200
Subject: [PATCH cygport] Add a command to make a test release

lib/pkg_pkg.cygpart: inform when creating hint files for a test release.

lib/help.cygport: document command to package test releases.

bin/cygport.in: provide command to package test releases.

v2:
Add test: to all hints
Add to help output

Signed-off-by: Jon Turney 
---
 bin/cygport.in  |  3 +++
 lib/help.cygpart|  1 +
 lib/pkg_pkg.cygpart | 13 +
 3 files changed, 17 insertions(+)

diff --git a/bin/cygport.in b/bin/cygport.in
index 6cf0122..9cf6f46 100644
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -599,6 +599,9 @@ do
__show_web;
_status=$?;
;;
+   package-test|pkg-test)
+   TESTRELEASE=cmdline;
+   ;&
package|pkg)
__stage Packaging;
__log_init ${pkglog};
diff --git a/lib/help.cygpart b/lib/help.cygpart
index 460f8f7..54819a9 100644
--- a/lib/help.cygpart
+++ b/lib/help.cygpart
@@ -46,6 +46,7 @@ __show_help() {
  test run the package's test suite, if one exists
  install  install into a DESTDIR, and run 
post-installation steps
  package  create binary and source packages
+ package-test create binary and source packages, marked as test
  upload   upload finished packages to cygwin.com
  announce send an announcement email to cygwin.com
  finish   delete the working directory
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index cfc0770..c3b47fe 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -665,6 +665,14 @@ __pkg_dist() {
 #  libfoo-devel will use libfoo_devel_OBSOLETES.
 #
 
+   pkg_testrelease=${TESTRELEASE+test:};
+   if [ "test:" = "${pkg_testrelease:-none}" ]
+   then
+   inform "Package hint files are prepared for a 
\e[1;31mtest\e[0;0m release\n"
+   else
+   inform "Package hint files are prepared for a 
\e[1;32mcurrent\e[0;0m release\n"
+   fi
+
n=0;
while defined pkg_name[${n}]
do
@@ -712,6 +720,7 @@ category: ${!pkg_category_var:-${CATEGORY}}
 requires: ${pkg_bin_requires} ${!pkg_requires_var}
 sdesc: "${!pkg_summary_var:-${SUMMARY}}"
 ldesc: 
"${!pkg_description_var:-${DESCRIPTION:-${!pkg_summary_var:-${SUMMARY"
+${pkg_testrelease}
 _EOF
if defined distsubdir
then
@@ -751,6 +760,7 @@ ldesc: "The ${obspkg} package is obsolete.  Selecting this 
package for
 installation will cause the ${pkg_name[${n}]} package, which replaces this
 one, to be installed instead."
 ${obssubdir:+external-source: ${PN}}
+${pkg_testrelease}
 _EOF
done
 
@@ -777,6 +787,7 @@ external-source: ${PN}
 sdesc: "Debug info for ${PN}"
 ldesc: "This package contains files necessary for debugging the
 ${PN} package with gdb."
+${pkg_testrelease}
 _EOF
fi
 
@@ -795,6 +806,7 @@ ldesc: "The ${obspkg} package is obsolete.  Selecting this 
package for
 installation will cause the ${PN}-debuginfo package, which replaces this
 one, to be installed instead."
 external-source: ${PN}
+${pkg_testrelease}
 _EOF
done
fi
@@ -820,6 +832,7 @@ category: ${!pkg_category_var:-${CATEGORY}}
 requires:
 sdesc: "${!pkg_summary_var:-${SUMMARY}}"
 ldesc: 
"${!pkg_description_var:-${DESCRIPTION:-${!pkg_summary_var:-${SUMMARY"
+${pkg_testrelease}
 skip:
 _EOF
else
-- 
2.14.2