setproctitle() support for DragonFly

[p5pRT]

Migrated from rt.perl.org#130068 (status was 'resolved')

Searchable as RT130068$

[p5pRT]

From @pavalos

Created by @pavalos

DragonFly has the same setproctitle() support that FreeBSD has, so
mg.c needs to be patched to include DragonFly (#ifdef __DragonFly__).

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.24.1:

Configured by perl at Wed Oct 12 21:42:09 UTC 2016.

Summary of my perl5 (revision 5 version 24 subversion 1) configuration:
   
  Platform:
    osname=dragonfly, osvers=4.7-synth, archname=x86_64-dragonfly-thread-multi
    uname='dragonfly ylem.theshell.com 4.7-synth dragonfly 4.7-synth x86_64 '
    config_args='-sde -Dprefix=/usr/local -Dlibperl=libperl.so.5.24.1 -Darchlib=/usr/local/lib/perl5/5.24/mach -Dprivlib=/usr/local/lib/perl5/5.24 -Dman3dir=/usr/local/lib/perl5/5.24/perl/man/man3 -Dman1dir=/usr/local/lib/perl5/5.24/perl/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/mach/5.24 -Dsitelib=/usr/local/lib/perl5/site_perl -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/site_perl/man/man3 -Dsiteman1dir=/usr/local/lib/perl5/site_perl/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dusenm=n -Dcc=cc -Duseshrplib -Dinc_version_list=none -Dcf_by=perl -Dcf_email=perl@FreeBSD.org -Dcf_time=Wed Oct 12 21:42:09 UTC 2016 -Alddlflags=-L/construction/lang/perl5.24/perl-5.24.1-RC4 -L/usr/local/lib/perl5/5.24/mach/CORE -lperl -Dshrpldflags=$(LDDLFLAGS:N-L/construction/lang/perl5.24/perl-5.24.1-RC4:N-L/usr/local/lib/perl5/5.24/mach/CORE:N-lperl) -Wl,-soname,$(LIBPERL:R) -Doptimize=-pipe -O2 -fno-strict-aliasing -Ui_gdbm -Dusemultiplicity=y -Duse64bitint -Dusethreads=y -Dusemymalloc=n'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2',
    optimize='-pipe -O2 -fno-strict-aliasing',
    cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion='', gccversion='5.4.1 [DragonFly] Release/2016-08-27', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-pthread -Wl,-E  -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib /usr/lib
    libs=-lpthread -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so.5.24.1
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='  -Wl,-R/usr/local/lib/perl5/5.24/mach/CORE'
    cccdlflags='-DPIC -fPIC', lddlflags='-shared  -L/usr/local/lib/perl5/5.24/mach/CORE -lperl -L/usr/local/lib -fstack-protector-strong'

Locally applied patches:
    RC4


@INC for perl 5.24.1:
    /usr/local/lib/perl5/site_perl/mach/5.24
    /usr/local/lib/perl5/site_perl
    /usr/local/lib/perl5/5.24/mach
    /usr/local/lib/perl5/5.24


Environment for perl 5.24.1:
    HOME=/home/pavalos
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/pkg/sbin:/usr/pkg/bin:/home/pavalos/bin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/zsh

[p5pRT]

From @jkeenan

On Thu, 10 Nov 2016 19​:29​:16 GMT, peter@​theshell.com wrote​:

This is a bug report for perl from peter@​theshell.com,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]
DragonFly has the same setproctitle() support that FreeBSD has, so
mg.c needs to be patched to include DragonFly (#ifdef __DragonFly__).

1. Do you know if there is someone who is the designated "Perl 5 maintainer" for DragonflyBSD?

2. Is there someone who is capable of smoke-testing Perl 5 blead on this OS, and/or is capable of running a CPANtesters operation for DragonflyBSD?

I ask these questions because any patch to the hints file will need to be confirmed as not causing harm.

We know that we (Perl 5 Porters) are already not doing a great job on testing the long established BSDs (Free, Open, Net), but at least in two of those three cases we know whom to call.

Any leads you can provide would be appreciated. Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @jkeenan

On Sat, 19 Nov 2016 23​:05​:36 GMT, jkeenan wrote​:

On Thu, 10 Nov 2016 19​:29​:16 GMT, peter@​theshell.com wrote​:

This is a bug report for perl from peter@​theshell.com,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]
DragonFly has the same setproctitle() support that FreeBSD has, so
mg.c needs to be patched to include DragonFly (#ifdef __DragonFly__).

1. Do you know if there is someone who is the designated "Perl 5
maintainer" for DragonflyBSD?

2. Is there someone who is capable of smoke-testing Perl 5 blead on
this OS, and/or is capable of running a CPANtesters operation for
DragonflyBSD?

I ask these questions because any patch to the hints file will need to
be confirmed as not causing harm.

We know that we (Perl 5 Porters) are already not doing a great job on
testing the long established BSDs (Free, Open, Net), but at least in
two of those three cases we know whom to call.

Any leads you can provide would be appreciated. Thank you very much.

No responses in over a month. Marking ticket stalled.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

@jkeenan - Status changed from 'open' to 'stalled'

[p5pRT]

From @jhi

Sorry, I don't have DragonFly setup.

But a general comment about the desire of having a regular smoketester for all supported platforms.

It's a fine desire. Certainly would help in blead not accidentally breaking on various platforms.

But for rarer platforms, it is not going to happen. One can chase down people who in the past have provided patches on the platforms, or reported bugs, and try to get them to do if not Continuous Integration, at least semi-regular builds, automated and/or regular if possible.

Another possible avenue of finding people who care is to look for the whatever packaging
system(s) the OS uses.

[p5pRT]

The RT System itself - Status changed from 'stalled' to 'open'

[p5pRT]

From @xsawyerx

On 12/30/2016 01​:55 AM, Jarkko Hietaniemi via RT wrote​:

Sorry, I don't have DragonFly setup.

But a general comment about the desire of having a regular smoketester for all supported platforms.

It's a fine desire. Certainly would help in blead not accidentally breaking on various platforms.

But for rarer platforms, it is not going to happen.

This is basically the summary of it. We simply do not have active
smoketesters for every platform on which Perl is supported. This means
tickets will come up from time to time and we should depend on the
person who submits the tickets to help us resolve the issue. From ticket
history, we can also observe that not every breakage is a full platform
breakage (as in, for every user of that platform). Often times it's
about a specific setup the reporter has, in which case unless we set up
the same thing, we are not likely to find the problem.

One can chase down people who in the past have provided patches on the platforms, or reported bugs, and try to get them to do if not Continuous Integration, at least semi-regular builds, automated and/or regular if possible.

Another avenue is to have a system that sets up virtual environments
(VirtualBox, VMWare, Docker, etc.) that provide the same set up, using
the output provided in the ticket. This sounds like a plausible thing to
accomplish for various setups, but is probably more of a hackathon kind
of work, and it's not assured to work either.

Another possible avenue of finding people who care is to look for the whatever packaging
system(s) the OS uses.

Which goes back to reporters, I believe.

From my perspective, tickets that have to do with a platform on which we
do not have an active smoker setup should defer to whether the reporter
is available for help in resolving this, or another user of said
platform willing to offer assistance.

While I do not want to close the ticket, I also do not want to keep
various random failing tickets for what could also be a failed specific
setup. In many cases a report is completely irrelevant by the time we
get a response, since it involves a version we might not support anymore
and code that has drifted considerably since.

In this case I believe a grace period for such tickets, as Jim promotes
in other tickets, is a good balance.

[p5pRT]

From @jkeenan

On 12/30/2016 05​:22 AM, Sawyer X wrote​:

On 12/30/2016 01​:55 AM, Jarkko Hietaniemi via RT wrote​:

Sorry, I don't have DragonFly setup.

But a general comment about the desire of having a regular smoketester for all supported platforms.

It's a fine desire. Certainly would help in blead not accidentally breaking on various platforms.

But for rarer platforms, it is not going to happen.

This is basically the summary of it. We simply do not have active
smoketesters for every platform on which Perl is supported. This means
tickets will come up from time to time and we should depend on the
person who submits the tickets to help us resolve the issue. From ticket
history, we can also observe that not every breakage is a full platform
breakage (as in, for every user of that platform). Often times it's
about a specific setup the reporter has, in which case unless we set up
the same thing, we are not likely to find the problem.

One can chase down people who in the past have provided patches on the platforms, or reported bugs, and try to get them to do if not Continuous Integration, at least semi-regular builds, automated and/or regular if possible.

Another avenue is to have a system that sets up virtual environments
(VirtualBox, VMWare, Docker, etc.) that provide the same set up, using
the output provided in the ticket. This sounds like a plausible thing to
accomplish for various setups, but is probably more of a hackathon kind
of work, and it's not assured to work either.

Another possible avenue of finding people who care is to look for the whatever packaging
system(s) the OS uses.

Which goes back to reporters, I believe.

From my perspective, tickets that have to do with a platform on which we
do not have an active smoker setup should defer to whether the reporter
is available for help in resolving this, or another user of said
platform willing to offer assistance.

While I do not want to close the ticket, I also do not want to keep
various random failing tickets for what could also be a failed specific
setup. In many cases a report is completely irrelevant by the time we
get a response, since it involves a version we might not support anymore
and code that has drifted considerably since.

In this case I believe a grace period for such tickets, as Jim promotes
in other tickets, is a good balance.

I marked the ticket Stalled. That's a category I'm loathe to use, as it
usually consigns the ticket to a never-read-again limbo. But when we
can't proceed without information we don't have, it's sometimes the only
alternative.

[p5pRT]

From @iabyn

On Fri, Dec 30, 2016 at 08​:20​:26AM -0500, James E Keenan wrote​:

I marked the ticket Stalled. That's a category I'm loathe to use, as it
usually consigns the ticket to a never-read-again limbo. But when we can't
proceed without information we don't have, it's sometimes the only
alternative.

But in this case we weren't waiting on the OP to supply information, we
were "waiting" on someone to volunteer to smoke DragonFly. and since
no-one volunteered, we can fall back to the position of patching "blind".

However, I would request the following clarifications from the OP.

In S_set_dollarzero(), it decides whether to call setproctitle() based on
whether HAS_SETPROCTITLE is true. This in turn is set by Configure based
on whether it can find setproctitle() in libc.

OP​: is HAS_SETPROCTITLE set on DragonFly systems?

Secondly, it calls setproctitle() with a 1st arg of either "-%s" or
"%s" depending on whether __FreeBSD_version > 410001. OP​: what should it
do in the DragonFly case?

Even better, could OP supply a patch that works under DragonFly?

--
The warp engines start playing up a bit, but seem to sort themselves out
after a while without any intervention from boy genius Wesley Crusher.
  -- Things That Never Happen in "Star Trek" #17

[p5pRT]

From @pavalos

On Jan 2, 2017, at 12​:57 AM, Dave Mitchell via RT <perlbug-followup@​perl.org> wrote​:

However, I would request the following clarifications from the OP.

In S_set_dollarzero(), it decides whether to call setproctitle() based on
whether HAS_SETPROCTITLE is true. This in turn is set by Configure based
on whether it can find setproctitle() in libc.

OP​: is HAS_SETPROCTITLE set on DragonFly systems?

Yes.

Secondly, it calls setproctitle() with a 1st arg of either "-%s" or
"%s" depending on whether __FreeBSD_version > 410001. OP​: what should it
do in the DragonFly case?

For DragonFly it should be “-%s”, just like the __FreeBSD_version > 410001 case.

Even better, could OP supply a patch that works under DragonFly?

Inline Patch

--- mg.c.orig   2016-12-26 04:49:24.000000000 -0800
+++ mg.c        2017-01-02 22:26:14.683427000 -0800
@@ -2557,7 +2557,7 @@
      * the setproctitle() routine to manipulate that. */
     if (PL_origalen != 1) {
         s = SvPV_const(sv, len);
-#   if __FreeBSD_version > 410001
+#   if __FreeBSD_version > 410001 || defined(__DragonFly__)
         /* The leading "-" removes the "perl: " prefix,
          * but not the "(perl) suffix from the ps(1)
          * output, because that's what ps(1) shows if the

[p5pRT]

From @iabyn

On Mon, Jan 02, 2017 at 10​:33​:53PM -0800, Peter Avalos wrote​:

On Jan 2, 2017, at 12​:57 AM, Dave Mitchell via RT <perlbug-followup@​perl.org> wrote​:

However, I would request the following clarifications from the OP.

In S_set_dollarzero(), it decides whether to call setproctitle() based on
whether HAS_SETPROCTITLE is true. This in turn is set by Configure based
on whether it can find setproctitle() in libc.

OP​: is HAS_SETPROCTITLE set on DragonFly systems?

Yes.

Secondly, it calls setproctitle() with a 1st arg of either "-%s" or
"%s" depending on whether __FreeBSD_version > 410001. OP​: what should it
do in the DragonFly case?

For DragonFly it should be “-%s”, just like the __FreeBSD_version > 410001 case.

Even better, could OP supply a patch that works under DragonFly?

--- mg.c.orig 2016-12-26 04​:49​:24.000000000 -0800
+++ mg.c 2017-01-02 22​:26​:14.683427000 -0800
@​@​ -2557,7 +2557,7 @​@​
* the setproctitle() routine to manipulate that. */
if (PL_origalen != 1) {
s = SvPV_const(sv, len);
-# if __FreeBSD_version > 410001
+# if __FreeBSD_version > 410001 || defined(__DragonFly__)
/* The leading "-" removes the "perl​: " prefix,
* but not the "(perl) suffix from the ps(1)
* output, because that's what ps(1) shows if the

Thanks, applied to blead as v5.25.8-178-g3862695. That commit also
adds your name name and email to the AUTHORS file.

--
Wesley Crusher gets beaten up by his classmates for being a smarmy git,
and consequently has a go at making some friends of his own age for a
change.
  -- Things That Never Happen in "Star Trek" #18

[p5pRT]

@iabyn - Status changed from 'open' to 'resolved'