[Attn Maintainer] stow

[Attn Maintainer] stow

[Achim Gratz]

The update to Perl 5.22 is planned for the end of this week.  Please
notify immediately if you cannot provide the updated packages indicated
below by then to your package upload area on cygwin.com.

Your following packages contain sub-packages that need an update or
re-release using Perl version 5.22:

stow	(perl-stow)


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

Re: [Attn Maintainer] stow

[Andrew Schulman]

> The update to Perl 5.22 is planned for the end of this week.  Please
> notify immediately if you cannot provide the updated packages indicated
> below by then to your package upload area on cygwin.com.
> 
> Your following packages contain sub-packages that need an update or
> re-release using Perl version 5.22:
> 
> stow	(perl-stow)

Hi Achim.  Sure, I'm happy to do it.  But can you please explain in more detail
what you're looking for?

ATM when I build perl-Stow, the files go into /usr/lib/perl5/vendor_perl/5.14.
If I understand right, you're asking me to provide an updated package where the
files will go into /usr/lib/perl5/vendor_perl/5.22 instead.  Correct?

Leave aside that it seems brain-dead that I should have to rebuild my package
for such a triviality.  Wouldn't it be nice if I could put the files into, say,
/usr/lib/perl5/vendor_perl, and not have to rebuild my package every time
there's a new point release of Perl?

But okay, I'll rebuild it.  So are you asking me to first wait until Perl 5.22
comes out, then rebuild the package and release it afterwards?  Or to manually
change where the files go, and release the update at the same time as Perl 5.22?

And doesn't this mean that perl-Stow-2.2.0-3 should be made to depend explicitly
on perl version 5.22?  Which upset doesn't currently support, IIRC.

I mean, seriously, this seems like a lot of dumb work to me.

Not that I blame you for that.  On the contrary, I greatly appreciate your work
as the Perl maintainer.  I'm just trying to figure out how to make it work with
the least amount of pain.

Thanks,
Andrew

Re: [Attn Maintainer] stow

[Achim Gratz]

Andrew Schulman writes:
> ATM when I build perl-Stow, the files go into /usr/lib/perl5/vendor_perl/5.14.
> If I understand right, you're asking me to provide an updated package where the
> files will go into /usr/lib/perl5/vendor_perl/5.22 instead.  Correct?

Yes.  It will automatically do that when you build it again with Perl 5.22.

> Leave aside that it seems brain-dead that I should have to rebuild my package
> for such a triviality.  Wouldn't it be nice if I could put the files into, say,
> /usr/lib/perl5/vendor_perl, and not have to rebuild my package every time
> there's a new point release of Perl?

The thing here is that we're making quite a jump from 5.14 to 5.22 (four
major upstream releases) with a bunch of user-visible changes and while
it would have been possible to make 5.22 look modules up in the 5.14
directories and it would generally work, there were too many changes for
_all_ of that to work correctly and some of these errors would likely
have been quite non-obvious.  So I decided that things must be rebuilt
with 5.22 for this update specifically.

> But okay, I'll rebuild it.  So are you asking me to first wait until Perl 5.22
> comes out, then rebuild the package and release it afterwards?  Or to manually
> change where the files go, and release the update at the same time as Perl 5.22?

The idea was that you install the pre-release Perl that was published
specifically to facilitate this rebuild.

> And doesn't this mean that perl-Stow-2.2.0-3 should be made to depend explicitly
> on perl version 5.22?  Which upset doesn't currently support, IIRC.

To be honest, I've been thinking about making a perl522 instead of just
a perl package, but that looked even less appealing, given that the next
few updates of Perl quite likely don't require such jumping through
hoops.

> I mean, seriously, this seems like a lot of dumb work to me.

Sorry.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [Attn Maintainer] stow

[Andrew Schulman]

> > I mean, seriously, this seems like a lot of dumb work to me.
> 
> Sorry.

OK.  Again, not your fault and thanks for maintaining.  Andrew

Re: [Attn Maintainer] stow

[Andrew Schulman]

> > But okay, I'll rebuild it.  So are you asking me to first wait until Perl 5.22
> > comes out, then rebuild the package and release it afterwards?  Or to manually
> > change where the files go, and release the update at the same time as Perl 5.22?
> 
> The idea was that you install the pre-release Perl that was published
> specifically to facilitate this rebuild.

Sorry, where is that?  I looked in setup, and the newest test version there
is 5.14.4-3.

Re: [Attn Maintainer] stow

[Achim Gratz]

Andrew Schulman writes:
>> The idea was that you install the pre-release Perl that was published
>> specifically to facilitate this rebuild.
>
> Sorry, where is that?  I looked in setup, and the newest test version there
> is 5.14.4-3.

From the thread on the Perl update:

--8<---------------cut here---------------start------------->8---
I have rebuilt Perl 5.22.0 and all distributions including some updates
in the last month with the updated toolchain.  I've uploaded the files
to my server if you want to test, please point setup at:

setup-{x86,x86_64}.exe -XOs http://cygwin.stromeko.net/

Again, since the release numbers haven't been bumped, it's easiest to
cheat on setup to get it to re-install everything Perl:

sed -re 's/( perl-.*-)[0-9]+\./\10./' -i.bak /etc/setup/installed.db
--8<---------------cut here---------------end--------------->8---



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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [Attn Maintainer] stow

[Andrew Schulman]

> Andrew Schulman writes:
> >> The idea was that you install the pre-release Perl that was published
> >> specifically to facilitate this rebuild.
> >
> > Sorry, where is that?  I looked in setup, and the newest test version there
> > is 5.14.4-3.
> 
> From the thread on the Perl update:

OK.  I missed that thread.  For the next time there's a Perl update that
requires action from us maintainers, it would help if you put a HEADSUP in
the subject line.  Thanks, Andrew.

Re: [Attn Maintainer] stow

[Andrew Schulman]

> The update to Perl 5.22 is planned for the end of this week.  Please
> notify immediately if you cannot provide the updated packages indicated
> below by then to your package upload area on cygwin.com.
> 
> Your following packages contain sub-packages that need an update or
> re-release using Perl version 5.22:
> 
> stow	(perl-stow)

OK, I've rebuilt and uploaded stow and perl-Stow, and created

/x86/release/stow/!perl
/x86_64/release/stow/!perl

Re: [Attn Maintainer] stow

[Achim Gratz]

Andrew Schulman writes:
> OK, I've rebuilt and uploaded stow and perl-Stow, and created
>
> /x86/release/stow/!perl
> /x86_64/release/stow/!perl

Thanks.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [Attn Maintainer] stow

[Achim Gratz]

Andrew Schulman writes:
> OK.  I missed that thread.  For the next time there's a Perl update that
> requires action from us maintainers, it would help if you put a HEADSUP in
> the subject line.

I've realized just in time that some maintainers don't read all of the
cygwin-apps list or even filter it.  I'm not sure what's the right thing
to do, but calling out individual maintainers, trying to contact them on
their private emails or stuffing keywords into the subject to me goes
against the spirit of having this mailing list.


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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [Attn Maintainer] stow

[Andrew Schulman]

> Andrew Schulman writes:
> > OK.  I missed that thread.  For the next time there's a Perl update that
> > requires action from us maintainers, it would help if you put a HEADSUP in
> > the subject line.
> 
> I've realized just in time that some maintainers don't read all of the
> cygwin-apps list or even filter it.  I'm not sure what's the right thing
> to do, but calling out individual maintainers, trying to contact them on
> their private emails or stuffing keywords into the subject to me goes
> against the spirit of having this mailing list.

I read cygwin-apps regularly, but I don't read every thread.  I scan the subject
lines, and read the threads that seem important.  The thread about a Perl update
didn't catch my attention.

I have a filter set up to flag messages with HEADSUP in the subject line as
important.  So I always read those.  Other maintainers are probably filtering on
HEADSUP in a similar way.

I agree that you shouldn't have to track down maintainers individually.  You
should be able to just write to the list.  But it's also not realistic to expect
everyone to read every thread.  Putting HEADSUP in the subject line seems to me
like a good way of telling people that they need to read this.

Andrew

Re: [Attn Maintainer] stow

[Achim Gratz]

Andrew Schulman writes:
> I have a filter set up to flag messages with HEADSUP in the subject line as
> important.  So I always read those.  Other maintainers are probably filtering on
> HEADSUP in a similar way.

I wasn't aware that this was an agreed-upon keyword and I can't find
where it is documented, but I think it should be.


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: [Attn Maintainer] stow

[Ken Brown]

On 7/31/2015 2:01 PM, Achim Gratz wrote:
> Andrew Schulman writes:
>> I have a filter set up to flag messages with HEADSUP in the subject line as
>> important.  So I always read those.  Other maintainers are probably filtering on
>> HEADSUP in a similar way.
>
> I wasn't aware that this was an agreed-upon keyword and I can't find
> where it is documented, but I think it should be.

I'm not sure it's an agreed-upon keyword, and I'm actually surprised to hear 
that some maintainers are filtering on that word.  As a practical matter, 
however, I think Andrew is probably right that HEADSUP is a good way to get the 
attention of several maintainers at once.  Corinna and Yaakov seem to be the 
main people who use it (e.g., 
https://sourceware.org/ml/cygwin-apps/2015-05/msg00040.html).

Ken

Re: [Attn Maintainer] stow

[Ken Brown]

On 7/31/2015 2:44 PM, Ken Brown wrote:
> On 7/31/2015 2:01 PM, Achim Gratz wrote:
>> Andrew Schulman writes:
>>> I have a filter set up to flag messages with HEADSUP in the subject line as
>>> important.  So I always read those.  Other maintainers are probably filtering on
>>> HEADSUP in a similar way.
>>
>> I wasn't aware that this was an agreed-upon keyword and I can't find
>> where it is documented, but I think it should be.
>
> I'm not sure it's an agreed-upon keyword, and I'm actually surprised to hear
> that some maintainers are filtering on that word.  As a practical matter,
> however, I think Andrew is probably right that HEADSUP is a good way to get the
> attention of several maintainers at once.  Corinna and Yaakov seem to be the
> main people who use it (e.g.,
> https://sourceware.org/ml/cygwin-apps/2015-05/msg00040.html).

None of this discussion should detract from the amazing job you've done in 
pulling this Perl update together.  I hope you get several gold stars and/or 
plush hippos for all your work.

Ken

perl vendorlib, sitelib (was: stow)

[Yaakov Selkowitz]

On Mon, 2015-07-27 at 18:13 -0400, Andrew Schulman wrote:
> Leave aside that it seems brain-dead that I should have to rebuild my package
> for such a triviality.  Wouldn't it be nice if I could put the files into, say,
> /usr/lib/perl5/vendor_perl, and not have to rebuild my package every time
> there's a new point release of Perl?

This is a good point; pure Perl modules should not need to be rebuilt
for every new Perl version.

It's too late for 5.22, but for 5.24 could we change this to:

prefix=/usr
privlib=/usr/share/perl5/${VERSION%.*}
archlib=/usr/lib/perl5/${VERSION%.*}
vendorprefix=/usr
vendorlib=/usr/share/perl5/vendor_perl
vendorarch=/usr/lib/perl5/vendor_perl/${VERSION%.*}
siteprefix=/usr/local
sitelib=/usr/local/share/perl5/site_perl
sitearch=/usr/local/lib/perl5/site_perl/${VERSION%.*}

Besides being better compliant with FHS, this would help avoid
unnecessary rebuilds with upgrades post-5.24.  A similar change that I
made to ruby for 2.0 saved me a LOT of time when upgrading to 2.2.

--
Yaakov

Re: perl vendorlib, sitelib

[Achim Gratz]

Yaakov Selkowitz writes:
> This is a good point; pure Perl modules should not need to be rebuilt
> for every new Perl version.

As I've explained before, the impetus to rebuild even those is coming
from the large jump we're making with Perl for just this update, which
rolls up several user-visible and sometimes backwards-incompatible
changes, some of which have already completed the obsoletion cycle
between those versions and do not get warned about anymore.

> It's too late for 5.22, but for 5.24 could we change this to:

The next update will be 5.22.1 around September.

> prefix=/usr
> privlib=/usr/share/perl5/${VERSION%.*}

Why move that to /usr/share?

> archlib=/usr/lib/perl5/${VERSION%.*}
> vendorprefix=/usr
> vendorlib=/usr/share/perl5/vendor_perl
> vendorarch=/usr/lib/perl5/vendor_perl/${VERSION%.*}

That's not what openSUSE is doing, I haven't checked other Linux
distributions.  I don't think it's a particularly good idea to conceal
which version of Perl the packaging was done with, since that's the only
way to inform any rebuild decisions for packages that haven't been
updated n a while.  If we want to enable backwards compatibility we can
explicitly add the previous version of Perl to @INC like before; but as
said above I explicitly didn't want to do that for this update.

> siteprefix=/usr/local
> sitelib=/usr/local/share/perl5/site_perl
> sitearch=/usr/local/lib/perl5/site_perl/${VERSION%.*}

I see no problem moving site_perl to /usr/local, but I don't understand
what this is supposed to solve w.r.t. to packages using Perl modules.

> Besides being better compliant with FHS, this would help avoid
> unnecessary rebuilds with upgrades post-5.24.  A similar change that I
> made to ruby for 2.0 saved me a LOT of time when upgrading to 2.2.

See above.  Depending on what, if any backwards incompatible changes are
made between 5.22 and 5.24, the previous version (5.22) will be kept in
@INC.  That means no immediate rebuilds will be necessary for that
update.


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

Re: [Attn Maintainer] stow

[Andrew Schulman]

> None of this discussion should detract from the amazing job you've done in 
> pulling this Perl update together.  I hope you get several gold stars and/or 
> plush hippos for all your work.

Awarded! http://cygwin.com/goldstars/#AG

Re: [Attn Maintainer] stow

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

On Jul 31 17:30, Andrew Schulman wrote:
> > None of this discussion should detract from the amazing job you've done in 
> > pulling this Perl update together.  I hope you get several gold stars and/or 
> > plush hippos for all your work.
> 
> Awarded! http://cygwin.com/goldstars/#AG

I guess I should more often just disappear for a few days... :)

Thanks to all of you.  Thanks to Achim for pulling this through, thanks
to Ken for pointing this out, thanks to Andrew for having the awards
ready when they are most needed, and thanks to you other maintainers
providing the required new packages.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]