Re: PATCH: Hurd FTBFS with perl 5.22

[Svante Signell]

On Wed, 2016-01-06 at 03:25 +0100, Guillem Jover wrote:
> On Tue, 2016-01-05 at 06:56:37 +0100, Svante Signell wrote:
> > 
> $ apt-cache show perl|grep Essential
> Build-Essential: yes
> `---
> > Is there more perl code in upstream Hurd? If not, how about rewrite this
> > code
> > snippet in C and "remove a should be added" a language dependency!

See below.

> That would be pointless, as per above. Not to mention that the
> dpkg-dev tools are all in perl, same as debhelper, and there's no
> intention to rewrite them.

Well, for the GNU GuixSD Guix will essentially build-depend on guile, not perl.
So for upstream removing the perl dependency would not hurt. Of course this
depends on how long libdde is going to be used in the future. It seems like the
Rump kernel is the way forward. (Samuel, how's the sound and USB presentation
progressing for FOSDEM 2016?)

I'm really longing for a GNU distribution of GNU/Hurd, (and GNU/Linux) to
counteract the catastrophic trail the Debian developers are heading, getting
themselves locked in in cooperation with commercial agendas.

Re: PATCH: Hurd FTBFS with perl 5.22

[Samuel Thibault]

Svante Signell, on Wed 06 Jan 2016 10:00:57 +0100, wrote:
> (Samuel, how's the sound and USB presentation progressing for FOSDEM
> 2016?)

Hasn't progressed so far. Way too many other things to do with short
deadlines.

Samuel

Re: PATCH: Hurd FTBFS with perl 5.22

[Svante Signell]

On Wed, 2016-01-06 at 08:34 +0100, Samuel Thibault wrote:
> Guillem Jover, on Wed 06 Jan 2016 03:25:27 +0100, wrote:
> > $ apt-cache show perl-base|grep Essential
> > Essential: yes
> > $ apt-cache show perl|grep Essential
> > Build-Essential: yes
> 
> Ah, I was wondering. I knew that perl was not essential, but didn't know
> perl was build-essential.

Same with me, I did not know perl-base was Build-Essential. I suspected
something like this though. Sorry for the fuzz.

Re: PATCH: Hurd FTBFS with perl 5.22

[Samuel Thibault]

Svante Signell, on Tue 05 Jan 2016 14:49:40 +0100, wrote:
> On 5 Jan 2016 13:27, "Samuel Thibault" <[1]samuel.thiba...@gnu.org> wrote:
> >
> > > Well, the source is from the Hurd package, not netdde. It's in 
> > > hurd_0.7.orig-libdde-linux26.tar.bz2
> >
> > See the file name.
> 
> And since this tarball is part of the hurd source it should depend on perl.
> (that part  you edited away from my mail)

Yes, because that's right. See the commit I've made just after that.

Samuel

Re: PATCH: Hurd FTBFS with perl 5.22

[Svante Signell]

On 5 Jan 2016 13:27, "Samuel Thibault"  wrote:
>
> > Well, the source is from the Hurd package, not netdde. It's in
> > hurd_0.7.orig-libdde-linux26.tar.bz2
>
> See the file name.

And since this tarball is part of the hurd source it should depend on perl.
(that part  you edited away from my mail)

Re: PATCH: Hurd FTBFS with perl 5.22

[Samuel Thibault]

Guillem Jover, on Wed 06 Jan 2016 03:25:27 +0100, wrote:
> $ apt-cache show perl-base|grep Essential
> Essential: yes
> $ apt-cache show perl|grep Essential
> Build-Essential: yes

Ah, I was wondering. I knew that perl was not essential, but didn't know
perl was build-essential.

Anyway, it's pointless to discuss this further.

Samuel

Re: PATCH: Hurd FTBFS with perl 5.22

[Richard Braun]

On Mon, Jan 04, 2016 at 11:09:00PM +0100, Svante Signell wrote:
> On Mon, 2016-01-04 at 22:50 +0100, Samuel Thibault wrote:
> > Svante Signell, on Mon 04 Jan 2016 22:02:02 +0100, wrote:
> > > - @val = @{$canned_values{$hz}};
> > > - if (!defined(@val)) {
> > > - @val = compute_values($hz);
> > > - }
> > > + @val = compute_values($hz);
> > 
> > Don't we want to still try to use canned_values?
> 
> As I wrote in IRC you should solve this, not me. Obviously the !defined(@val) 
> is

Apparently you're too stupid to notice when you lack respect, so we'll
tell you.

Don't.

-- 
Richard Braun

Re: PATCH: Hurd FTBFS with perl 5.22

[Samuel Thibault]

Svante Signell, on Tue 05 Jan 2016 08:30:51 +0100, wrote:
> On Tue, 2016-01-05 at 17:36 +1100, William ML Leslie wrote:
> > On 5 January 2016 at 16:56, Svante Signell  wrote:
> > > BTW: Why does Hurd contain such crappy dependencies such as perl. Is this
> > > part
> > > of upstream or Debian specific? The Debian package does not have it:
> > > apt-cache showsrc hurd | grep Build-Depends | grep -i perl
> > > 
> > > Is there more perl code in upstream Hurd? If not, how about rewrite this
> > > code
> > > snippet in C and "remove a should be added" language dependency!
> > > 
> > 
> > It's used by a ported linux driver as part of libdde, as the path of
> > the patch indicates.
> 
> Well, the source is from the Hurd package, not netdde. It's in 
> hurd_0.7.orig-libdde-linux26.tar.bz2 

See the file name.

Samuel

Re: PATCH: Hurd FTBFS with perl 5.22

[Guillem Jover]

On Tue, 2016-01-05 at 06:56:37 +0100, Svante Signell wrote:
> BTW: Why does Hurd contain such crappy dependencies such as perl.

This comment seems unnecessarily abrasive and out of place…

> Is this part of upstream or Debian specific? The Debian package does not
> have it:

> apt-cache showsrc hurd | grep Build-Depends | grep -i perl
> 

That's because that would be wrong on two accounts:

,---
$ apt-cache show perl-base|grep Essential
Essential: yes
$ apt-cache show perl|grep Essential
Build-Essential: yes
`---

> Is there more perl code in upstream Hurd? If not, how about rewrite this code
> snippet in C and "remove a should be added" a language dependency!

That would be pointless, as per above. Not to mention that the
dpkg-dev tools are all in perl, same as debhelper, and there's no
intention to rewrite them.

Regards,
Guillem

PATCH: Hurd FTBFS with perl 5.22

[Svante Signell]

Hi,

The following patch is sufficient to make Debian GNU/Hurd build again with the
latest perl 5.22.1-1:

Index: hurd-0.7/libdde-linux26/lib/src/kernel/timeconst.pl
===
--- hurd-0.7.orig/libdde-linux26/lib/src/kernel/timeconst.pl
+++ hurd-0.7/libdde-linux26/lib/src/kernel/timeconst.pl
@@ -369,10 +369,7 @@ if ($hz eq '--can') {
    die "Usage: $0 HZ\n";
    }
 
-   @val = @{$canned_values{$hz}};
-   if (!defined(@val)) {
-   @val = compute_values($hz);
-   }
+   @val = compute_values($hz);
    output($hz, @val);
 }
 exit 0;

Re: PATCH: Hurd FTBFS with perl 5.22

[Svante Signell]

On Mon, 2016-01-04 at 22:50 +0100, Samuel Thibault wrote:
> Svante Signell, on Mon 04 Jan 2016 22:02:02 +0100, wrote:
> > -   @val = @{$canned_values{$hz}};
> > -   if (!defined(@val)) {
> > -   @val = compute_values($hz);
> > -   }
> > +   @val = compute_values($hz);
> 
> Don't we want to still try to use canned_values?

As I wrote in IRC you should solve this, not me. Obviously the !defined(@val) is
no longer allowed, and I don't know how to rewrite that condition. The
suggestion when it failed was:
Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at
/.../timeconst.pl line 373.

Re: PATCH: Hurd FTBFS with perl 5.22

[Samuel Thibault]

Svante Signell, on Mon 04 Jan 2016 23:09:00 +0100, wrote:
> On Mon, 2016-01-04 at 22:50 +0100, Samuel Thibault wrote:
> > Svante Signell, on Mon 04 Jan 2016 22:02:02 +0100, wrote:
> > > - @val = @{$canned_values{$hz}};
> > > - if (!defined(@val)) {
> > > - @val = compute_values($hz);
> > > - }
> > > + @val = compute_values($hz);
> > 
> > Don't we want to still try to use canned_values?
> 
> As I wrote in IRC you should solve this, not me.

Me taking the time to solve it means I have less time to solve other
issues. I already took time for the Hurd the other day to track the
difficult pfinet crash we've been having for years. I can't spend all my
free time on the Hurd.

> Obviously the !defined(@val) is
> no longer allowed, and I don't know how to rewrite that condition.

Perhaps juste !@val?
I have no idea, I don't know perl. But probably worth trying and
investigating, and I believe you can do it.

> The suggestion when it failed was:  Can't use 'defined(@array)' (Maybe
> you should just omit the defined()?) at /.../timeconst.pl line 373.

Which means omitting the call, but not the parameter.

Samuel

Re: PATCH: Hurd FTBFS with perl 5.22

[Samuel Thibault]

Svante Signell, on Mon 04 Jan 2016 22:02:02 +0100, wrote:
> - @val = @{$canned_values{$hz}};
> - if (!defined(@val)) {
> - @val = compute_values($hz);
> - }
> + @val = compute_values($hz);

Don't we want to still try to use canned_values?

Samuel

Re: PATCH: Hurd FTBFS with perl 5.22

[Samuel Thibault]

James Clarke, on Mon 04 Jan 2016 22:38:28 +, wrote:
> > -   if (!defined(@val)) {
> > +   if (!@val) {

Applied, thanks!

Samuel

Re: PATCH: Hurd FTBFS with perl 5.22

[Svante Signell]

On Tue, 2016-01-05 at 17:36 +1100, William ML Leslie wrote:
> On 5 January 2016 at 16:56, Svante Signell  wrote:
> > BTW: Why does Hurd contain such crappy dependencies such as perl. Is this
> > part
> > of upstream or Debian specific? The Debian package does not have it:
> > apt-cache showsrc hurd | grep Build-Depends | grep -i perl
> > 
> > Is there more perl code in upstream Hurd? If not, how about rewrite this
> > code
> > snippet in C and "remove a should be added" language dependency!
> > 
> 
> It's used by a ported linux driver as part of libdde, as the path of
> the patch indicates.

Well, the source is from the Hurd package, not netdde. It's in 
hurd_0.7.orig-libdde-linux26.tar.bz2 so a build dependency on perl should be
added to the Hurd source package.

Re: PATCH: Hurd FTBFS with perl 5.22

[William ML Leslie]

On 5 January 2016 at 16:56, Svante Signell  wrote:
> BTW: Why does Hurd contain such crappy dependencies such as perl. Is this part
> of upstream or Debian specific? The Debian package does not have it:
> apt-cache showsrc hurd | grep Build-Depends | grep -i perl
> 
> Is there more perl code in upstream Hurd? If not, how about rewrite this code
> snippet in C and "remove a should be added" a language dependency!
>

It's used by a ported linux driver as part of libdde, as the path of
the patch indicates.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

Re: PATCH: Hurd FTBFS with perl 5.22

[Svante Signell]

On Mon, 2016-01-04 at 22:38 +, James Clarke wrote:
> On 4 Jan 2016, at 22:13, Samuel Thibault  wrote:
> > Svante Signell, on Mon 04 Jan 2016 23:09:00 +0100, wrote:
> 
> It is indeed just !@val (this use of defined was deprecated in 5.6.1 and
> raised warnings since 5.16[1]). Here's the simplified patch (untested):
> 
> > -   if (!defined(@val)) {
> > +   if (!@val) {
> > 

Thanks James, problem solved for now.

BTW: Why does Hurd contain such crappy dependencies such as perl. Is this part
of upstream or Debian specific? The Debian package does not have it:
apt-cache showsrc hurd | grep Build-Depends | grep -i perl

Is there more perl code in upstream Hurd? If not, how about rewrite this code
snippet in C and "remove a should be added" a language dependency!

Re: PATCH: Hurd FTBFS with perl 5.22

[James Clarke]

On 4 Jan 2016, at 22:13, Samuel Thibault  wrote:
> Svante Signell, on Mon 04 Jan 2016 23:09:00 +0100, wrote:
>> Obviously the !defined(@val) is
>> no longer allowed, and I don't know how to rewrite that condition.
> 
> Perhaps juste !@val?
> I have no idea, I don't know perl. But probably worth trying and
> investigating, and I believe you can do it.

It is indeed just !@val (this use of defined was deprecated in 5.6.1 and raised 
warnings since 5.16[1]). Here's the simplified patch (untested):

> Index: hurd-0.7/libdde-linux26/lib/src/kernel/timeconst.pl
> ===
> --- hurd-0.7.orig/libdde-linux26/lib/src/kernel/timeconst.pl
> +++ hurd-0.7/libdde-linux26/lib/src/kernel/timeconst.pl
> @@ -369,10 +369,10 @@ if ($hz eq '--can') {
>   die "Usage: $0 HZ\n";
>   }
> 
>   @val = @{$canned_values{$hz}};
> - if (!defined(@val)) {
> + if (!@val) {
>   @val = compute_values($hz);
>   }
>   output($hz, @val);
>  }
>  exit 0;


James

[1] 
https://metacpan.org/pod/release/RJBS/perl-5.22.0/pod/perldelta.pod#defined-array-and-defined-hash-are-now-fatal-errors



signature.asc
Description: Message signed with OpenPGP using GPGMail