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 l...@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
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
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 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 software' 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: Removed ports - looking from the bench
On 11 September 2011 15:35, Warren Block wbl...@wonkity.com 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
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: [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: [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
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: 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: Removed ports - looking from the bench
On Sun, 11 Sep 2011, Chris Rees wrote: On 11 September 2011 15:35, Warren Block wbl...@wonkity.com 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: [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
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
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
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Lev Serebryakov l...@freebsd.org 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
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: Removed ports - looking from the bench
On Sun, 11 Sep 2011 14:35:47 -0600 (MDT) Warren Block wbl...@wonkity.com 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
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 bsd.port.mk
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 \
+
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
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
