Re: Deprecation campaign
Hello, i noted that ucpp is deprecated because it cannot be fetched from original site. This is an alternate c preprocessor supposed to be better than the gnu one, written by Thomas Pornin. I happen to know the guy (*), so i searched if the soft had been moved, and indeed it can be found here: http://code.google.com/p/ucpp/ I hope you may reconsider your decision. With my best regards (*) i think he now runs a crypto firm in the Boston area. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
17.03.2011 02:33, Michel Talon пишет:
Hello,
i noted that ucpp is deprecated because it cannot be fetched
from original site. This is an alternate c preprocessor
supposed to be better than the gnu one, written by Thomas
Pornin. I happen to know the guy (*), so i searched if
the soft had been moved, and indeed it can be found here:
http://code.google.com/p/ucpp/
I hope you may reconsider your decision.
With my best regards
(*) i think he now runs a crypto firm in the Boston area.
I've tried to adopt the port to new distfile..
It builds but doesn't produce ucpp binary.
Maybe you or anybody can look what's wrong.
--
Regards,
Ruslan
diff -ruNa ucpp.orig/Makefile ucpp/Makefile
--- ucpp.orig/Makefile 2011-03-16 16:55:41.0 +0300
+++ ucpp/Makefile 2011-03-17 07:19:14.0 +0300
@@ -9,16 +9,16 @@
PORTNAME= ucpp
PORTVERSION= 1.3
CATEGORIES=devel
-MASTER_SITES= http://pornin.nerim.net/ucpp/
+MASTER_SITES= GOOGLE_CODE
MAINTAINER=po...@freebsd.org
COMMENT= A C preprocessor and lexer
-DEPRECATED= Upstream disapear and distfile is no more available
-EXPIRATION_DATE=2011-05-01
+LICENSE= BSD
MAN1= ucpp.1
PLIST_FILES= bin/ucpp
+USE_GMAKE= yes
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/${PORTNAME} ${PREFIX}/bin
diff -ruNa ucpp.orig/distinfo ucpp/distinfo
--- ucpp.orig/distinfo 2005-11-24 18:40:02.0 +0300
+++ ucpp/distinfo 2011-03-17 07:04:01.0 +0300
@@ -1,3 +1,2 @@
-MD5 (ucpp-1.3.tar.gz) = f6f508ab42dd3eb57c0411a25429c9e8
-SHA256 (ucpp-1.3.tar.gz) =
6057028d96d349acd3de39a83f88f5772c422f822beb7f139dca8eabcf058bfa
-SIZE (ucpp-1.3.tar.gz) = 91537
+SHA256 (ucpp-1.3.tar.gz) =
d81bff52769325497d7663356ebebb358991e4c820b43aa60c40d65a29e9c376
+SIZE (ucpp-1.3.tar.gz) = 91626
diff -ruNa ucpp.orig/files/patch-Makefile ucpp/files/patch-Makefile
--- ucpp.orig/files/patch-Makefile 2003-07-29 00:59:02.0 +0400
+++ ucpp/files/patch-Makefile 2011-03-17 07:20:24.0 +0300
@@ -1,22 +1,22 @@
Makefile.orig Wed Jan 15 02:07:44 2003
-+++ Makefile Sun Jul 27 14:51:51 2003
+--- Makefile.orig 2008-10-01 21:15:41.0 +0400
Makefile 2011-03-17 07:10:39.0 +0300
@@ -56,8 +56,8 @@
#FLAGS = -O -m -DMEM_CHECK
# for gcc
-CC = gcc
--FLAGS = -g -W -Wall -ansi -DAUDIT -DMEM_DEBUG
+-FLAGS = -O3 -W -Wall -ansi
+CC ?= gcc
+FLAGS = -ansi -DAUDIT -DMEM_DEBUG
+ #FLAGS = -g -W -Wall -ansi -DAUDIT -DMEM_DEBUG
#FLAGS = -O3 -mcpu=pentiumpro -fomit-frame-pointer -W -Wall -ansi -DMEM_CHECK
#FLAGS = -O -pg -W -Wall -ansi -DMEM_CHECK
- #LDFLAGS = -pg
-@@ -80,7 +80,7 @@
+@@ -87,7 +87,7 @@
# - nothing should be changed below this line -
COBJ = mem.o nhash.o cpp.o lexer.o assert.o macro.o eval.o
--CFLAGS = $(FLAGS) -DSTAND_ALONE
-+CFLAGS += $(FLAGS) -DSTAND_ALONE
+-CFLAGS = $(FLAGS) $(STAND_ALONE)
++CFLAGS += $(FLAGS) $(STAND_ALONE)
all: ucpp
-
+ @ar cq libucpp.a *.o
diff -ruNa ucpp.orig/pkg-descr ucpp/pkg-descr
--- ucpp.orig/pkg-descr 2002-08-19 15:44:39.0 +0400
+++ ucpp/pkg-descr 2011-03-17 07:04:49.0 +0300
@@ -6,4 +6,4 @@
- Possibility to use the code as a lexer (that outputs tokens
directly)
-WWW: http://pornin.nerim.net/ucpp/
+WWW: http://code.google.com/p/ucpp/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
For those that want to see the state of all this, you can check out the following URL: http://portsmon.freebsd.org/portsconcordancefordeprecated.py In particular, the "interesting" entries for you may be the unmaintained ports (e.g. maintainer = "po...@freebsd.org".) In some of the other cases, the maintainer had already asked for the port to be deprecated (e.g. obsolete versions of databases/postgresql, dns/bind, emulators/linux_base, etc.) If you find that any of the ports on this list are ports that you use at your site, please consider taking them over as maintainer. This would help FreeBSD out. fwiw, an email version of this will go out on the 21st via a cronjob. Thanks. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
Am 17.03.2011 05:33, schrieb Ruslan Mahmatkhanov: 17.03.2011 02:33, Michel Talon пишет: Hello, i noted that ucpp is deprecated because it cannot be fetched from original site. This is an alternate c preprocessor supposed to be better than the gnu one, written by Thomas Pornin. I happen to know the guy (*), so i searched if the soft had been moved, and indeed it can be found here: http://code.google.com/p/ucpp/ I hope you may reconsider your decision. With my best regards (*) i think he now runs a crypto firm in the Boston area. I've tried to adopt the port to new distfile.. It builds but doesn't produce ucpp binary. Maybe you or anybody can look what's wrong. Guys, all these efforts to rescue the ports are all good, but: do we actually _need_ the ports? Just having one more port isn't a value in itself. And if yes, can someone step up to become maintainer of the port, meaning, upgrade it to new versions, sort FreeBSD bug reports and forward/file them with the upstream authors, and all that? Thanks. -- Matthias Andree ports committer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
On Thu, Mar 17, 2011 at 07:33:01AM +0300, Ruslan Mahmatkhanov wrote:
> 17.03.2011 02:33, Michel Talon ??:
> >Hello,
> >
> >i noted that ucpp is deprecated because it cannot be fetched
> >from original site. This is an alternate c preprocessor
> >supposed to be better than the gnu one, written by Thomas
> >Pornin. I happen to know the guy (*), so i searched if
> >the soft had been moved, and indeed it can be found here:
> >http://code.google.com/p/ucpp/
> >I hope you may reconsider your decision.
> >
> >With my best regards
> >
> >(*) i think he now runs a crypto firm in the Boston area.
>
> I've tried to adopt the port to new distfile..
> It builds but doesn't produce ucpp binary.
> Maybe you or anybody can look what's wrong.
>
> --
> Regards,
> Ruslan
I have looked at the question.
First point is that the preprocessor is intended to be run as part of
other tools so does not produce a stand alone preprocessor. However
one may compile it to produce a stand alone executable.
Then one encounters a problem, it does not compile because there are
macros STD_MACROS and STD_ASSERT which are undefined. I have checked the
problem is the same under Linux, maybe this works under Solaris or
whatever. I have replaced that by /usr/include, but assertions don't
work, so i have disabled them. Anyways with the following patch,
one gets a preprocessor ucpp that seems to work OK.
niobe% diff Makefile.new Makefile
81c81
< STAND_ALONE = -DSTAND_ALONE
---
> #STAND_ALONE = -DSTAND_ALONE
niobe% diff cpp.c.new cpp.c
68,69c68,69
< static char *system_macros_def[] = { "/usr/include", 0 };
< static char *system_assertions_def[] = { "", 0 };
---
> static char *system_macros_def[] = { STD_MACROS, 0 };
> static char *system_assertions_def[] = { STD_ASSERT, 0 };
2367c2367
< int system_macros = 0, standard_assertions = 0;
---
> int system_macros = 0, standard_assertions = 1;
The *.new files are the files i have modified.
--
Michel TALON
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
On 2011-Mar-17, 10:26, Matthias Andree wrote: > Am 17.03.2011 05:33, schrieb Ruslan Mahmatkhanov: > > 17.03.2011 02:33, Michel Talon пишет: > >> Hello, > >> > >> i noted that ucpp is deprecated because it cannot be fetched > >> from original site. This is an alternate c preprocessor > >> supposed to be better than the gnu one, written by Thomas > >> Pornin. I happen to know the guy (*), so i searched if > >> the soft had been moved, and indeed it can be found here: > >> http://code.google.com/p/ucpp/ > >> I hope you may reconsider your decision. > >> > >> With my best regards > >> > >> (*) i think he now runs a crypto firm in the Boston area. > > > > I've tried to adopt the port to new distfile.. > > It builds but doesn't produce ucpp binary. > > Maybe you or anybody can look what's wrong. > > Guys, > > all these efforts to rescue the ports are all good, but: do we actually > _need_ the ports? Just having one more port isn't a value in itself. It's a potential value. Having one port less is a potential loss. > And if yes, can someone step up to become maintainer of the port, > meaning, upgrade it to new versions, sort FreeBSD bug reports and > forward/file them with the upstream authors, and all that? Well, this is not how it works. There are a lot of old ports which are not being developped upstreams anymore. Probably nobody is interested in maintaining those, because there's nothing to do to those ports other than fixing potential build problems. However, this doesn't imply that the port is useless or that nobody's interested in using it. Not all consumers of FreeBSD ports follow ports@. I'd be very carful on killing ports. I agree on killing BROKEN ports where the distfiles are not fetchable anymore. In this case, nobody can benefit from having the (non working) port. But I wouldn't go further. And I'd welcome ANY effort to resurrect a port or make it workable again, even if it does not imply setting a real MAINTAINER. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpfNBzlZEw61.pgp Description: PGP signature
Re: Deprecation campaign
Hi, I have finish my deprecation campaign, fill free to undeprecate what ever you thinks it is suitable to keep on the ports tree. regards, Bapt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
Am 17.03.2011 11:36, schrieb Pietro Cerutti:
all these efforts to rescue the ports are all good, but: do we actually
_need_ the ports? Just having one more port isn't a value in itself.
It's a potential value. Having one port less is a potential loss.
Unless there is another one to take over.
And if yes, can someone step up to become maintainer of the port,
meaning, upgrade it to new versions, sort FreeBSD bug reports and
forward/file them with the upstream authors, and all that?
Well, this is not how it works. There are a lot of old ports which
are not being developped upstreams anymore. Probably nobody is
interested in maintaining those, because there's nothing to do to those
ports other than fixing potential build problems. However, this doesn't
imply that the port is useless or that nobody's interested in using it.
Not all consumers of FreeBSD ports follow ports@.
But exactly in such situations ("nothing to do") being a maintainer is
an extremely low effort because you hardly ever get input, but you are
sort of a godfather to the port in case it fails. And it's prudent for
a maintainer to ask for help anyways.
I'd be very carful on killing ports. I agree on killing BROKEN ports
where the distfiles are not fetchable anymore. In this case, nobody can
benefit from having the (non working) port. But I wouldn't go further.
And I'd welcome ANY effort to resurrect a port or make it workable
again, even if it does not imply setting a real MAINTAINER.
I've done steps towards getting gpart working again, but I fear we'll be
running in circles unless ports are maintained. I've taken
maintainership of gpart now based on my own argument written above.
And while I haven't fully audited gpart or looked through its code, the
first impression was "not stellar but reasonably OK with some
portability headaches" so it's probably reasonably low profile, too.
Best regards
--
Matthias Andree
ports committer
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
===> Installing for ucpp-1.3 ===> Generating temporary packing list ===> Checking if devel/ucpp already installed install -s -o root -g wheel -m 555 /usr/home/miwi/dev/ports/devel/ucpp/work/ucpp-1.3/ucpp /usr/local/bin install: /usr/home/miwi/dev/ports/devel/ucpp/work/ucpp-1.3/ucpp: No such file or directory *** Error code 71 Stop in /usr/home/miwi/dev/ports/devel/ucpp. On Thu, Mar 17, 2011 at 12:33 PM, Ruslan Mahmatkhanov wrote: > 17.03.2011 02:33, Michel Talon пишет: > > Hello, >> >> i noted that ucpp is deprecated because it cannot be fetched >> from original site. This is an alternate c preprocessor >> supposed to be better than the gnu one, written by Thomas >> Pornin. I happen to know the guy (*), so i searched if >> the soft had been moved, and indeed it can be found here: >> http://code.google.com/p/ucpp/ >> I hope you may reconsider your decision. >> >> With my best regards >> >> (*) i think he now runs a crypto firm in the Boston area. >> > > I've tried to adopt the port to new distfile.. > It builds but doesn't produce ucpp binary. > Maybe you or anybody can look what's wrong. > > -- > Regards, > Ruslan > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
17.03.2011 20:56, Martin Wilke пишет: ===> Installing for ucpp-1.3 ===>Generating temporary packing list ===> Checking if devel/ucpp already installed install -s -o root -g wheel -m 555 /usr/home/miwi/dev/ports/devel/ucpp/work/ucpp-1.3/ucpp /usr/local/bin install: /usr/home/miwi/dev/ports/devel/ucpp/work/ucpp-1.3/ucpp: No such file or directory *** Error code 71 Stop in /usr/home/miwi/dev/ports/devel/ucpp. Yes. It doesn't produce ucpp binary for some reason as i stated earlier. There is some patches from Michel later in the thread, but i doesn't tested them yet. On Thu, Mar 17, 2011 at 12:33 PM, Ruslan Mahmatkhanovwrote: 17.03.2011 02:33, Michel Talon пишет: Hello, i noted that ucpp is deprecated because it cannot be fetched from original site. This is an alternate c preprocessor supposed to be better than the gnu one, written by Thomas Pornin. I happen to know the guy (*), so i searched if the soft had been moved, and indeed it can be found here: http://code.google.com/p/ucpp/ I hope you may reconsider your decision. With my best regards (*) i think he now runs a crypto firm in the Boston area. I've tried to adopt the port to new distfile.. It builds but doesn't produce ucpp binary. Maybe you or anybody can look what's wrong. -- Regards, Ruslan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
17.03.2011 20:56, Martin Wilke пишет:
===> Installing for ucpp-1.3
===>Generating temporary packing list
===> Checking if devel/ucpp already installed
install -s -o root -g wheel -m 555
/usr/home/miwi/dev/ports/devel/ucpp/work/ucpp-1.3/ucpp /usr/local/bin
install: /usr/home/miwi/dev/ports/devel/ucpp/work/ucpp-1.3/ucpp: No such
file or directory
*** Error code 71
Stop in /usr/home/miwi/dev/ports/devel/ucpp.
I tested it with Michel Talon patches. It now builds and work well.
Tried this patch (should be applied with -p0)
On Thu, Mar 17, 2011 at 12:33 PM, Ruslan Mahmatkhanovwrote:
17.03.2011 02:33, Michel Talon пишет:
Hello,
i noted that ucpp is deprecated because it cannot be fetched
from original site. This is an alternate c preprocessor
supposed to be better than the gnu one, written by Thomas
Pornin. I happen to know the guy (*), so i searched if
the soft had been moved, and indeed it can be found here:
http://code.google.com/p/ucpp/
I hope you may reconsider your decision.
With my best regards
(*) i think he now runs a crypto firm in the Boston area.
I've tried to adopt the port to new distfile..
It builds but doesn't produce ucpp binary.
Maybe you or anybody can look what's wrong.
--
Regards,
Ruslan
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
--
Regards,
Ruslan
diff -ruNa ucpp.orig/Makefile ucpp/Makefile
--- ucpp.orig/Makefile 2011-03-16 16:55:41.0 +0300
+++ ucpp/Makefile 2011-03-17 21:03:33.0 +0300
@@ -9,16 +9,16 @@
PORTNAME= ucpp
PORTVERSION= 1.3
CATEGORIES=devel
-MASTER_SITES= http://pornin.nerim.net/ucpp/
+MASTER_SITES= GOOGLE_CODE
MAINTAINER=po...@freebsd.org
COMMENT= A C preprocessor and lexer
-DEPRECATED= Upstream disapear and distfile is no more available
-EXPIRATION_DATE=2011-05-01
+LICENSE= BSD
MAN1= ucpp.1
PLIST_FILES= bin/ucpp
+USE_GMAKE= yes
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/${PORTNAME} ${PREFIX}/bin
diff -ruNa ucpp.orig/distinfo ucpp/distinfo
--- ucpp.orig/distinfo 2005-11-24 18:40:02.0 +0300
+++ ucpp/distinfo 2011-03-17 21:03:33.0 +0300
@@ -1,3 +1,2 @@
-MD5 (ucpp-1.3.tar.gz) = f6f508ab42dd3eb57c0411a25429c9e8
-SHA256 (ucpp-1.3.tar.gz) =
6057028d96d349acd3de39a83f88f5772c422f822beb7f139dca8eabcf058bfa
-SIZE (ucpp-1.3.tar.gz) = 91537
+SHA256 (ucpp-1.3.tar.gz) =
d81bff52769325497d7663356ebebb358991e4c820b43aa60c40d65a29e9c376
+SIZE (ucpp-1.3.tar.gz) = 91626
diff -ruNa ucpp.orig/files/patch-Makefile ucpp/files/patch-Makefile
--- ucpp.orig/files/patch-Makefile 2003-07-29 00:59:02.0 +0400
+++ ucpp/files/patch-Makefile 2011-03-17 21:06:08.0 +0300
@@ -1,22 +1,31 @@
Makefile.orig Wed Jan 15 02:07:44 2003
-+++ Makefile Sun Jul 27 14:51:51 2003
+--- Makefile.orig 2008-10-01 21:15:41.0 +0400
Makefile 2011-03-17 21:05:49.0 +0300
@@ -56,8 +56,8 @@
#FLAGS = -O -m -DMEM_CHECK
# for gcc
-CC = gcc
--FLAGS = -g -W -Wall -ansi -DAUDIT -DMEM_DEBUG
+-FLAGS = -O3 -W -Wall -ansi
+CC ?= gcc
+FLAGS = -ansi -DAUDIT -DMEM_DEBUG
+ #FLAGS = -g -W -Wall -ansi -DAUDIT -DMEM_DEBUG
#FLAGS = -O3 -mcpu=pentiumpro -fomit-frame-pointer -W -Wall -ansi -DMEM_CHECK
#FLAGS = -O -pg -W -Wall -ansi -DMEM_CHECK
- #LDFLAGS = -pg
-@@ -80,7 +80,7 @@
+@@ -78,7 +78,7 @@
+ #LIBS = libefence.a
+ #LIBS = -lgc_dbg
+
+-#STAND_ALONE = -DSTAND_ALONE
++STAND_ALONE = -DSTAND_ALONE
+
+ ifdef STAND_ALONE
+ FINAL_STEP = $(CC) $(LDFLAGS) -o ucpp $(COBJ) $(LIBS)
+@@ -87,7 +87,7 @@
# - nothing should be changed below this line -
COBJ = mem.o nhash.o cpp.o lexer.o assert.o macro.o eval.o
--CFLAGS = $(FLAGS) -DSTAND_ALONE
-+CFLAGS += $(FLAGS) -DSTAND_ALONE
+-CFLAGS = $(FLAGS) $(STAND_ALONE)
++CFLAGS += $(FLAGS) $(STAND_ALONE)
all: ucpp
-
+ @ar cq libucpp.a *.o
diff -ruNa ucpp.orig/files/patch-cpp.c ucpp/files/patch-cpp.c
--- ucpp.orig/files/patch-cpp.c 1970-01-01 03:00:00.0 +0300
+++ ucpp/files/patch-cpp.c 2011-03-17 21:08:34.0 +0300
@@ -0,0 +1,22 @@
+--- cpp.c.orig 2008-10-01 21:15:41.0 +0400
cpp.c 2011-03-17 21:08:15.0 +0300
+@@ -65,8 +65,8 @@
+ FILE *emit_output;
+
+ #ifdef STAND_ALONE
+-static char *system_macros_def[] = { STD_MACROS, 0 };
+-static char *system_assertions_def[] = { STD_ASSERT, 0 };
++static char *system_macros_def[] = { "/usr/include", 0 };
++static char *system_assertions_def[] = { "", 0 };
+ #endif
+
+ char *current_filename = 0, *current_long_filename = 0;
+@@ -2364,7 +2364,7 @@
+ char *filename = 0;
+ int with_
Re: Deprecation campaign
On Thu 17 Mar 2011 at 03:36:38 PDT Pietro Cerutti wrote: Well, this is not how it works. There are a lot of old ports which are not being developped upstreams anymore. Probably nobody is interested in maintaining those, because there's nothing to do to those ports other than fixing potential build problems. However, this doesn't imply that the port is useless or that nobody's interested in using it. Not all consumers of FreeBSD ports follow ports@. I'd be very carful on killing ports. I agree on killing BROKEN ports where the distfiles are not fetchable anymore. In this case, nobody can benefit from having the (non working) port. But I wouldn't go further. And I'd welcome ANY effort to resurrect a port or make it workable again, even if it does not imply setting a real MAINTAINER. I agree with you that a port shouldn't be deprecated simply because there hasn't been much recent activity upstream. Often that's simply an indication that the software is mature and relatively bug-free. It does not in any way imply that the software is no longer useful. (Think of all the stuff in /usr/bin that hasn't changed in years!) But I think the fact that many of the ports we're discussing in this thread had become unfetchable from the MASTER_SITES listed in their Makefiles is sufficient proof of the need for maintainers even when upstream is idling. Authors move their websites all the time, and they take their projects with them. Sometimes, perhaps as a cost-cutting measure, they shut down their self-hosted sites and move their projects to a repository like SourceForge. Or maybe they just reorganize their site, so that the downloads are now at a new address. So we see a need for a MASTER_SITES update even when the upstream author hasn't done anything that changes the distfile we need to download. If, as you say, these old ports don't require much work from a maintainer, I don't see why anyone who wants to keep them in the portstree should hesitate to put his name on them. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
On Thu, Mar 17, 2011 at 11:36:38AM +0100, Pietro Cerutti wrote: > > all these efforts to rescue the ports are all good, but: do we actually > > _need_ the ports? Just having one more port isn't a value in itself. > > It's a potential value. Having one port less is a potential loss. Potential value, but each port has a real cost: the time to deal with things such as keeping a copy of the ports tree (and, of course, trying to make packages for each port) each has a marginal cost. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
Mark Linimon wrote: For those that want to see the state of all this, you can check out the following URL: http://portsmon.freebsd.org/portsconcordancefordeprecated.py In particular, the "interesting" entries for you may be the unmaintained ports (e.g. maintainer = "po...@freebsd.org".) In some of the other cases, the maintainer had already asked for the port to be deprecated (e.g. obsolete versions of databases/postgresql, dns/bind, emulators/linux_base, etc.) If you find that any of the ports on this list are ports that you use at your site, please consider taking them over as maintainer. This would help FreeBSD out. fwiw, an email version of this will go out on the 21st via a cronjob. Thanks. mcl I understand you want to remove a port if it does not build and there is no one (in long time) to fix it. However, deprecating because a dist file moved, while port may be perfectly functional, seems a bit too much, imho. I've just glanced at the list linked above and I've noticed a few ports I've used in (not that distant) past. So I believe there are still users of them out there. So why would we deny them using the ports if all it takes is publishing the port files somewhere ? And since FreeBSD has the infrastructure and resources I see no issue in providing parking for such distfiles, especially if we believe they are used by minority of users. Or is there something I miss here ? With regards, Martin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
On 2011-Apr-26 02:02:02 +0200, martinko wrote: >I understand you want to remove a port if it does not build and there is >no one (in long time) to fix it. However, deprecating because a dist >file moved, while port may be perfectly functional, seems a bit too >much, imho. For these ports, the port as it stands does not fetch. Someone needs to update the port with the new distfile location - this is the responsibility of the port's maintainer. If a port remains broken for an extended period, it indicates that no-one cares about it any longer and therefore no-one should miss it if it's deleted. > So why would we deny them using the >ports if all it takes is publishing the port files somewhere ? And >since FreeBSD has the infrastructure and resources I see no issue in >providing parking for such distfiles, especially if we believe they are >used by minority of users. Or is there something I miss here ? Who do you see as responsible for doing this? Whilst the FreeBSD Project has resources for storing/distributing distfiles, it takes human effort to verify that the port's license allows the FreeBSD Project to host the distfile and to actually copy the distfile. That person also needs to distinguish between the cases: a) The port is up-to-date and the distfile has moved b) The project (and hence distfile) have been renamed c) The port is so out-of-date that the distfie has been removed by the vendor Whilst the effort required for a single port may not be great, the total effort to work through all the ports in this situation would be substantial. This is not the task of the port committers group. It's up to the port's users to come up with a maintainer - if none of a port's users are willing to put in the effort to ensure that the port remains usable, why should the FreeBSD Project expend scarce resources to offering that port? If there are ports on the deprecated list that you use, maybe it's up to you to step up and maintain them. -- Peter Jeremy pgpJKilSlc1fM.pgp Description: PGP signature
Re: Deprecation campaign
Peter Jeremy wrote: On 2011-Apr-26 02:02:02 +0200, martinko wrote: I understand you want to remove a port if it does not build and there is no one (in long time) to fix it. However, deprecating because a dist file moved, while port may be perfectly functional, seems a bit too much, imho. For these ports, the port as it stands does not fetch. Someone needs to update the port with the new distfile location - this is the responsibility of the port's maintainer. If a port remains broken for an extended period, it indicates that no-one cares about it any longer and therefore no-one should miss it if it's deleted. So why would we deny them using the ports if all it takes is publishing the port files somewhere ? And since FreeBSD has the infrastructure and resources I see no issue in providing parking for such distfiles, especially if we believe they are used by minority of users. Or is there something I miss here ? Who do you see as responsible for doing this? Whilst the FreeBSD Project has resources for storing/distributing distfiles, it takes human effort to verify that the port's license allows the FreeBSD Project to host the distfile and to actually copy the distfile. That person also needs to distinguish between the cases: a) The port is up-to-date and the distfile has moved b) The project (and hence distfile) have been renamed c) The port is so out-of-date that the distfie has been removed by the vendor Whilst the effort required for a single port may not be great, the total effort to work through all the ports in this situation would be substantial. This is not the task of the port committers group. It's up to the port's users to come up with a maintainer - if none of a port's users are willing to put in the effort to ensure that the port remains usable, why should the FreeBSD Project expend scarce resources to offering that port? If there are ports on the deprecated list that you use, maybe it's up to you to step up and maintain them. There are usually many users but only a few are ready to become maintainers (for whatever reasons). So no one stepping up does not really mean no one uses a port. But ok, I'll try to see what I can do for ports I might care about.. M. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
On 1 May 2011 08:31, "mato" wrote: > There are usually many users but only a few are ready to become maintainers (for whatever reasons). So no one stepping up does not really mean no one uses a port. But ok, I'll try to see what I can do for ports I might care about.. > They could always pay someone. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
On Sun, 1 May 2011 09:40:21 +0100 Chris Rees articulated: > On 1 May 2011 08:31, "mato" wrote: > > There are usually many users but only a few are ready to become > maintainers (for whatever reasons). So no one stepping up does not > really mean no one uses a port. But ok, I'll try to see what I can > do for ports I might care about.. > > > > They could always pay someone. You do realize that many here would consider that blasphemy. While it might be advantageous, like so many other capitalistic concepts, it is not likely to get a foothold in this galère. Perhaps asking the community for a list of users wishing to offer free space for hosting orphaned ports/distfiles/etcetera might be an easier crapshoot. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ May the bluebird of happiness twiddle your bits. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
On 1 May 2011 12:34, "Jerry" wrote: > > On Sun, 1 May 2011 09:40:21 +0100 > Chris Rees articulated: > > > On 1 May 2011 08:31, "mato" wrote: > > > There are usually many users but only a few are ready to become > > maintainers (for whatever reasons). So no one stepping up does not > > really mean no one uses a port. But ok, I'll try to see what I can > > do for ports I might care about.. > > > > > > > They could always pay someone. > > You do realize that many here would consider that blasphemy. While it > might be advantageous, like so many other capitalistic concepts, it > is not likely to get a foothold in this galère. No, it's not at all, but how is complaining about the state while consciously failing to do anything oneself OK? > > Perhaps asking the community for a list of users wishing to offer free > space for hosting orphaned ports/distfiles/etcetera might be an easier > crapshoot. I'll do it. Give me a list and fix the Makefiles, and I'll co-host. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
On Sun, 1 May 2011 12:45:24 +0100 Chris Rees articulated: > On 1 May 2011 12:34, "Jerry" wrote: > > > > On Sun, 1 May 2011 09:40:21 +0100 > > Chris Rees articulated: > > > > > On 1 May 2011 08:31, "mato" wrote: > > > > There are usually many users but only a few are ready to become > > > maintainers (for whatever reasons). So no one stepping up does > > > not really mean no one uses a port. But ok, I'll try to see what > > > I can do for ports I might care about.. > > > > > > > > > > They could always pay someone. > > > > You do realize that many here would consider that blasphemy. While > > it might be advantageous, like so many other capitalistic concepts, > > it is not likely to get a foothold in this galère. > > No, it's not at all, but how is complaining about the state while > consciously failing to do anything oneself OK? I have no intention of hosting any potential data, other than my own, for several reasons, not limited to the fact that my own personal servers are always in a state of flux since I am constantly doing beta testing and other projects with them. The owners of the corporate servers that I have access to would probably find it most unamusing if they found out I was using their systems for other than corporate business. > > Perhaps asking the community for a list of users wishing to offer > > free space for hosting orphaned ports/distfiles/etcetera might be > > an easier crapshoot. > > I'll do it. Give me a list and fix the Makefiles, and I'll co-host. That would be the responsibility of the each individual port maintainer. I am sure if you make it publicly known that you are offering such a service, perhaps by getting the FreeBSD webmaster to put such an advertisement up on the FreeBSD web site, you will get your wish. Good luck with your venture. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ He who has a shady past knows that nice guys finish last. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation campaign
--On May 1, 2011 7:34:06 AM -0400 Jerry wrote: On Sun, 1 May 2011 09:40:21 +0100 Chris Rees articulated: On 1 May 2011 08:31, "mato" wrote: > There are usually many users but only a few are ready to become maintainers (for whatever reasons). So no one stepping up does not really mean no one uses a port. But ok, I'll try to see what I can do for ports I might care about.. > They could always pay someone. You do realize that many here would consider that blasphemy. While it might be advantageous, like so many other capitalistic concepts, it is not likely to get a foothold in this galère. I think there was a greater underlying point. FreeBSD is a volunteer project. Lots of people would like to have all sorts of functionality that isn't presently available or save things that aren't maintained. Yet few want to volunteer to do the work. (In my experience that is normal human nature.) So I took Chris' response to mean, step up and take responsibility if you don't want it to go away. I became a port maintainer because there were things I needed that weren't available. Rather than asking someone else to do it, I took on the responsibility myself. That's how it's *supposed* to work. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
