Re: rsync 5.x breakage
* David O'Brien [EMAIL PROTECTED] [2002-06-18 05:32]: On Sun, Jun 16, 2002 at 02:30:29PM +0200, Oliver Braun wrote: The problem is that sed(1) on -current fails with sed -i.bak file, if file.bak already exists, but perl does not. Please file a PR about this. done Since net/rsync/Makefile uses 3 ${REINPLACE_CMD}s on one file (rsync.h), I have removed the backup file with ${RM} file.bak between the calls. :-( I can see I should not have dropped maintainership of this port. The 3 substitutions on one file were already present when I take over maintainership. As I have written before I am not very happy with my fix. So, if you have a better solution, please let me know. BTW, why have you added BUILD_DEPENDS= perl:${PORTSDIR}/lang/perl5 to net/rsync? Only for the patches? Regards, Olli -- IST IIS _ INF _ UniBwM ___ http://ist.unibw-muenchen.de/People/obraun/ Tele-Consulting GmbH ___ http://www.tele-consulting.com/ ___ obraun@ FreeBSD: The Power To Serve http://www.freebsd.org/ ___ GnuPG: 0xEF25B1BA Fingerprint: 6A3B 042A 732E 17E4 B6E7 3EAF C0B1 6B7D EF25 B1BA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rsync 5.x breakage
[CC ports@ and current@] * Kris Kennaway [EMAIL PROTECTED] [2002-06-16 13:02]: Looks like the ${REINPLACE_CMD} patch didn't work: http://bento.freebsd.org/errorlogs/5-latest/rsync-2.5.5_1.log Fixed in PR ports/39365. But I am not very happy with that fix. The problem is that sed(1) on -current fails with sed -i.bak file, if file.bak already exists, but perl does not. Since net/rsync/Makefile uses 3 ${REINPLACE_CMD}s on one file (rsync.h), I have removed the backup file with ${RM} file.bak between the calls. == ${REINPLACE_CMD} has different semantics on -current and -stable Maintainer only using -stable won't be able to get that error and fix it _before_ submitting. The extension bak has to be hardcoded in the Makefile. This is not very sexy, and after a change of ${REINPLACE_CMD} to something like sed -i.orig this will fail again. So, what about changing sed(1) on -current to unify semantics of ${REINPLACE_CMD}? Regards, Olli -- IST IIS _ INF _ UniBwM ___ http://ist.unibw-muenchen.de/People/obraun/ Tele-Consulting GmbH ___ http://www.tele-consulting.com/ ___ obraun@ FreeBSD: The Power To Serve http://www.freebsd.org/ ___ GnuPG: 0xEF25B1BA Fingerprint: 6A3B 042A 732E 17E4 B6E7 3EAF C0B1 6B7D EF25 B1BA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rsync 5.x breakage
* Doug Barton [EMAIL PROTECTED] [2002-06-16 20:20]: Oliver Braun wrote: The problem is that sed(1) on -current fails with sed -i.bak file, if file.bak already exists, but perl does not. Since net/rsync/Makefile uses 3 ${REINPLACE_CMD}s on one file (rsync.h), I have removed the backup file with ${RM} file.bak between the calls. == ${REINPLACE_CMD} has different semantics on -current and -stable Given that we're currently discussing alternatives to REINPLACE_CMD, I would suggest that for now, not trying to switch all the ports over to it might be a good idea. OK. So, I am going to suspend my work on switching the ports maintained by ports@ to ${REINPLACE_CMD}. Or should I go on submitting patches? Regards, Olli -- IST IIS _ INF _ UniBwM ___ http://ist.unibw-muenchen.de/People/obraun/ Tele-Consulting GmbH ___ http://www.tele-consulting.com/ ___ obraun@ FreeBSD: The Power To Serve http://www.freebsd.org/ ___ GnuPG: 0xEF25B1BA Fingerprint: 6A3B 042A 732E 17E4 B6E7 3EAF C0B1 6B7D EF25 B1BA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machine/endian.h revision 1.33 breaks port x11-fm/gentoo
* Mike Barcroft [EMAIL PROTECTED] [2002-05-27 01:30]: Niels Chr. Bank-Pedersen [EMAIL PROTECTED] writes: On Sun, May 19, 2002 at 12:32:07AM +0200, Oliver Braun wrote: Hi, I am the ports maintainer of x11-fm/gentoo. Building gentoo dies since revision 1.33 of machine/endian.h with the following error: In file included from cmdseq.c:18: /usr/include/sys/wait.h:114: duplicate member `w_Filler' /usr/include/sys/wait.h:115: duplicate member `w_Retcode' /usr/include/sys/wait.h:116: duplicate member `w_Coredump' /usr/include/sys/wait.h:117: duplicate member `w_Termsig' /usr/include/sys/wait.h:132: duplicate member `w_Filler' /usr/include/sys/wait.h:133: duplicate member `w_Stopsig' /usr/include/sys/wait.h:134: duplicate member `w_Stopval' *** Error code 1 With machine/endian.h revision 1.32 it works. A workaround for x11-fm/gentoo is to declare the functions needed explicit and avoid including whole sys/wait.h. This is good. I was hoping fixing the namespace pollution in endian.h would expose more bugs. The bug in this case is that wait.h is depending on the old pollution of endian.h in the !__BSD_VISIBLE case. The solution is to use the underscored variants in wait.h. I'll commit the fix soon. I ran into another build problem later on. This time the bug was in the port itself. It was missing a string.h include, for the strdup() prototype. I think the previous GCC didn't complain about missing prototypes for built-ins, which is probably why this wasn't exposed earlier. Adding the include doesn't fix the problem because the program, via gentoo.h, specifies that it wants a POSIX environment (`#define _POSIX_C_SOURCE 3'). I think the value 3 is wrong here. The correct format is MM, which specifies the ratified date of the Standard. Nevertheless, our headers try and accomodate and provide a 1988 environment. strdup() wasn't added to POSIX until 2001. The solution would be to specify a Standard that provides the interface the application needs, or to not specify a Standard at all. The software does the latter in the NetBSD, et al cases. This patch below and the upcoming commit to sys/wait.h should fix this port. %%% --- gentoo.h.orig Sun May 26 19:20:42 2002 +++ gentoo.h Sun May 26 19:13:52 2002 @@ -13,7 +13,7 @@ #include config.h -#if !(defined __osf__ defined __alpha__) !defined __NetBSD__ +#if !(defined __osf__ defined __alpha__) !defined __NetBSD__ !defined __FreeBSD__ #define __EXTENSIONS__ #define _POSIX_C_SOURCE 3 /* This is for Solaris. */ #define POSIX_C_SOURCE3 %%% Thanks, it fixes the port. I have tested it and submitted it already. Regards, Olli -- IST IIS _ INF _ UniBwM http://ist.unibw-muenchen.de/People/obraun/ Tele-Consulting GmbH http://www.tele-consulting.com/ ___ obraun@ FreeBSD: The Power To Serve _ http://www.freebsd.org/ ___ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
machine/endian.h revision 1.33 breaks port x11-fm/gentoo
Hi, I am the ports maintainer of x11-fm/gentoo. Building gentoo dies since revision 1.33 of machine/endian.h with the following error: In file included from cmdseq.c:18: /usr/include/sys/wait.h:114: duplicate member `w_Filler' /usr/include/sys/wait.h:115: duplicate member `w_Retcode' /usr/include/sys/wait.h:116: duplicate member `w_Coredump' /usr/include/sys/wait.h:117: duplicate member `w_Termsig' /usr/include/sys/wait.h:132: duplicate member `w_Filler' /usr/include/sys/wait.h:133: duplicate member `w_Stopsig' /usr/include/sys/wait.h:134: duplicate member `w_Stopval' *** Error code 1 With machine/endian.h revision 1.32 it works. A workaround for x11-fm/gentoo is to declare the functions needed explicit and avoid including whole sys/wait.h. Has anyone an idea for a not-so-dirty hack? What could be the problem? Is this a system-wide issue or a x11-fm/gentoo -specific one? Defining __BSD_VISIBLE in cmdseq.c did not help. Regards, Olli -- IST IIS _ INF _ UniBwM http://ist.unibw-muenchen.de/People/obraun/ Tele-Consulting GmbH http://www.tele-consulting.com/ ___ obraun@ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bsd.port.mk dependency loop checking patch (Re: Who broke 'make clean' for ports ?)
* Maxim Sobolev [EMAIL PROTECTED] [2002-05-11 15:00]: KOMATSU Shinichiro wrote: (add To: [EMAIL PROTECTED]) From: Garrett Rooney [EMAIL PROTECTED] Subject: Re: Who broke 'make clean' for ports ? Date: Sat, May 11, 2002 at 02:31:32AM JST there's a circular dependency that was just introduced to gettext. gettext now depends on expat, which depends on gmake, which depends on gettext. Recently, I wrote a patch for bsd.port.mk that checks circular dependency. If a dependency loop is found, it gives you a warning and does not invoke 'make' process any further. Someone, please test the patch below. If no problem is found, I will send-pr(8). I don't think that we really need such patch. In 99.% of cases it would just waste CPU cycles. Circular dependency is a bug and as such it doesn't need to be a supported special case. But it might be a good idea to incorporate this functionality into ${PORTSDIR}/devel/portlint. Regards, Olli -- Institute for Software TechnologyInstitute for Information Systems Department of Computing Science, Federal Armed Forces University Munich --- http://ist.unibw-muenchen.de/People/obraun/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Some ports fail on -current because ${BINOWN} and ${BINGRP} seems to be not defined
* Bill Fenner [EMAIL PROTECTED] [2002-05-11 17:12]: This is presumably fallout from the /usr/share/mk rearrangement, but rev 1.306 of /usr/share/mk/bsd.port.mk should fix this. on my -current box it doesn't. The world was build last Saturday 2002-05-04, including rev 1.306 of /usr/share/mk/bsd.port.mk: $FreeBSD: src/share/mk/bsd.port.mk,v 1.306 2002/04/19 07:43:50 ru Exp $ Oh, hey, are the failing ports all ones that use bsd.port.pre.mk and bsd.port.post.mk? no, e.g. /usr/ports/audio/cam fails and uses bsd.port.mk. Regards, Olli -- Institute for Software TechnologyInstitute for Information Systems Department of Computing Science, Federal Armed Forces University Munich --- http://ist.unibw-muenchen.de/People/obraun/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Some ports fail on -current because ${BINOWN} and ${BINGRP} seems to be not defined
Hi, I am currently checking bento's port building errors on -current. I have found some ports, e.g. audio/cam [1], that could not be installed because ${BINOWN} and ${BINGRP} seems to be not defined. They end up with the error: install: -g: Invalid argument coming from things like: install -c -m 755 -o -g cam /usr/local/bin Any ideas? Any hints? Regards, Olli 1. http://bento.freebsd.org/errorlogs/5-latest/cam-1.02.log -- Institute for Software TechnologyInstitute for Information Systems Department of Computing Science, Federal Armed Forces University Munich --- http://ist.unibw-muenchen.de/People/obraun/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdout changes break some ports
* Kris Kennaway [EMAIL PROTECTED] [2002-03-31 08:48]: On Sun, Mar 24, 2002 at 05:54:36PM -0800, Kris Kennaway wrote: On Sun, Mar 24, 2002 at 06:43:13PM -0700, M. Warner Losh wrote: : David O'Brien committed a workaround to the clog port yesterday to : move the initializer to main() instead of trying to do it statically. : : Is this something which is supposed to work? No. This isn't something that is guaranteed to work per the standards, iirc. The proper fix is to put the initializer in main. OK. Someone needs to go and fix those 84 ports then. How does one fix this in a library? I've been moving the initialization to main() for applications. Unfortunately it is not so straight forward. IMO, the best solution is to initialise to NULL and test for this when called and change them to stdin and stdout where necessary. This is a little overhead but the cleanest way IMO. I heard of the possibility to do things like static FILE*fpout=NULL; #define fp (fpout?fpout:stdout) But I never tested this. I can help you a little bit changing this in the concerning libraries, if you want, since this seems to be a lot of work. Regards, Olli -- Department of Computing Science Federal Armed Forces University Munich http://ist.unibw-muenchen.de/People/obraun/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message