Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
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'
-=| 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'
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'
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, 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'
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'
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'
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'
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'
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'
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'
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'
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'
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'
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 j...@toerring.de
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 EOF;
#include stdio.h
#include stddef.h
#include stdlib.h
#include string.h
#include fcntl.h
#include limits.h
#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 ),
Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
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'
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'
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: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
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'
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'
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'
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
