Bug#756629: libfile-fcntllock-perl: File::FcntlLock no longer exports the required constants
Hi Raphaël, On Thu, Jul 31, 2014 at 04:00:17PM +0200, Raphaël Hertzog wrote: Package: libfile-fcntllock-perl Version: 0.20-1 Severity: important The problem is that the constants are exported by File::FcntlLock::Core but no longer by File::FcntlLock itself. Here's a tentative patch: $ diff -u lib/File/FcntlLock.pm /usr/lib/perl5/File/FcntlLock.pm --- lib/File/FcntlLock.pm 2014-05-27 16:38:47.0 +0200 +++ /usr/lib/perl5/File/FcntlLock.pm 2014-07-31 15:50:19.454997932 +0200 @@ -22,6 +22,7 @@ bootstrap File::FcntlLock $VERSION; +our @EXPORT = @File::FcntlLock::Core::EXPORT; Thank you very much for the patch! I applied it (and made some more small changes to the XS, Pure and Inline modules which also need to export these constants). The new version 0.22 (don't use the 0.21 version, it's still missing the corrections for the XS/Pure/Inline modules) has just been uploaded to PAUSE. Please complain loudly if you find any further issues;-) 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'
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'
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'
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'
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'
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'
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, 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, 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'
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#719452: libforms-dev: xforms.info image links
Hi Kevin, On Sun, Nov 03, 2013 at 09:02:12AM +1100, Kevin Ryde wrote: Jens Thoms Toerring j...@toerring.de writes: pointing out the problem! I since had a lintian test accepted which reports various packages with this Good work! ... so you're not Robinson Crusoe :-) Even though my cat is called Friday?;-) http://lintian.debian.org/tags/info-document-missing-image-file.html I guess it's the same for them as it was for me - I never, before you brought it up, used emacs for reading info files (although I use emacs every day), so I never noticed this (and neither did any of the users of the library - or at last no-one mentioned it). But I don't seem to be in bad company;-) I definitely hope it works with the next release, at least on my machine it seems to do that now (but not perfectly - some of the larger pictures are not completely visible and I haven't found a way around that yet, that must remain a task for sometime when I have more time...) Enjoy your spring and summer down under - here it starts getting really bad, the days are getting shorter and shor- ter, all trees lost their leaves and the weather gets uglier with every day... 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#714919: libforms-bin: fdesign segfaults on sh4
Hi Paul, On Thu, Jul 04, 2013 at 05:43:35PM +0800, Paul Wise wrote: Package: libforms-bin Severity: minor As you can see here, fdesign segfaults on the sh4 port: http://buildd.debian-ports.org/status/package.php?p=mancala This seems to be fixed in the current pre-release version of Xforms (xforms-1.0.94pre18), a new release will come out some time in the near future (hopefully). 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#620634: libforms upgrade broke xmancala
Hi Paul,
On Tue, Apr 05, 2011 at 08:49:30AM +0800, Paul Wise wrote:
Please keep the Debian bug in CC.
Sorry, didn't realize that.
On Tue, 2011-04-05 at 02:25 +0200, Jens Thoms Toerring wrote:
Perhaps I also will have to ask a few more questions - I downloaded
mancala and had a short look at it but didn't figure out yet what it's
supposed to do;-)
It is a board game where you take stones out of one pit and travel
around the board placing one stone into each pit until you have no more
stones left, then the other player gets a turn. The winner can be the
first to have no stones or the one with the most stones in their end
pit.
The way that the game is broken is that clicking on a pit doesn't move
the stones around with libforms2. You can see how it should work with
the terminal-based version named mancala or by compiling xmancala
against the old libforms1.
The program was playing tricks that were too dirty;-) So I rewrote
a smal part of it (including the form designer file) to avoid doing
that and it seems to work again (and should also work with older
XForms library versions).
Instead of trying to push back a ClientMessage event into XForms
event loop (which one should do only for windows controlled by
the program independently of XForms and for which then a handler
must be installed) and sending an (except for the type) unini-
tialized XEvent (which is playing a bit of Russion roulette;-)
I added a hidden button that gets triggered to get the program
out of the event loop (which obviously was the intent of the
dirty trick used before).
I changed two files, xmain.c and xform.fd. Indirectly the latter
change also results in changes of xform.c and xform.h (they need
to be recreated using the command 'fdesign -convert xform.fd'). I
simply append all four files, if you need them in some other form
please tell me.
Best regards, Jens
--
\ Jens Thoms Toerring j...@toerring.de
\___ http://toerring.de
/* $Id: xmain.c,v 1.5 2007-06-13 18:29:52 sverrehu Exp $ */
/**
*
* FILExmain.c
* MODULE OF The board game Mancala
*
* DESCRIPTION Main function / frontend for using an X/XForms-based
* display.
*
* This code is _really_ (I mean: REALLY) dirty...
* The main purpose of this is to make someone play the
* game. For those interested in the gaming (as I am),
* please take a look at the other sourcefiles instead.
* I'm not at all proud of this file, it's my first
* attempt on using the XForms library, and it was done
* in a hurry.
*
* I don't like event driven programming...
*
* WRITTEN BY Sverre H. Huseby
*
**/
#include stdlib.h
#include stdio.h
#include stdarg.h
#include string.h
#include forms.h
#include minimax.h
#include mancala.h
#include xform.h
#define flushForms fl_check_only_forms
extern char *textRules;
/**
**
* P R I V A T ED A T A *
**
**/
static FD_mancala *frm;
static FD_rules *frmRules;
static FL_OBJECT *frmMancala[2];
static FL_OBJECT *frmHole[2][MAX_HOLES];
static FL_OBJECT *frmLight[2][MAX_HOLES];
static const char *playerName[2] = { the human player, the computer };
static intmaxPly[2] = { 0, 4 };
static intrulesDisplayed = 0;
static intstones_pr_hole = STONES_PR_HOLE;
/*
* Player side and hole chosen by human player.
*/
static Player movePlayer;
static intmoveHole = -1;
static Player player;
static intstatus;
/**
**
* P R I V A T EF U N C T I O N S *
**
**/
/*-
*
* NAME showBoard
*
* FUNCTION Display the current board on screen.
*
* DESCRIPTION Very simple thing.
*/
static void showBoard(void)
{
Player p;
intq;
char s[10];
fl_freeze_form(frm-mancala);
for (p = 0; p 2; p++) {
sprintf(s, %d, getMancala(p));
fl_set_object_label(frmMancala[p], s);
for (q = 0; q MAX_HOLES; q++) {
sprintf(s, %d, getHole(p, q
Bug#620634: libforms upgrade broke xmancala
Hi Paul, On Tue, Apr 05, 2011 at 08:07:36PM +0800, Paul Wise wrote: I'll forward your changes to the mancala upstream and update the Debian package. Thanks! BTW: do you recommend that programs based on libforms generate their .c file from the .fd file at build time instead of doing the conversion once and saving the result? I'd think that would be more clever - you safe a bit of storage and the form designer file (the one with the .fd extension) is the one that's important (and it's a PITA if someone edits the .c file and it then gets out of sync with the .fd file). To re- create the .c and .h files you just need something like %.c %.h: %.fd fdesign -convert $ in the Makefile (but that requires the .c or .h file is listed somewhere as a dependency). I append a new version of the Make- file that should do it automatically. Best regards, Jens -- \ Jens Thoms Toerring j...@toerring.de \___ http://toerring.de # $Id: Makefile,v 1.7 2007-06-13 18:29:52 sverrehu Exp $ TARGETS = mancala xmancala DIST= mancala VERMAJ = 1 VERMIN = 0 VERPAT = 1 VERSION = $(VERMAJ).$(VERMIN).$(VERPAT) CC = gcc # Common directories and libraries INCDIR = -I. LIBDIR = -L. LIBS= # Directories and libraries for X, Xpm and XForms. # If you don't have Xpm, you'll need to link with a static version of XForms. XINCDIR = -I/usr/include/X11 XLIBDIR = -L/usr/X11R6/lib XLIBS = -lXpm -lforms -lX11 -lm OPTIM = -O3 -fomit-frame-pointer CCOPT = -Wall $(OPTIM) $(INCDIR) $(XINCDIR) -DVERSION=\$(VERSION)\ LDOPT = -s $(LIBDIR) # Object files common to all programs. OBJS= minimax.o mancala.o # Object files used by xmancala XSRCS = xform.c rulestxt.c XOBJS = $(XSRCS:.c=.o) all: $(TARGETS) %.c %.h: %.fd fdesign -convert $ mancala: textmain.o $(OBJS) $(CC) $(CCOPT) -o $@ textmain.o $(OBJS) $(LDOPT) $(LIBS) xmancala: $(XOBJS) xmain.o $(OBJS) $(CC) $(CCOPT) -o $@ xmain.o $(XOBJS) $(OBJS) \ $(LDOPT) $(XLIBDIR) $(XLIBS) .c.o: $(CC) -o $@ -c $(CCOPT) $ clean: rm -f *.o core depend *~ xform.c xform.h veryclean: clean rm -f $(TARGETS) $(DIST)-$(VERSION).tar.gz chmod: chmod a+r * depend dep: $(CC) $(INCDIR) $(XINCDIR) -MM *.c depend # To let the authors make a distribution. The rest of the Makefile # should be used by the authors only. LSMFILE = $(DIST)-$(VERSION).lsm DISTDIR = $(DIST)-$(VERSION) DISTFILE= $(DIST)-$(VERSION).tar.gz DISTFILES = README INSTALL RULES $(LSMFILE) \ Makefile Makefile.bcc \ mancala.c mancala.h minimax.c minimax.h \ textmain.c \ xform.c xform.h xform.fd xmain.c rulestxt.c $(LSMFILE): FORCE VER=$(VERSION); \ DATE=`date +%d%b%y|tr '[a-z]' '[A-Z]'`; \ sed -e s/VER/$$VER/g;s/DATE/$$DATE/g $(DIST).lsm.in $(LSMFILE) FORCE: # Warning: distclean removes the lsm-file, which can not be # regenerated without the lsm.in-file, which is not part of the package. distclean: veryclean rm -f $(LSMFILE) dist: $(LSMFILE) chmod mkdir $(DISTDIR) chmod a+rx $(DISTDIR) ln $(DISTFILES) $(DISTDIR) tar -cvzf $(DISTFILE) $(DISTDIR) chmod a+r $(DISTFILE) rm -rf $(DISTDIR) ifeq (depend,$(wildcard depend)) include depend endif
Bug#620634: libforms upgrade broke xmancala
Hi Paul,
On Tue, Apr 05, 2011 at 07:26:34AM +0800, Paul Wise wrote:
I didn't notice at the time but the upgrade from libforms1 to libforms2
in Debian broke xmancala. The issue seems to be that it uses the below
trick to make fl_do_forms return something and this works with libforms1
but not with libforms2. Would you be able to take a look at this issue
and maybe give me some hints on what the right way to fix this would be?
/* Dirty trick to make fl_do_forms() return */
static void formWakeup(void)
{
XEvent xev;
xev.type = ClientMessage;
fl_XPutBackEvent(xev);
}
If you would like to see the full mancala code, download the Debian
source package using `apt-get source mancala` or visit the website:
http://shh.thathost.com/pub-unix/#Mancala
Sorry for the inconvenience. Of course, I will take a look,
but please give me a bit of time, I'm currently a bit over-
whelmed with official work. Please complain when I don't
get back to you in a few days. Perhaps I also will have to
ask a few more questions - I downloaded mancala and had a
short look at it but didn't figure out yet what it's suppo-
sed to do;-)
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#558025: Release update: transitions status and freeze, RC-bugs
Hi Adam, On Wed, May 19, 2010 at 09:32:49PM +0100, Adam D. Barratt wrote: On Mon, 2010-05-10 at 09:58 -0400, Peter S Galbraith wrote: A forthcoming new upstream version will bump the soname to fix the problem, and the few packages that depends on libforms1 will need to be rebuilt. % apt-cache rdepends libforms1 | grep -v libforms Reverse Depends: xwatch xplot xcolmix predict-gsat mancala kali jazip I maintain all but 3 of these packages. As soon as the new libforms1 is ready, I will reset bug #558025 against kali to request a rebuild, and will file bugs against the two other packages (predict-gsat, mancala). Has there been any further update on the new upstream release? I note from the bug that the hopeful timeframe was within the next couple of weeks about a week and a half ago, so apologies for chasing but it would be good to know whether this transition is imminent. I'm one of the maintainers of XForms. My appologies for breaking the packages you maintain! And, yes, I'm all set for a new release that should fix the bug. I hope that I will be able to do so on next Sunday (Mai 23rd), of course always under the condition that no new show-stopper bugs get found in the meantime... 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#558025: segfault at startup
Hi Peter, On Fri, May 07, 2010 at 09:27:29PM -0400, Peter S Galbraith wrote: Debian is getting close to a stable release and this bug is release-critical, meaning it has to be fixed. Do you recall where we are at? Should the next release of XForms fix this bug? Have you bumped the soname? as a reminder, The bug conversation is at http://bugs.debian.org/558025 Thank you for the reminder. I am hopefully close to a new release that should fix that bug, giving the library a new soname. Things had slowed down a bit due to me being busy with a new job and not too many reactions to my requests for tests of the pre-releases. But I hope very much to be able to release a new version within the next two weeks. Would that still fit into your time schedule? 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#558025: [kali] segfault at startup
On Sun, Nov 29, 2009 at 12:32:58PM -0500, Peter S Galbraith wrote: [I have added Jens Thoms Toerring j...@toerring.de, the XForms (upstream) maintainer to the CC list.] Thanks, that's a good idea! Colin Watson cjwat...@debian.org wrote: [CC: libfor...@packages.debian.org] On Sat, Nov 28, 2009 at 11:53:21AM +0200, George Danchev wrote: I can confirm that 3.1-10 crashes on startup on x86, but not on amd64. I got the source in order to rebuilt with debugging symbols on x86, but then the app started just fine. My best bet is that something has changed within the underlying libraries, also looking at ltrace output: fl_set_object_lcol(0x9e2a500, 0, 0xbfbad678, 0x804bf28, 1) = 0x9e2a500 fl_initial_wingeometry(8, 8, 220, 670, 0x37f0c7f) = 220 fl_show_form(0x9e29a68, 0, 1, 0x8051237, 0x37f0c7f unfinished ... --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ reveals that something has changed in the callback functions there. I'm curious if rebuilding on x86 would make that crash go away. Thanks, and indeed I see similar symptoms here. Rebuilding does make it go away, but I think this is really a bug in libforms1 that needs to be fixed there. It will probably involve a kali rebuild at some point, but I'd like to hear from the libforms1 maintainer first. With kali built against libforms1 1.0-8 and a version of libforms1 1.0.92sp1-5 built with debugging symbols and -O0, gdb's new reverse debugging support (yay!) quickly narrowed down the point where libforms1 jumps into space: (gdb) b fli_scale_form Function fli_scale_form not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (fli_scale_form) pending. (gdb) r Starting program: /home/cjwatson/src/debian/kali/trunk/kali/kali Breakpoint 1, fli_scale_form (form=0x807c838, xsc=1, ysc=0.99178082191780825) at forms.c:515 515 double neww = form-w_hr * xsc, (gdb) target record (gdb) c Continuing. Process record: failed to record execution log. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0001 in ?? () (gdb) reverse-stepi 0x00c86968 in handle_object (obj=0x807d090, event=22, mx=0, my=0, key=0, xev=0x0, keep_ret=1) at objects.c:2426 2426obj-posthandle( obj, event, mx, my, key, xev ); So. On investigating the diff from libforms1 1.0-8 to 1.0.92sp1-5, I notice that a bunch of new members have been inserted into the FL_OBJECT structure, namely fl1, fr1, ft1, fb1, fl2, fr2, ft2, and fb2, all before posthandle. (There are also multiple changes after posthandle.) No wonder kali is breaking. Peter, doesn't this require libforms1 to have a new SONAME, or else to clean up its interface to be ABI-compatible with previous versions (at least by only ever appending members to structs)? I sounds like the current issue requires a new soname, but I'm guessing that Jens didn't really mean to make it backwards incompatible with the previous version. So we have a window to find the issue without a new soname. What do you think Jens? That's right, the new version isn't meant to be backward compatible (several of the core data structures had to be augmented to remove bugs and improve a number of things). So, yes, a new SONAME is pro- bably in order (I wasn't aware of that being an issue until now - sorry, I haven't much practise yet with maintaining a library). I will try to figure out what I have to change to set a new SONAME and send Peter an email when I am done with it. (And many thanks Colin, for all the work!) Also from me for pointing out this problem! 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
