Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Dominic Hargreaves]

Control: block -1 by 827075

On Mon, Jun 06, 2016 at 11:54:01PM +0200, Guillem Jover wrote:
> I've been looking recently at creating a small helper to delegate the
> locking to, because the automatic dbgsym packages and dpkg coloring
> have exacerbated this annoyance when building packages :), but that
> poses varios problems, and using an XS module is definitely the
> cleanest approach. And the mail from Josh just reminded me that this
> seems to have fallen through the cracks. :)
> 
> As I've mentioned before I'd really prefer to use the pre-existing
> module to avoid duplicating work, but if the correct solution might
> take too much effort, I might look into embedding something based on
> this module into dpkg itself temporarily.
> 
> Also maybe we should file the above as a bug report against
> libfile-fcntllock-perl and block this one aginst the new one?

Hi Guillem,

Yes, indeed; this bug is quite long enough already :) I've refiled
Niko's plan (which is still, as far as I know, "just" in need
of implementation, as two new bugs, #827074 and #827075). I don't
think that it would take a lot of work to implement, so I'm hopeful
that we can get this resolved before too much longer.

(I'm still very aware that I was the original instigator of the
much-despised warning, so I'd like to see the back of it as much
as anyone :)

Cheers,
Dominic.

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Guillem Jover]

Hi!

On Sun, 2015-05-24 at 20:11:42 +0300, Niko Tyni wrote:
> On Wed, May 28, 2014 at 08:10:50AM +0200, Guillem Jover wrote:
> > On Tue, 2014-05-27 at 23:56:03 +0300, Niko Tyni wrote:
> 
> > > @debian-perl: To make this usable for the original problem (giving
> > > dpkg-dev a working File::FcntlLock without a transitive hard dependency
> > > on perlapi-*), I suppose the package should either be split or the
> > > ${perl:Depends} dependency should be relaxed to a recommendation.
> > 
> > Either would work for me, the latter might be problematic for current
> > code not assuming that it can fallback to use one of the pure perl
> > versions though. Although checking now it seems only libdpkg-perl is
> > making use of the module in Debian, so it might not be such an issue
> > after all; and would avoid a round-trip over NEW, a very tiny package,
> > and would guarantee the packages and modules are always present (even
> > if not fully functional). Anyway, I'm fine with whatever you decide.
> 
> Hi, we've been looking at this again at the Debian Perl sprint in
> Barcelona. Jens: see below for another feature request (and sorry
> for bothering you again with this :)
> 
> > > (Hm, my preliminary testing indicates that 5.20.0 may introduce new
> > >  challenges around PERL_DL_NONLAZY.  Urgh. Will investigate.)
> > 
> > Thanks, will take that into account! And I'm obviously interested in
> > any results from that investigation, which might imply having to switch
> > to always use the pure version for example. :)
> 
> We ended up moving XS modules into Perl version specific paths in 5.20, so
> PERL_DL_NONLAZY=1 should no longer be needed, and the above "challenges"
> became moot. Perl shouldn't be able to see binary incompatible modules
> anymore.
> 
> However, this introduced another problem. As the architecture dependent
> parts of @INC now vary with the Perl version, packages that put files
> there also need a dependency on perlapi-* to ensure they match the
> installed Perl version, otherwise they won't be found at all. See Perl
> policy 4.4.2, at
> 
>  
> https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps
> 
> To achieve the goal of having a libfile-fcntllock-perl package which
> doesn't have a hard dependency on perlapi-*, we need another place to
> put File::FcntlLock::Pure, which is architecture dependent but not
> Perl version dependent. That could be something like
>  /usr/lib//libfile-fcntllock-perl
> However, I'd like to punt information about that solely to the
> libfile-fcntllock-perl package, so that callers wouldn't need
> to be aware of the details.
> 
> Jens: would it be possible to have the main File::FcntlLock module
> fall back to ::Pure (or even ::Inline after that, I suppose) in case
> ::XS is not found on @INC? Or are the API differences mentioned
> in the documentation big enough that this wouldn't really work?
> In that case maybe something like File::FcntlLock::Any with a minimal
> API would make sense?
> 
> For full disclosure, if we had the fallback we could setup the
> modules something like this:
> 
>  /usr/share/perl5/File/FcntlLock.pm
> on normal arch-independent @INC; tries ::XS first and
> falls back to ::Pure from a special directory
> 
>  /usr/lib//libfile-fcntllock-perl/File/FcntllLock/Pure.pm
> in a special directory that only File::FcntlLock knows
> possibly with an additional symlink on the normal @INC too
> 
>  /usr/lib///File/FcntlLock/XS.pm (and .so)
> on normal arch-dependent @INC
> 
> The "special directory" part would be a Debian-specific deviation
> that wouldn't need any upstream support.
> 
> This way we could honestly have the package just Recommend
> perlapi-*, and have it still work (even if in a degraded state)
> when there's version skew between Perl and the XS parts.
> 
> (Jens: I can have a shot at a patch for this if that helps...)

I've been looking recently at creating a small helper to delegate the
locking to, because the automatic dbgsym packages and dpkg coloring
have exacerbated this annoyance when building packages :), but that
poses varios problems, and using an XS module is definitely the
cleanest approach. And the mail from Josh just reminded me that this
seems to have fallen through the cracks. :)

As I've mentioned before I'd really prefer to use the pre-existing
module to avoid duplicating work, but if the correct solution might
take too much effort, I might look into embedding something based on
this module into dpkg itself temporarily.

Also maybe we should file the above as a bug report against
libfile-fcntllock-perl and block this one aginst the new one?

Thanks,
Guillem

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Niko Tyni]

(dropped the debian-perl list, added the pkg-perl team)

On Wed, May 28, 2014 at 08:10:50AM +0200, Guillem Jover wrote:
> On Tue, 2014-05-27 at 23:56:03 +0300, Niko Tyni wrote:

> > @debian-perl: To make this usable for the original problem (giving
> > dpkg-dev a working File::FcntlLock without a transitive hard dependency
> > on perlapi-*), I suppose the package should either be split or the
> > ${perl:Depends} dependency should be relaxed to a recommendation.
> 
> Either would work for me, the latter might be problematic for current
> code not assuming that it can fallback to use one of the pure perl
> versions though. Although checking now it seems only libdpkg-perl is
> making use of the module in Debian, so it might not be such an issue
> after all; and would avoid a round-trip over NEW, a very tiny package,
> and would guarantee the packages and modules are always present (even
> if not fully functional). Anyway, I'm fine with whatever you decide.

Hi, we've been looking at this again at the Debian Perl sprint in
Barcelona. Jens: see below for another feature request (and sorry
for bothering you again with this :)

> > (Hm, my preliminary testing indicates that 5.20.0 may introduce new
> >  challenges around PERL_DL_NONLAZY.  Urgh. Will investigate.)
> 
> Thanks, will take that into account! And I'm obviously interested in
> any results from that investigation, which might imply having to switch
> to always use the pure version for example. :)

We ended up moving XS modules into Perl version specific paths in 5.20, so
PERL_DL_NONLAZY=1 should no longer be needed, and the above "challenges"
became moot. Perl shouldn't be able to see binary incompatible modules
anymore.

However, this introduced another problem. As the architecture dependent
parts of @INC now vary with the Perl version, packages that put files
there also need a dependency on perlapi-* to ensure they match the
installed Perl version, otherwise they won't be found at all. See Perl
policy 4.4.2, at

 
https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-module_deps

To achieve the goal of having a libfile-fcntllock-perl package which
doesn't have a hard dependency on perlapi-*, we need another place to
put File::FcntlLock::Pure, which is architecture dependent but not
Perl version dependent. That could be something like
 /usr/lib//libfile-fcntllock-perl
However, I'd like to punt information about that solely to the
libfile-fcntllock-perl package, so that callers wouldn't need
to be aware of the details.

Jens: would it be possible to have the main File::FcntlLock module
fall back to ::Pure (or even ::Inline after that, I suppose) in case
::XS is not found on @INC? Or are the API differences mentioned
in the documentation big enough that this wouldn't really work?
In that case maybe something like File::FcntlLock::Any with a minimal
API would make sense?

For full disclosure, if we had the fallback we could setup the
modules something like this:

 /usr/share/perl5/File/FcntlLock.pm
on normal arch-independent @INC; tries ::XS first and
falls back to ::Pure from a special directory

 /usr/lib//libfile-fcntllock-perl/File/FcntllLock/Pure.pm
in a special directory that only File::FcntlLock knows
possibly with an additional symlink on the normal @INC too

 /usr/lib///File/FcntlLock/XS.pm (and .so)
on normal arch-dependent @INC

The "special directory" part would be a Debian-specific deviation
that wouldn't need any upstream support.

This way we could honestly have the package just Recommend
perlapi-*, and have it still work (even if in a degraded state)
when there's version skew between Perl and the XS parts.

(Jens: I can have a shot at a patch for this if that helps...)
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Josh Triplett]

Package: libdpkg-perl
Version: 1.17.23
Followup-For: Bug #677865

What's the current status of this bug?  The most recent mail, in May
2014, mentions a possible improvement in dpkg 1.17.10.  Has the
necessarily perl packaging change not yet taken place?

I still see this issue every time I build a package.

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.18.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libdpkg-perl depends on:
ii  dpkg  1.17.23
ii  libtimedate-perl  2.3000-2
ii  perl  5.20.1-5

Versions of packages libdpkg-perl recommends:
ii  bzip2   1.0.6-7+b2
pn  libfile-fcntllock-perl  
ii  xz-utils5.1.1alpha+20120614-2+b3

Versions of packages libdpkg-perl suggests:
ii  binutils  2.25-4
pn  debian-keyring
ii  gcc [c-compiler]  4:4.9.2-1
ii  gcc-4.8 [c-compiler]  4.8.4-1
ii  gcc-4.9 [c-compiler]  4.9.2-10
ii  gnupg 1.4.18-6
ii  gnupg22.0.26-4
ii  gpgv  1.4.18-6
ii  patch 2.7.3-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Guillem Jover]

Hi!

On Tue, 2014-05-27 at 23:56:03 +0300, Niko Tyni wrote:
> On Tue, May 27, 2014 at 04:49:35PM +0200, Jens Thoms Toerring wrote:
> > Let's hope the new 0.20 version on CPAN is the final one;-)
> 
> Thanks for your awesome work, Jens!

Absolutely, the same goes for the debian-perl team! :)

> @debian-perl: To make this usable for the original problem (giving
> dpkg-dev a working File::FcntlLock without a transitive hard dependency
> on perlapi-*), I suppose the package should either be split or the
> ${perl:Depends} dependency should be relaxed to a recommendation.

Either would work for me, the latter might be problematic for current
code not assuming that it can fallback to use one of the pure perl
versions though. Although checking now it seems only libdpkg-perl is
making use of the module in Debian, so it might not be such an issue
after all; and would avoid a round-trip over NEW, a very tiny package,
and would guarantee the packages and modules are always present (even
if not fully functional). Anyway, I'm fine with whatever you decide.

> This way dpkg-dev could still depend on the package, and either fall
> back to File::FcntlLock::Pure if File::FcntlLock::XS doesn't work, or
> just unconditionally use File::FcntlLock::Pure. Not sure which is cleaner.

As I've mentioned before I think always using one of the pure versions
could potentially lead to ABI issues, so I'd rather only use as a
fallback when the XS is not available or functional if possible. And I'll
be implementing that for dpkg 1.17.10, leaving the dependency metadata
until the packaging side has been decided on your side.

> In the fallback option, dpkg-dev should probably set PERL_DL_NONLAZY=1
> before trying to load File::FcntlLock::XS. See #479711. 

> (Hm, my preliminary testing indicates that 5.20.0 may introduce new
>  challenges around PERL_DL_NONLAZY.  Urgh. Will investigate.)

Thanks, will take that into account! And I'm obviously interested in
any results from that investigation, which might imply having to switch
to always use the pure version for example. :)

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Niko Tyni]

On Tue, May 27, 2014 at 04:49:35PM +0200, Jens Thoms Toerring wrote:

> Let's hope the new 0.20 version on CPAN is the final one;-)

Thanks for your awesome work, Jens!

@debian-perl: To make this usable for the original problem (giving
dpkg-dev a working File::FcntlLock without a transitive hard dependency
on perlapi-*), I suppose the package should either be split or the
${perl:Depends} dependency should be relaxed to a recommendation.

This way dpkg-dev could still depend on the package, and either fall
back to File::FcntlLock::Pure if File::FcntlLock::XS doesn't work, or
just unconditionally use File::FcntlLock::Pure. Not sure which is cleaner.

In the fallback option, dpkg-dev should probably set PERL_DL_NONLAZY=1
before trying to load File::FcntlLock::XS. See #479711. 

(Hm, my preliminary testing indicates that 5.20.0 may introduce new
 challenges around PERL_DL_NONLAZY.  Urgh. Will investigate.)
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[gregor herrmann]

On Tue, 27 May 2014 16:49:35 +0200, Jens Thoms Toerring wrote:

> On Tue, May 27, 2014 at 03:01:18PM +0300, Damyan Ivanov wrote:
> > The hurd-i386 build fails with an undefined subroutine error:
> Looks like I got this fixed also (a missing '$self->' and a
> stray '=cut' - no idea why it wasn't also flagged on other
> systems...). Let's hope the new 0.20 version on CPAN is the
> final one;-)

Thanks for the new release, on its way to the Debian buildds.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: U2: Bad


signature.asc
Description: Digital Signature

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

On Tue, May 27, 2014 at 03:01:18PM +0300, Damyan Ivanov wrote:
> The hurd-i386 build fails with an undefined subroutine error:

Looks like I got this fixed also (a missing '$self->' and a
stray '=cut' - no idea why it wasn't also flagged on other
systems...). Let's hope the new 0.20 version on CPAN is the
final one;-)
  Thanks and best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Damyan Ivanov]

-=| Jens Thoms Toerring, 27.05.2014 09:21:42 +0200 |=-
>I realized that I can install a 32-bit version of Debian
> in a virtual box also on an 64-bit machine and that allowed
> me to find the reason for the failing tests. As you already
> may have suspected, it was a rather stupid mistake: I had
> forgotten to pass the CFLAGS Perl was build with to the
> C compiler when creating the program that determines what
> format string to pass to pack/unpack.

Ah, good catch!

> And since the Debian
> version of Perl seems to be build with large file and 64-bit
> offset enabled on 32-bit machines, but this isn't the com-
> pilers default setting, a mismatch between the flock struct
> Perl uses and what my program thinks it is resulted. This
> hopefully is now corrected in the new 0.19 version I just
> uploaded to CPAN.

Package updated and uploaded to unstable. I tested it in a 32-bit 
chroot and it built fine there. Should appear in the build network 
soon.

> https://buildd.debian.org/status/logs.php?pkg=libfile-fcntllock-perl

Cheers,
dam


signature.asc
Description: Digital signature

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

   I realized that I can install a 32-bit version of Debian
in a virtual box also on an 64-bit machine and that allowed
me to find the reason for the failing tests. As you already
may have suspected, it was a rather stupid mistake: I had
forgotten to pass the CFLAGS Perl was build with to the
C compiler when creating the program that determines what
format string to pass to pack/unpack. And since the Debian
version of Perl seems to be build with large file and 64-bit
offset enabled on 32-bit machines, but this isn't the com-
pilers default setting, a mismatch between the flock struct
Perl uses and what my program thinks it is resulted. This
hopefully is now corrected in the new 0.19 version I just
uploaded to CPAN.

Thank you for your patience and help!

 Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Daniel Lintott]

On 26/05/14 22:11, gregor herrmann wrote:
> On Mon, 26 May 2014 22:41:13 +0200, Jens Thoms Toerring wrote:
> 
>> Is there any chance of someone temporarily giving me an account
>> on a type of machine where the tests fail or 
> 
> https://gcc.gnu.org/wiki/CompileFarm

If it's of any use I do have an account on the GCC Compile Farm,
obviously I can't give access to that account myself.. as access is via
SSH key... but if needed I can try some builds over there

-- 
Daniel Lintott
GPG Key: 4096R/5D73EC6E



signature.asc
Description: OpenPGP digital signature

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[gregor herrmann]

On Mon, 26 May 2014 22:41:13 +0200, Jens Thoms Toerring wrote:

> Is there any chance of someone temporarily giving me an account
> on a type of machine where the tests fail or 

https://gcc.gnu.org/wiki/CompileFarm
https://dsa.debian.org/doc/guest-account/
might be possibilities.

> at least of getting
> at what the results of 'perl Makefile.PL' look like (that should
> contain the automatically created Perl code which might give me
> some clues)?

Sure.
Since it seems that Debian doesn't have an i386 porterbox I choose
harris (armhf) [0].
Find attached the files that were created by `perl Makefile.PL'. [1]
 
> Please accept my appologies for these inconveniences!

No worries :)


Cheers,
gregor


[0]
$ dpkg-architecture 
DEB_BUILD_ARCH=armhf
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_CPU=arm
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_GNU_CPU=arm
DEB_BUILD_GNU_SYSTEM=linux-gnueabihf
DEB_BUILD_GNU_TYPE=arm-linux-gnueabihf
DEB_BUILD_MULTIARCH=arm-linux-gnueabihf
DEB_HOST_ARCH=armhf
DEB_HOST_ARCH_BITS=32
DEB_HOST_ARCH_CPU=arm
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_ARCH_OS=linux
DEB_HOST_GNU_CPU=arm
DEB_HOST_GNU_SYSTEM=linux-gnueabihf
DEB_HOST_GNU_TYPE=arm-linux-gnueabihf
DEB_HOST_MULTIARCH=arm-linux-gnueabihf


[1]
$ perl -v

This is perl 5, version 18, subversion 2 (v5.18.2) built for 
arm-linux-gnueabihf-thread-multi-64int
(with 41 registered patches, see perl -V for more detail)


-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Tanita Tikaram: Wonderful Shadow


perl-makefile.pl-result.tar.gz
Description: application/gzip


signature.asc
Description: Digital Signature

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

On Mon, May 26, 2014 at 08:34:59PM +0200, gregor herrmann wrote:
> On Mon, 26 May 2014 17:57:34 +0200, Jens Thoms Toerring wrote:
> > Thank you very much. Unfortunately, CPAN testing has shown
> > that there are some systems where there are problems building
> > the complete module. 
> 
> The results of the Debian build daemons are also not very
> encouraging:
> https://buildd.debian.org/status/logs.php?pkg=libfile-fcntllock-perl
> 
> > For this reason I had to modify the build process to avoid that
> > on such systems the modules File::FcntlLock::Pure and
> > File::FcntlLock::Inline get installed, and I have just uploaded
> > a new 0.17 version.
> 
> 0.18 uploaded to Debian, let's keep an eye on the buildd logs (same
> URL as above).

I just had a look at these log files (thanks for the link!) and
something definitely is fishy there. While (with the excetion of
mipsel, where there is a complaining about some downloads failing
which I probably can't do much about) for most of what looks like
32-bit systems the ::Pure and ::Inline modules fail their most
important test:-(

CPAN testing gives it clean bill of health, but the tests seem
to have been done with 64-bit systems only.

At the moment I'm at a loss to understand what's going on with the
32-bit systems - they obviously have a 'q' format for pack/unpack
(otherwise the ::Pure and ::Inline modules shouldn't be build and
then also not tested). Unfortunately, it's nearly a decade since
I had any 32-bit system, so this is a bit like flying blind;-)

Is there any chance of someone temporarily giving me an account
on a type of machine where the tests fail or at least of getting
at what the results of 'perl Makefile.PL' look like (that should
contain the automatically created Perl code which might give me
some clues)?

Please accept my appologies for these inconveniences!

   Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[gregor herrmann]

On Mon, 26 May 2014 17:57:34 +0200, Jens Thoms Toerring wrote:

(trimming the CC list a bit)

> On Mon, May 26, 2014 at 12:39:51PM +0300, Damyan Ivanov wrote:
> > Package libfile-fcntllock-perl upgraded to 0.16 and uploaded to Debian 
> > unstable.
> Thank you very much. Unfortunately, CPAN testing has shown
> that there are some systems where there are problems building
> the complete module. 

The results of the Debian build daemons are also not very
encouraging:
https://buildd.debian.org/status/logs.php?pkg=libfile-fcntllock-perl

> For this reason I had to modify the build process to avoid that
> on such systems the modules File::FcntlLock::Pure and
> File::FcntlLock::Inline get installed, and I have just uploaded
> a new 0.17 version.

0.18 uploaded to Debian, let's keep an eye on the buildd logs (same
URL as above).


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: U2: Gloria


signature.asc
Description: Digital Signature

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

On Mon, May 26, 2014 at 12:39:51PM +0300, Damyan Ivanov wrote:
> Package libfile-fcntllock-perl upgraded to 0.16 and uploaded to Debian 
> unstable.

Thank you very much. Unfortunately, CPAN testing has shown
that there are some systems where there are problems building
the complete module. These seem to be 32-bit systems where the
flock struct contains 64-bit values and the installed Perl ver-
sion doesn't support the 'q' format for its pack() and unpack()
function. This then does not allow the use of a "pure Perl" ap-
proach since there doesn't seem to be a reliable way to assemble
the flock struct - at least I have no good idea how to do it:-(

For this reason I had to modify the build process to avoid that
on such systems the modules File::FcntlLock::Pure and
File::FcntlLock::Inline get installed, and I have just uploaded
a new 0.17 version.

I don't know if there are any Debian systems with that kind of
setup (the machine this was reported from runs OpenBSD). But per-
haps it would be prudent to have a look at the configuration of
the distributed Perl version for 32-bit systems to ascertain
that this won't become a problem when attempting to use the
"pure Perl" sub-modules on Debian based systems.

If someone has a good idea for how to handle this problem with-
out disabling the "pure Perl" modules I'd be grateful!

Thank you and best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Damyan Ivanov]

-=| Jens Thoms Toerring, 25.05.2014 23:01:34 +0200 |=-
>since I got no complaints about the new version of the
> File::FcntlLock module I just uploaded it to CPAN. I hope
> that it will help to avoid the problems you had with it.

Package libfile-fcntllock-perl upgraded to 0.16 and uploaded to Debian 
unstable.


signature.asc
Description: Digital signature

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

   since I got no complaints about the new version of the
File::FcntlLock module I just uploaded it to CPAN. I hope
that it will help to avoid the problems you had with it.

 Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

   thanks to your inputs I'm mostly through with a rework
of the File::FnctlLock module. It's now basically three
modules:

a) File::FcntlLock (or File::FcntlLock::XS as an alias) -
   this is basically the old module, using XS,

b) File::FcntlLock::Pure - created during Perl "Makefile.PL"
   where a C program is run to add the necessary Perl code
   for packing/unpacking the C flock struct,

c) File::FcntlLock::Inline - similar to File::FcntlLock::Pure
   in that it uses pack/unpack but creates, compiles and runs
   a C program for determining the binry layout of the flock
   structure each time it's loaded.

There's a rather minor difference between the functionality
of the first and the two others: File::FcntlLock also accepts
a file descriptor as an argument to the lock() method call,
while the other to only can deal with file handles or type-
globs.

The handling of errors (when passing invalid arguments to the
lock() method) also deviates slightly: File::FcntlLock passes
them on to the fcntl(2) system call while for the others Perl's
fcntl() function rejects some of them.

You can simply pick the one you would like to use or, if there
are concerns that one of them won't work, do a 'use' in an eval
and switch to another one if loading fails. I've also played
around with the idea of switching to a different one automati-
cally but this got rather tricky with the MakeMaker build system
(I don't think it was written with the idea in mind that there
could be a submodule that is XS-based) and then the little dif-
ferences in behaviour made me decide against it - other people
using the module might be caught unaware when, for whatever
reasons, the XS-version doesn't work but this isn't obvious and
then suddenly an attempt to lock() on a file descriptor suddenly
fails. Someone having to figure out what's going wrong in such a
situation probably wouldn't be too amused;-)

Could you be so kind and give the thing a try and tell me if
you notice any irregularities? I append the tar ball.

  Thank you and best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


File-FcntlLock-0.15.tar.gz
Description: Binary data

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

On Sun, May 18, 2014 at 07:24:25PM +0200, Guillem Jover wrote:
> Well, I think going for now with the pure perl version would solve
> our immediate problem, we could go over the rest separately. I just
> mentioned it now because it would avoid dropping an then having to
> reintroduce the XS code again.

Fine. I'm in the process of doing some clean-up and will send
it wen done.

> > a) add File::FcntlLock in XS form directly as Dpkg::Lock (or
> >a simplified version since obviously only locks on whole
> >files are required)
> > b) add the pure Perl version
> > c) add a version that is modified so that it determines the lay-
> >out of the C flock struct somewhere in a BEGIN block by com-
> >piling and running a C program and then using its output (as
> >I can see libdpkg-perl requires the availability of a C com-
> >piler). I'd write that for you if you like.
> 
> Because the File::FcntlLock module is generally useful, I'd rather see
> it improved, instead of forking a local copy for dpkg-dev alone. I don't
> think option c) would solve the issue I described, though.

Wouldn't it? It always evaluates the C flock struct whenever
'use'd, so it should get it right on the system used, even if
the C fcntl(2) function should be modified. And if there's a
new Perl version will update the dpkg-dev package and with
this a Dpkg::FcntlLock submodule, wouldn't you? Well, as I
said, all this is a bit above my level;-) But since I just
got it finished and it seems to work I'll append it anyway.
(I pared it back a bit to make it smaller, so it may now be
a bit easier to read, and it's just a single .pm file meant
to be dropped into the scripts/Dpkg directory of dpkg.)

> I think the conventional way of doing what I was proposing might be:
> 
>  * Create a File::FcntlLock::XS module that loads the XS code,
>which would only contain C_fcntl_lock.
>  * Either create another module, say File::FcntlLock::Perl or ::Pure
>or similar name with the pure perl implementation, or embed the pure
>perl code in the File::FcntlLock module at build time. The former
>would in addition get rid of your CPAN upload concerns, as you could
>ship the .pm module normally.
>  * In File::FcntlLock decide which implementation to use depending on
>File::FcntlLock::XS being available or not through an evaled require.
>  * Then in Debian the File::FcntlLock::XS and corresponding .so file
>could be split into a different package.
> 
> Hope that clarifies.

Yes, I guess so. Give me a bit of time for this. The build process
could be a bit more tricky, though;-)

   Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de
# -*- cperl -*-
#
# This program is free software; you can redistribute it and/or
# modify it under the same terms as Perl itself.
#
# Copyright (C) 2002-2014 Jens Thoms Toerring 


package File::FcntlLock;

use v5.6.1;
use strict;
use warnings;
use Fcntl;
use POSIX;
use Errno;
use Carp;
use Config;
use File::Temp qw/ /;
use File::Spec;

require Exporter;

our @ISA = qw( Exporter );

# Items to export into callers namespace by default.

our @EXPORT = qw( F_GETLK F_SETLK F_SETLKW
  F_RDLCK F_WRLCK F_UNLCK
  SEEK_SET SEEK_CUR SEEK_END );


our $VERSION = '0.15';


my ( $packstr, @member_list );


###

BEGIN {
	# Create a C file in the prefered directory for temporary files for
	# probing the layout of the C 'flock struct'. Since __DATA__ can't
	# be used in a BEGIN block we've got to do this via a HEREDOC.

	my $c_file = File::Temp->new( TEMPLATE => 'File_FcntlLock-XX',
  SUFFIX   => '.c',
  DIR  => File::Spec->tmpdir( ) );

	print $c_file <
#include 
#include 
#include 
#include 
#include 


#define membersize( type, member ) ( sizeof( ( ( type * ) NULL )->member ) )
#define NUM_ELEMS( p ) ( sizeof p / sizeof *p )

typedef struct {
const char * name;
size_t   size;
size_t   offset;
}  Params;


/*-*
 * Called from qsort() for sorting an array of Params structures
 * in ascending order of their 'offset' members
 *-*/

static int
comp( const void * a,
  const void * b )
{
if ( a == b )
return 0;
return ( ( Params * ) a )->offset < ( ( Params * ) b )->offset ? -1 : 1;
}


/*-*
 *-*/

int
main( void )
{
Params params[ ] = { { "l_type",
   CHAR_BIT * membersize( struct flock, l_type ),
   CHAR_BIT * offsetof( struct flock, l_type ) },
 { "l_whence",
   CHAR_BIT * membersize( struct flock, l_whence ),
   CHAR_BIT * offsetof( 

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Guillem Jover]

On Sun, 2014-05-18 at 14:38:31 +0200, Jens Thoms Toerring wrote:
> On Sun, May 18, 2014 at 06:04:45AM +0200, Guillem Jover wrote:
> > What about, preserving the XS module, and make the code try to load it
> > and if not available, fall back to the new pure perl code? I think that
> > would palliate such concern.
> 
> That went over my head;-) Is that something I should do (I'm
> also not sure how I could check within a module if some XS
> stuff is available).

Well, I think going for now with the pure perl version would solve
our immediate problem, we could go over the rest separately. I just
mentioned it now because it would avoid dropping an then having to
reintroduce the XS code again.

> Perhaps it would be simpler in the long run to include the
> file locking stuff directly into the libdpkg-perl package
> itself, e.g. as a Dpkg::Lock sub-module. Since I'm sure I
> don't understand properly what the real problem is (sorry,
> I've never taken a good look at the way how Debian manages
> packages, that has always been white magic to me;-) I can't
> decide what the correct way to go would be. It could be pos-
> sible to 
> 
> a) add File::FcntlLock in XS form directly as Dpkg::Lock (or
>a simplified version since obviously only locks on whole
>files are required)
> b) add the pure Perl version
> c) add a version that is modified so that it determines the lay-
>out of the C flock struct somewhere in a BEGIN block by com-
>piling and running a C program and then using its output (as
>I can see libdpkg-perl requires the availability of a C com-
>piler). I'd write that for you if you like.
> 
> I don't think that this would require a lot of extra mainainance:
> I didn't had to change anything about File::FcntlLock within the
> last three years and the last serious bug was fixes about 5 years
> ago.

Because the File::FcntlLock module is generally useful, I'd rather see
it improved, instead of forking a local copy for dpkg-dev alone. I don't
think option c) would solve the issue I described, though.

I think the conventional way of doing what I was proposing might be:

 * Create a File::FcntlLock::XS module that loads the XS code,
   which would only contain C_fcntl_lock.
 * Either create another module, say File::FcntlLock::Perl or ::Pure
   or similar name with the pure perl implementation, or embed the pure
   perl code in the File::FcntlLock module at build time. The former
   would in addition get rid of your CPAN upload concerns, as you could
   ship the .pm module normally.
 * In File::FcntlLock decide which implementation to use depending on
   File::FcntlLock::XS being available or not through an evaled require.
 * Then in Debian the File::FcntlLock::XS and corresponding .so file
   could be split into a different package.

Hope that clarifies.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

On Sun, May 18, 2014 at 06:04:45AM +0200, Guillem Jover wrote:
> What about, preserving the XS module, and make the code try to load it
> and if not available, fall back to the new pure perl code? I think that
> would palliate such concern.

That went over my head;-) Is that something I should do (I'm
also not sure how I could check within a module if some XS
stuff is available).

Perhaps it would be simpler in the long run to include the
file locking stuff directly into the libdpkg-perl package
itself, e.g. as a Dpkg::Lock sub-module. Since I'm sure I
don't understand properly what the real problem is (sorry,
I've never taken a good look at the way how Debian manages
packages, that has always been white magic to me;-) I can't
decide what the correct way to go would be. It could be pos-
sible to 

a) add File::FcntlLock in XS form directly as Dpkg::Lock (or
   a simplified version since obviously only locks on whole
   files are required)
b) add the pure Perl version
c) add a version that is modified so that it determines the lay-
   out of the C flock struct somewhere in a BEGIN block by com-
   piling and running a C program and then using its output (as
   I can see libdpkg-perl requires the availability of a C com-
   piler). I'd write that for you if you like.

I don't think that this would require a lot of extra mainainance:
I didn't had to change anything about File::FcntlLock within the
last three years and the last serious bug was fixes about 5 years
ago.
   Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Guillem Jover]

Hi!

On Sun, 2014-05-18 at 01:39:12 +0200, Jens Thoms Toerring wrote:
> On Fri, May 16, 2014 at 11:06:17PM +0300, Niko Tyni wrote:
> > Would it be possible to probe for the contents of the flock struct with C
> > code at build time, and then use that information to write out a pure perl
> > module that regenerates the structs at run time (probably with pack())?
> > 
> > It would still be architecture dependent (and thus go in
> > vendorarch/sitearch) but it wouldn't need a rebuild across Perl upgrades.
> 
> I've got it to work and send atttach the new version - it's now
> a pure Perl module, created when running 'perl Makefile.PL'.
> Please let me know if this helps to solve the problem. If it
> does I'll upload it to CPAN.

Wow nice! Yes I think this would solve the issue. But I've got a slight
concern about this new approach and binary compatibility, though. The
inferred information used at build time is disconnected from the actual
function being used at run-time. This could fail or stop working if for
example, a new fcntl(3) versioned symbol was introduced that used a
different ABI (unlikely), or more probably new fcntl commands got
introduced to handle say a layout change in its struct flock, change in
member size, alignment or similar, and then perl core switched to use
that new symbol or the module kept using the old commands. We already
have seen this at least for the fcntl(2) to fcntl64(2) syscall
transition on GNU/Linux for example, which also switched userland to
transparently use F_SETLK64, F_SETLKW64 commands and friends to be able
to use the new struct flock64 and fcntl64 syscall.

What about, preserving the XS module, and make the code try to load it
and if not available, fall back to the new pure perl code? I think that
would palliate such concern.

In Debian libdpkg-perl could switch back to a strong Depends, and the
libfile-fcntllock-perl could Recommend a new -xs variant for example?

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

On Fri, May 16, 2014 at 11:06:17PM +0300, Niko Tyni wrote:
> Would it be possible to probe for the contents of the flock struct with C
> code at build time, and then use that information to write out a pure perl
> module that regenerates the structs at run time (probably with pack())?
> 
> It would still be architecture dependent (and thus go in
> vendorarch/sitearch) but it wouldn't need a rebuild across Perl upgrades.

I've got it to work and send atttach the new version - it's now
a pure Perl module, created when running 'perl Makefile.PL'.
Please let me know if this helps to solve the problem. If it
does I'll upload it to CPAN.

I've got one concern about the CPAN upload: there's no .pm file
in the package since that only gets created when 'perl Makefile.PL'
is run (that is when I can compile and run the C program that
creates the Perl code for packing/unpacking the C structure which
then is added to the other Perl code). Does anyone know if CPAN
will grok that and run 'perl Makefile.PL'? I worry that without
a .pm file CPAN won't be able to create a web page with the POD
documentation which wouldn't be very nice...

 Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


File-FcntlLock-0.15.tar.gz
Description: Binary data

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

On Fri, May 16, 2014 at 11:06:17PM +0300, Niko Tyni wrote:
> > > Unfortunately, I also
> > > don't see any way to do things without XS since the flock
> > > structure that must be passed to fcntl(2) can be quite dif-
> > > ferent on different systems, both concerning the number and
> > > ordering of its members as well as the sizes of them:-( I
> > > would love to hear ideas on how to do it differently, i.e.
> > > with Perl-only methods!
> 
> Would it be possible to probe for the contents of the flock struct with C
> code at build time, and then use that information to write out a pure perl
> module that regenerates the structs at run time (probably with pack())?
> 
> It would still be architecture dependent (and thus go in
> vendorarch/sitearch) but it wouldn't need a rebuild across Perl upgrades.

It should be possible to write a C program that determines the
relevant bits of the structure (i.e., overall size, positions
and sizes of the relevant members) and, given that information,
one should be able to automatically write out a pure Perl module.
Good idea! Never considered that since I thought when having to
use the C compiler anyway XS is the way to go (and it makes things
a bit easier). If you think this will help I'll give it a try!

   Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Niko Tyni]

On Fri, May 16, 2014 at 05:54:26PM +0200, Guillem Jover wrote:
> On Fri, 2014-05-16 at 11:05:35 +0200, Jens Thoms Toerring wrote:
> > > Long term what I think would be best would be to get File::FcntlLock
> > > into the perl core distribution, preferably upstream, but I'm not sure
> > > how such proposals are handled there and if something like that would
> > > be feasible, Jens what do you think? And/or would that be possible in
> > > Debian, maybe in the interim or regardless of perl core upstream?
> > 
> > I've never considered trying to get this module included into
> > the Perl core distribution (and I also wouldn't know how to
> > get started with something like that;-)
> 
> I'd assume a proposal needs to be sent to perl5-porters? But I've
> skimmed a bit over its archives, and I don't see anything obvious
> there. The debian-perl folks will know most probably.

I'm not aware of any documented process for this. The perl5-porters
list is certainly the right place to bring it up.

Generally, I think the aim is to make the core leaner so the bar probably
is (or at least should be) quite high. OTOH at least IO::Socket::IP did
make it in relatively recently.

I'm not very enthusiastic about including it as a Debian specific
bundling, but I'm not ruling that out totally.

> > Unfortunately, I also
> > don't see any way to do things without XS since the flock
> > structure that must be passed to fcntl(2) can be quite dif-
> > ferent on different systems, both concerning the number and
> > ordering of its members as well as the sizes of them:-( I
> > would love to hear ideas on how to do it differently, i.e.
> > with Perl-only methods!

Would it be possible to probe for the contents of the flock struct with C
code at build time, and then use that information to write out a pure perl
module that regenerates the structs at run time (probably with pack())?

It would still be architecture dependent (and thus go in
vendorarch/sitearch) but it wouldn't need a rebuild across Perl upgrades.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

On Fri, May 16, 2014 at 05:54:26PM +0200, Guillem Jover wrote:
> > ... But they might argue that you already can get
> > fcntl(2) used for locking instead of flock(2) by building Perl with
> > "-Ud_flock" (don't ask me why that's not the default anyway;-)
> > Perhaps building the Perl version distributed with Debian with
> > that option might be another solution?
> 
> I don't think switching perl in Debian to use fcntl(2) would be a good
> idea as the perl documentation states that this would change the
> semantics for the flock perl function too, which could easily break
> code around.

Yes, that would be a problem. Another way might be to convince
the Perl people to introduce a third (optional) argument to the
flock() function, allowing to specify which sort of locking is
to be used. This might also be beneficial for other purposes,
e.g., if one knows an application uses lock(3) type locking and
one writes a Perl program to interoperate with it one also has
to use that method (or both programs will get a "lock", bliss-
fully unaware that the other one is using a different locking
method of). Perhaps something like that would be easier to argue
for than the inclusion a module that is rather system-specific in
that it requires the existence of a fcntl(2) system call.

I'd be prepared to try to implement itif you think that it could
be a viable solution to the problem - perhaps at first only as a
patch to the Perl version Debian distributes. Though I can't make
any promises about that: I first have to have a goood look at the
Perl sources to see how difficult it will be - it might very well
be far beyond my skills level;-)

   Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Guillem Jover]

Hi!

On Fri, 2014-05-16 at 11:05:35 +0200, Jens Thoms Toerring wrote:
> > Long term what I think would be best would be to get File::FcntlLock
> > into the perl core distribution, preferably upstream, but I'm not sure
> > how such proposals are handled there and if something like that would
> > be feasible, Jens what do you think? And/or would that be possible in
> > Debian, maybe in the interim or regardless of perl core upstream?
> 
> I've never considered trying to get this module included into
> the Perl core distribution (and I also wouldn't know how to
> get started with something like that;-)

I'd assume a proposal needs to be sent to perl5-porters? But I've
skimmed a bit over its archives, and I don't see anything obvious
there. The debian-perl folks will know most probably.

> Unfortunately, I also
> don't see any way to do things without XS since the flock
> structure that must be passed to fcntl(2) can be quite dif-
> ferent on different systems, both concerning the number and
> ordering of its members as well as the sizes of them:-( I
> would love to hear ideas on how to do it differently, i.e.
> with Perl-only methods!

Yeah, I don't see any other way either of doing it with pure perl.

> As far as I can see I can't contribute anything useful here,
> sorry. If someone has some pointers on how to go about getting
> it into the Perl core distribution I would try that, though I'd
> rather likely need a lot of very good arguments to convince peo-
> ple deciding about such things - some of you might be in a better
> situation for that. But they might argue that you already can get
> fcntl(2) used for locking instead of flock(2) by building Perl with
> "-Ud_flock" (don't ask me why that's not the default anyway;-)
> Perhaps building the Perl version distributed with Debian with
> that option might be another solution?

I don't think switching perl in Debian to use fcntl(2) would be a good
idea as the perl documentation states that this would change the
semantics for the flock perl function too, which could easily break
code around.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jens Thoms Toerring]

Hi,

> Long term what I think would be best would be to get File::FcntlLock
> into the perl core distribution, preferably upstream, but I'm not sure
> how such proposals are handled there and if something like that would
> be feasible, Jens what do you think? And/or would that be possible in
> Debian, maybe in the interim or regardless of perl core upstream?

I've never considered trying to get this module included into
the Perl core distribution (and I also wouldn't know how to
get started with something like that;-) Unfortunately, I also
don't see any way to do things without XS since the flock
structure that must be passed to fcntl(2) can be quite dif-
ferent on different systems, both concerning the number and
ordering of its members as well as the sizes of them:-( I
would love to hear ideas on how to do it differently, i.e.
with Perl-only methods!

As far as I can see I can't contribute anything useful here,
sorry. If someone has some pointers on how to go about getting
it into the Perl core distribution I would try that, though I'd
rather likely need a lot of very good arguments to convince peo-
ple deciding about such things - some of you might be in a better
situation for that. But they might argue that you already can get
fcntl(2) used for locking instead of flock(2) by building Perl with
"-Ud_flock" (don't ask me why that's not the default anyway;-)
Perhaps building the Perl version distributed with Debian with
that option might be another solution?

Best regards, Jens
-- 
  \   Jens Thoms Toerring    j...@toerring.de
   \___  http://toerring.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Julien Cristau]

On Wed, May 14, 2014 at 19:44:45 +0200, Guillem Jover wrote:

> It is needed on NFS mounts, where the locks are going to be most needed,
> as it's easier to get into a situation that several uncoordinate remote
> systems are building the same thing in parallel, but those are also not
> portably detectable. And unfortunately this is now a Recommends only
> due to , as it was causing issues when
> introduceing new perl ABI versions.
> 
Does anyone actually do that?  (Build packages concurrently from the
same build directory on NFS)

> >  Yes, installing something in a pbuilder/cowbuilder chroot that isn't a
> > Build-Depends (or Depends of the base system) is a problem in the sense
> > that it somehow defeats the whole purpose of using a chroot for that in
> > the first place.  :)
> 
> Well, it's still just a warning, would people feel less pestered if it
> was a simple info notice? I'd be fine with this immediate compromise
> for 1.17.10, and can queue a patch for that right now.
> 
That would be just as annoying, as far as I'm concerned.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Guillem Jover]

[ CCed Jens and the Debian perl team for feedback on a proposal at
  the bottom, leaving the rest for context. ]

Hi!

On Tue, 2014-05-13 at 17:08:24 +0200, Gerfried Fuchs wrote:
> * Guillem Jover  [2012-06-17 19:46:50 CEST]:
> > On Sun, 2012-06-17 at 13:02:31 +0200, Julien Cristau wrote:
> > > Package: dpkg-dev
> > > Version: 1.16.4.2
> > > Severity: normal
> > > 
> > > dpkg-gencontrol makes annoying noise like this:
> > > dpkg-gencontrol: warning: File::FcntlLock not available; using flock 
> > > which is not NFS-safe
> > > 
> > > Please silence it.
> > 
> > But you can silence it yourself, by installing libfile-fcntllock-perl,
> > or is that a problem?
> 
>  This also affects a cowbuilder chroot and ends up in its build logs.
> Either it is needed, then it should be a Depends, or not, then it
> shouldn't blabber about it and end up in build logs.

It is needed on NFS mounts, where the locks are going to be most needed,
as it's easier to get into a situation that several uncoordinate remote
systems are building the same thing in parallel, but those are also not
portably detectable. And unfortunately this is now a Recommends only
due to , as it was causing issues when
introduceing new perl ABI versions.

>  Yes, installing something in a pbuilder/cowbuilder chroot that isn't a
> Build-Depends (or Depends of the base system) is a problem in the sense
> that it somehow defeats the whole purpose of using a chroot for that in
> the first place.  :)

Well, it's still just a warning, would people feel less pestered if it
was a simple info notice? I'd be fine with this immediate compromise
for 1.17.10, and can queue a patch for that right now.

Long term what I think would be best would be to get File::FcntlLock
into the perl core distribution, preferably upstream, but I'm not sure
how such proposals are handled there and if something like that would
be feasible, Jens what do you think? And/or would that be possible in
Debian, maybe in the interim or regardless of perl core upstream?

Otherwise, I guess I'll create a helper program in dpkg to be used by
the perl module, but that would be a slightly annoying last resort.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Raphael Hertzog]

Hi,

On Tue, 13 May 2014, Gerfried Fuchs wrote:
>  This also affects a cowbuilder chroot and ends up in its build logs.
> Either it is needed, then it should be a Depends, or not, then it
> shouldn't blabber about it and end up in build logs.
> 
>  Yes, installing something in a pbuilder/cowbuilder chroot that isn't a
> Build-Depends (or Depends of the base system) is a problem in the sense
> that it somehow defeats the whole purpose of using a chroot for that in
> the first place.  :)

FWIW, I agree that we should do something to get rid of that warning. It
hurts more than it helps. The build log pollution is very annoying.

And we have seen that installing the dependency in the build chroots is
also not desirable because it will create problems during a perl
transition.

Is there a way to detect that NFS is in use ?

If yes, then we could make the warning conditional on the usage of NFS.
Otherwise we should just silence it and document the limitation when
the module is not installed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Gerfried Fuchs]

* Guillem Jover  [2012-06-17 19:46:50 CEST]:
> On Sun, 2012-06-17 at 13:02:31 +0200, Julien Cristau wrote:
> > Package: dpkg-dev
> > Version: 1.16.4.2
> > Severity: normal
> > 
> > dpkg-gencontrol makes annoying noise like this:
> > dpkg-gencontrol: warning: File::FcntlLock not available; using flock which 
> > is not NFS-safe
> > 
> > Please silence it.
> 
> But you can silence it yourself, by installing libfile-fcntllock-perl,
> or is that a problem?

 This also affects a cowbuilder chroot and ends up in its build logs.
Either it is needed, then it should be a Depends, or not, then it
shouldn't blabber about it and end up in build logs.

 Yes, installing something in a pbuilder/cowbuilder chroot that isn't a
Build-Depends (or Depends of the base system) is a problem in the sense
that it somehow defeats the whole purpose of using a chroot for that in
the first place.  :)

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Raphael Hertzog]

Hi,

On Sun, 17 Jun 2012, Julien Cristau wrote:
> On Sun, Jun 17, 2012 at 19:46:50 +0200, Guillem Jover wrote:
> > But you can silence it yourself, by installing libfile-fcntllock-perl,
> > or is that a problem?
>
> I'm not installing anything I don't have to in any build chroot, no.

The only reason why it's not a Depends is to avoid a bootstrapping issue
when a new upstream version of Perl comes out. See #675947.

So the goal was clearly to get it installed by default.

OTOH, having it installed might forbid the chroot to be upgraded to the
new perl so it might create problems of its own when we want to switch to
a new Perl. :-|

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Julien Cristau]

On Sun, Jun 17, 2012 at 19:46:50 +0200, Guillem Jover wrote:

> On Sun, 2012-06-17 at 13:02:31 +0200, Julien Cristau wrote:
> > Package: dpkg-dev
> > Version: 1.16.4.2
> > Severity: normal
> > 
> > dpkg-gencontrol makes annoying noise like this:
> > dpkg-gencontrol: warning: File::FcntlLock not available; using flock which 
> > is not NFS-safe
> > 
> > Please silence it.
> 
> But you can silence it yourself, by installing libfile-fcntllock-perl,
> or is that a problem?
> 
I'm not installing anything I don't have to in any build chroot, no.

Cheers,
Julien



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Jonathan Nieder]

Guillem Jover wrote:
> On Sun, 2012-06-17 at 13:02:31 +0200, Julien Cristau wrote:

>> dpkg-gencontrol makes annoying noise like this:
>> dpkg-gencontrol: warning: File::FcntlLock not available; using flock which 
>> is not NFS-safe
>> 
>> Please silence it.
>
> But you can silence it yourself, by installing libfile-fcntllock-perl,
> or is that a problem?

I think Julien means on autobuilders, which do not install Recommends by
default.

Hope that helps,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Guillem Jover]

On Sun, 2012-06-17 at 13:02:31 +0200, Julien Cristau wrote:
> Package: dpkg-dev
> Version: 1.16.4.2
> Severity: normal
> 
> dpkg-gencontrol makes annoying noise like this:
> dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
> not NFS-safe
> 
> Please silence it.

But you can silence it yourself, by installing libfile-fcntllock-perl,
or is that a problem?

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'

[Julien Cristau]

Package: dpkg-dev
Version: 1.16.4.2
Severity: normal

Hi,

dpkg-gencontrol makes annoying noise like this:
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe

Please silence it.

Cheers,
Julien



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org