INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: rubygem-atoulme-Antwrap-0.7.2: no entry for /usr/ports/devel/rubygem-rjb Committers on the hook: arved cy novel pav rea thierry Most recent CVS update was: U MOVED U multimedia/Makefile ___ 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
> > ... gzip, for example, has "timestamp" field in header. > > Try this locally, without any [D]VCS: > > > > % mkdir test && echo "one" > test/one.txt && echo "two" > test/two.txt > > % tar czf test1.tar.gz test && sleep 5 && tar czf test2.tar.gz test > > % md5 test1.tar.gz test2.tar.gz > > MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec > > MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9 > > % gzip -d test1.tar.gz test2.tar.gz > > % md5 test1.tar test2.tar > > MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > > MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > > That is arguably a bug in "tar czf" :) but it is easy enough to > work around; we just need a checksum method -- e.g. SHA256_UNGZ -- > that pipes the distfile through gunzip when computing its checksum. > The problem goes beyond that: different standard tar formats can include mutable data like major and minor device numbers, and the atimes, uids, and gids of files. See, for example, tar(5). We would have to continually monitor whether each site generates tarballs with invariant checksums from the "same" files, or check the integrity of archive members after extraction. b. ___ 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"
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: rubygem-atoulme-Antwrap-0.7.2: no entry for /usr/ports/devel/rubygem-rjb Committers on the hook: arved cy pav rea thierry Most recent CVS update was: U games/angband/Makefile U games/angband/distinfo U games/angband/pkg-plist U games/ninix-aya/Makefile U games/ninix-aya/distinfo U security/fwbuilder/Makefile ___ 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"
print/afm: update for testing
Hello;
OpenOffice come with a package of 35 Adobe
Font Metric files. I think these are useful
basically for Windows but not for UNIX: am
I correct?
I did an update to print/afm so that it uses
the OOo file, which is somewhat bigger.
I am hesitating if I should submit this as print/afm
is used by hylafax and some of the names have
changed. Perhaps someone with hylafax may test
the attached patch?
best regards,
Pedro. diff -ruN afm.orig/Makefile afm/Makefile
--- afm.orig/Makefile 2011-09-11 16:47:30.0 +
+++ afm/Makefile2011-09-11 18:26:06.0 +
@@ -6,19 +6,19 @@
#
PORTNAME= afm
-PORTVERSION= 1.0
+PORTVERSION= 1.314
CATEGORIES=print
-MASTER_SITES= ftp://ftp.sgi.com/sgi/fax/source/
-DISTNAME= afm
-EXTRACT_SUFX= -tar.Z
+MASTER_SITES= ${MASTER_SITE_TEX_CTAN}
+MASTER_SITE_SUBDIR=fonts/adobe/afm
+PKGNAMEPREFIX= adobe-
+DISTNAME= Adobe-Core35_AFMs-314
MAINTAINER=po...@freebsd.org
-COMMENT= Adobe Font Metrics
+COMMENT= Adobe Core 35 AFM Files with 314 Glyph Entries
-pre-patch:
- @${RM} -rf ${WRKSRC}/RCS
-
-do-build:
- @${TRUE}
+NO_BUILD= yes
+post-extract:
+ ${INSTALL} ${FILESDIR}/Make.in ${WRKSRC}/Makefile
+
.include
diff -ruN afm.orig/distinfo afm/distinfo
--- afm.orig/distinfo 2011-09-11 16:47:30.0 +
+++ afm/distinfo2011-09-11 17:56:45.0 +
@@ -1,3 +1,2 @@
-MD5 (afm-tar.Z) = d3a69ff512639d14890b4788603ee9fb
-SHA256 (afm-tar.Z) =
5e1f566eded6bcdd2afe537b24f4b918426cb4f0d3649e23e4cb56985a7755c2
-SIZE (afm-tar.Z) = 154268
+SHA256 (Adobe-Core35_AFMs-314.tar.gz) =
6e6c53064ef6f40891ad72c06fab9f3c8fdcda80e03c9d0b21244cb1d4bf030b
+SIZE (Adobe-Core35_AFMs-314.tar.gz) = 315122
diff -ruN afm.orig/files/Make.in afm/files/Make.in
--- afm.orig/files/Make.in 1970-01-01 00:00:00.0 +
+++ afm/files/Make.in 2011-09-11 18:05:29.0 +
@@ -0,0 +1,84 @@
+# $Header: /usr/people/sam/fax/afm/RCS/Makefile,v 1.3 93/04/18 16:07:05
sam Exp $
+#
+# FlexFAX Facsimile Software
+#
+# Copyright (c) 1990, 1991, 1992, 1993 Sam Leffler
+# Copyright (c) 1991, 1992, 1993 Silicon Graphics, Inc.
+#
+# Permission to use, copy, modify, distribute, and sell this software and
+# its documentation for any purpose is hereby granted without fee, provided
+# that (i) the above copyright notices and this permission notice appear in
+# all copies of the software and related documentation, and (ii) the names of
+# Sam Leffler and Silicon Graphics may not be used in any advertising or
+# publicity relating to the software without the specific, prior written
+# permission of Sam Leffler and Silicon Graphics.
+#
+# THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY
+# WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+#
+# IN NO EVENT SHALL SAM LEFFLER OR SILICON GRAPHICS BE LIABLE FOR
+# ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND,
+# OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
+# WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF
+# LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+# OF THIS SOFTWARE.
+#
+
+#
+# This directory contains Adobe font metric files for the most
+# common PostScript fonts. They were obtained from the dvips
+# distribution that is available on ftp.uu.net (use
+#
+# site index dvipsafm
+#
+# to locate them). Note the copyright on them. Note that the
+# lptops program expects them to reside in files without a ".afm"
+# suffix.
+#
+AFMDIR=${PREFIX}/lib/afm
+INSTALL=install
+
+AFMFILES=\
+ Courier-Bold.afm\
+ Courier-BoldOblique.afm \
+ Courier-Oblique.afm \
+ Courier.afm \
+ Helvetica-Bold.afm \
+ Helvetica-BoldOblique.afm \
+ Helvetica-Narrow.afm\
+ Helvetica-NarrowBold.afm\
+ Helvetica-NarrowBoldOblique.afm \
+ Helvetica-NarrowOblique.afm \
+ Helvetica-Oblique.afm \
+ Helvetica.afm \
+ ITCAvantGarde-Book.afm \
+ ITCAvantGarde-BookOblique.afm \
+ ITCAvantGarde-Demi.afm \
+ ITCAvantGarde-DemiOblique.afm \
+ ITCBookman-Demi.afm \
+ ITCBookman-DemiItalic.afm \
+ ITCBookman-Light.afm\
+ ITCBookman-LightItalic.afm \
+ ITCZapfChancery-MediumItalic.afm\
+ NewCenturySchlbk-Bold.afm \
+ NewCenturySchlbk-BoldItalic.afm \
+ NewCenturySchlbk-Italic.afm \
+ NewCenturySchlbk-Roman.afm \
+ Palatino-Bold.afm
Re: Removed ports - looking from the bench
On Sun, 11 Sep 2011 14:35:47 -0600 (MDT) Warren Block wrote: > If archival of old historical distfiles is needed, that's not really > a FreeBSD problem. Start a new project with its own website. Quick, > somebody register deadports.org![4] LOL. Love the name! Wonder if it's already taken. :-) -- Conrad J. Sabatier conr...@cox.net ___ 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: Removed ports - looking from the bench
On 09/11/2011 13:35, Warren Block wrote: > Let me suggest a reasonable[1] plan: No. :) No more talking is necessary. Doing is necessary (or not, doesn't really matter to me at this point). I think Chris is right, a reasonable first step is a Handbook section on "How to recover a port from the CVS Attic." Beyond that if users want to get together and implement Carsten's idea, or another similar service, go for it! But at this point there is no more utility in continuing to talk about this topic. Everyone has said what they have to say, often numerous times, and there has been way more heat than light shed on the topic for some time now (as evidenced by Conrad's recent post where he realized that the issue is not nearly as dire as he thought it was after taking a look at what is actually happening). Time to move on, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Lev Serebryakov wrote: > ... gzip, for example, has "timestamp" field in header. > Try this locally, without any [D]VCS: > > % mkdir test && echo "one" > test/one.txt && echo "two" > test/two.txt > % tar czf test1.tar.gz test && sleep 5 && tar czf test2.tar.gz test > % md5 test1.tar.gz test2.tar.gz > MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec > MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9 > % gzip -d test1.tar.gz test2.tar.gz > % md5 test1.tar test2.tar > MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 That is arguably a bug in "tar czf" :) but it is easy enough to work around; we just need a checksum method -- e.g. SHA256_UNGZ -- that pipes the distfile through gunzip when computing its checksum. ___ 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"
CFT: security/openssh-portable 5.8p2
After became a new maintainer of security/openssh-portable, I updated it to 5.8p2 version. My paches fixes several problems repoted to this port: - ports/144597: Kerberos knob work again - ports/150493: Port updated to (almost) recent version - ports/160389: Port build fine on FreeBSD 9.x - ports/156926: Suffix isn't changed with knobs Next problem can't be fixed: - ports/155456: LPK patch wasn't updated upstream Current snapshot can be downloaded from: https://github.com/downloads/Roorback/mgk_ports/openssh-portable-5.8p2-t1.shar Anyone who have time and desire, please check if everything is working in this port and report bugs to me. ___ 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"
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: rubygem-atoulme-Antwrap-0.7.2: no entry for /usr/ports/devel/rubygem-rjb Committers on the hook: arved pav rea thierry Most recent CVS update was: U devel/Makefile U devel/rubygem-atoulme-antwrap/Makefile U devel/rubygem-atoulme-antwrap/distinfo U devel/rubygem-atoulme-antwrap/pkg-descr U java/Makefile U java/rubygem-rjb/Makefile U java/rubygem-rjb/distinfo U java/rubygem-rjb/pkg-descr U mail/offlineimap/Makefile U mail/offlineimap/distinfo U mail/offlineimap/pkg-plist U mail/offlineimap/files/patch-docs-MANUAL.rst U sysutils/pefs-kmod/files/patch-pefs_vnops.c U www/tt-rss/Makefile U www/tt-rss/distinfo ___ 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Sun, Sep 11, 2011 at 01:01:31PM +0400, Lev Serebryakov wrote: > Hello, Perryh. > You wrote 11 сентября 2011 г., 10:05:59: > > > I can't address the non-specific "etc", but I would claim that each > > of those 3 specific examples is a VCS bug. Creating a tarball of a > > particular content set _should_ be a deterministic process: > Once again: gzip, for example, has "timestamp" field in header. Try > this locally, without any [D]VCS: > > % mkdir test && echo "one" > test/one.txt && echo "two" > test/two.txt > % tar czf test1.tar.gz test && sleep 5 && tar czf test2.tar.gz test > % md5 test1.tar.gz test2.tar.gz > MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec > MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9 > % gzip -d test1.tar.gz test2.tar.gz > % md5 test1.tar test2.tar > MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 > % Now try the same with the -n option :) (and yes, I realize that you are probably aware of this, but so should any author of a system that automatically creates compressed tarballs out of not-ridigly-structured data) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. signature.asc Description: Digital signature
Re: Removed ports - looking from the bench
On Sun, 11 Sep 2011, Chris Rees wrote: On 11 September 2011 15:35, Warren Block wrote: On Sun, 11 Sep 2011, Greg Byshenk wrote: On Sat, Sep 10, 2011 at 01:05:49PM -0600, Chad Perrin wrote: Why? Because, in the cases here under discussion, there is somethin "wrong" (for some value of 'wrong') with the software in question. I can't speak for Matthias or Chris, but I think the point here is that (at least some) people don't want to make foot-shooting easier. Slippery slope: consider PHP, or Apache, or any MTA. Or newfs. No. PHP, Apache and the MTAs are maintained. Newfs is not buggy. There is "something "wrong" (for some value of 'wrong')" with all of these. newfs will easily overwrite an existing filesystem, for example. That's the slope, the degree to which ports or FreeBSD is going to go to assume ignorance on the part of the user and protect them from themselves. Historical precedent is to inform the user about problems but otherwise assume they know what they're doing. Certainly that's wrong at times, but the other way is the road to "That's dangerous and therefore not allowed." Whether there's overt questioning or security through obscurity, there is no way for the software to take on the responsibilities of the operator. Straw men are the tool of someone who has no more valid points to make, remember that. As is calling a point a straw man rather than addressing it. Probably neither is quite right. Let me suggest a reasonable[1] plan: Modify portdowngrade[2] or create another tool[2] to retrieve removed ports. Show the scary reason for removal before getting files from CVS. The user acknowledges that implicitly by retrieving files, or explicitly by answering an "Are you really, really, ultra-double sure?" question. The existence of this tool satisfies[3] users who want to install old ports. Continue the removal of dead ports as it has been going. If archival of old historical distfiles is needed, that's not really a FreeBSD problem. Start a new project with its own website. Quick, somebody register deadports.org![4] [1] All reasonableness is subjective. [2] Not it! [3] Well, no, some people won't be satisfied, ever. But this would address the problem and might mollify or assuage or assistify. [4] There may be something out there already that can be used. In fact, I think we'd all be surprised if there wasn't.___ 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: LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
* Dmitry Marakasov (amd...@amdmi3.ru) wrote: The patch is ready: http://people.freebsd.org/~amdmi3/ldflags.patch While it's mostly a bunch of similar changes, I'd like community eyes on specific important parts, namely Mk/ changes, python and ruby and generally all := assigns of *FLAGS, as these are dangerous (may refer variables which were not yet defined or which are changed later. However, I don't see any other way to prepend values instead of appending). -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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: [RFC] New ports idea: github / gitorious / bitbucket
On Sun, 2011-09-11 at 23:52 +0400, Ruslan Mahmatkhanov wrote: > Ruslan Mahmatkhanov wrote on 11.09.2011 23:50: > > > > We will see that anyway - when user will try to extract changed > > distfile, he will get warning about incorrect checksum, so this is not > > the case, i believe. > > s/warning/error/g > > this error will stops the build. > Of course. I am not worried about the user, but from a maintainer's point of view it is helpful to get informed about that. Unless you check all your port's distfile hashes all the time it takes some time to discover if you have a bad mirror (and all other mirrors being fine). ___ 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: [RFC] New ports idea: github / gitorious / bitbucket
Ruslan Mahmatkhanov wrote on 11.09.2011 23:50: We will see that anyway - when user will try to extract changed distfile, he will get warning about incorrect checksum, so this is not the case, i believe. s/warning/error/g this error will stops the build. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: [RFC] New ports idea: github / gitorious / bitbucket
C-S wrote on 11.09.2011 17:23: Sure it worth. From my POV, maintainer should be avoided the pleasure to mess with selfhosted and selfpackaged tarballs as much as possible. Besides of inconvenience it also less reliable (both in availability and security aspects). I'm perfectly happy to mirror anything if needed, by the way. Chris Selfhosting can be very helpful. I once had many downloads of hiawatha from my server in my logs. So, I checked the hashes and discovered that the distfile from the original homepage was not the same anymore. The author of hiawatha had changed the file without any announcements... Carlo We will see that anyway - when user will try to extract changed distfile, he will get warning about incorrect checksum, so this is not the case, i believe. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: Removed ports - looking from the bench
Just a case study. I was updating today, turns out print/mgv was deleted, so I switched to print/gv. The end. The current port deletion policy needs no change. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: Removed ports - looking from the bench
On 11 September 2011 15:35, Warren Block wrote: > On Sun, 11 Sep 2011, Greg Byshenk wrote: >> >> On Sat, Sep 10, 2011 at 01:05:49PM -0600, Chad Perrin wrote: >>> >>> Why? >> >> Because, in the cases here under discussion, there is somethin "wrong" >> (for some value of 'wrong') with the software in question. I can't >> speak for Matthias or Chris, but I think the point here is that (at >> least some) people don't want to make foot-shooting easier. > > Slippery slope: consider PHP, or Apache, or any MTA. Or newfs. No. PHP, Apache and the MTAs are maintained. Newfs is not buggy. Straw men are the tool of someone who has no more valid points to make, remember that. 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: Removed ports - looking from the bench
On Sun, 11 Sep 2011, Greg Byshenk wrote: On Sat, Sep 10, 2011 at 01:05:49PM -0600, Chad Perrin wrote: Why? Because, in the cases here under discussion, there is somethin "wrong" (for some value of 'wrong') with the software in question. I can't speak for Matthias or Chris, but I think the point here is that (at least some) people don't want to make foot-shooting easier. Slippery slope: consider PHP, or Apache, or any MTA. Or newfs. Someone who can't figure out how to install some software if it takes more than 'portinstall ' almost certainly isn't knowledgeable enough to evaluate the risks of installing buggy, exploitable, or unmaintained software. The ports system and FreeBSD in general are not capable of accurately assessing a user's abilities or situation. Informing the user of problems with a port is certainly within the scope of the ports system, or a hypothetical "bring back a removed port" tool. But the responsibility for the installation and use of any software is all on the informed user. The difficulty or ease of bringing back a removed port does not change that. ___ 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: [RFC] New ports idea: github / gitorious / bitbucket
>Sure it worth. From my POV, maintainer should be avoided the pleasure to > mess with selfhosted and selfpackaged tarballs as much as possible. > Besides of inconvenience it also less reliable (both in availability and > security aspects). > > > I'm perfectly happy to mirror anything if needed, by the way. > > > > Chris > Selfhosting can be very helpful. I once had many downloads of hiawatha from my server in my logs. So, I checked the hashes and discovered that the distfile from the original homepage was not the same anymore. The author of hiawatha had changed the file without any announcements... Carlo ___ 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: Removed ports - looking from the bench
On Sat, Sep 10, 2011 at 01:05:49PM -0600, Chad Perrin wrote: > On Sat, Sep 10, 2011 at 06:48:30PM +0100, Chris Rees wrote: > > On 10 September 2011 18:15, Chad Perrin wrote: > > > On Sat, Sep 10, 2011 at 04:45:02PM +0200, Matthias Andree wrote: > > >> > > >> I want to make installing dead ports harder for users. > > > > > > Why? > > > > Someone who wants to install a port that has been deprecated and > > removed should really have enough skills to check a port out of the > > Attic at least-- it's one command line. I don't see how much simpler > > it could get: > > This does not answer my question. I find the very concept of wanting to > make it harder for a user to install software bizarre. I could > understand wanting to achieve some other goal, and suffering the > unfortunate case of making it harder to install something, but I do not > understand the simple fact of wanting to make life harder for others, > unless it is a matter of pure spite. Thus my question: > > Why? Because, in the cases here under discussion, there is somethin "wrong" (for some value of 'wrong') with the software in question. I can't speak for Matthias or Chris, but I think the point here is that (at least some) people don't want to make foot-shooting easier. Someone who can't figure out how to install some software if it takes more than 'portinstall ' almost certainly isn't knowledgeable enough to evaluate the risks of installing buggy, exploitable, or unmaintained software. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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 Port: clamsmtp-1.10_3
Hello clsung, sorry that I don't know your right name, so I used prefix of your email address. I want to tell you that the download address of clamsmtp has changed. It is now http://thewalter.net/stef/software/clamsmtp/clamsmtp-1.10.tar.gz and not http://memberwebs.com/stef/software/clamsmtp/clamsmtp-1.10.tar.gz Best regards and thanks for porting Juergen ___ 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Hello, Perryh. You wrote 11 сентября 2011 г., 10:05:59: > I can't address the non-specific "etc", but I would claim that each > of those 3 specific examples is a VCS bug. Creating a tarball of a > particular content set _should_ be a deterministic process: Once again: gzip, for example, has "timestamp" field in header. Try this locally, without any [D]VCS: % mkdir test && echo "one" > test/one.txt && echo "two" > test/two.txt % tar czf test1.tar.gz test && sleep 5 && tar czf test2.tar.gz test % md5 test1.tar.gz test2.tar.gz MD5 (test1.tar.gz) = 7b7c763a9d1d4edca7b5b415ab297fec MD5 (test2.tar.gz) = 703ac5387b2bd1146434516f1d761ed9 % gzip -d test1.tar.gz test2.tar.gz % md5 test1.tar test2.tar MD5 (test1.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 MD5 (test2.tar) = 0ba33aa8ff6bffeeeb2d96efc38eec85 % -- // Black Lion AKA Lev Serebryakov ___ 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"
