Date: Thu, 26 Dec 1996 14:11:30 +0000 From: Adam David <adam@veda.is> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: freebsd-ports@freebsd.org Subject: Re: bsd.port.mk on freefall Message-ID: <199612261407.OAA19775@veda.is> In-Reply-To: Your message of "Thu, 26 Dec 1996 02:53:14 PST." <199612261053.CAA06890@baloon.mimi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> * My copy back from the mailing list did not have any quoted-printable > * rubbish in it, and yours only has it where your editor inserts its own > * line-break. Therefore it must be happening at your end. > * Oh, you are asking me to shorten my lines. ;) > > No, it's your side. I have been receiving mails with even longer > lines and they don't get converted. Okay, but there is still a problem at your end. Please send me copies of the damaged message complete with headers, both your copy and the one in the archive on freefall (since I'm not getting an http connection at the moment), and we can continue to track this bug down in private. This is a separate issue from why quoted-printable is being received in the first place. Actually I had already noticed this line-break bug several weeks ago on one of the mailing lists, but I was outside the circle of the problem then and had other things on my mind. > This is probably not a big issue (it didn't happen to this mail, so > maybe it's not a persistent problem on your side), I shortened my lines to compensate, and '.' is only escaped anyway when it is found as the first character of a line. There was no line-break in that position when I sent the previous message. > * I think the same applies for 2.1.x as 2.2, right? As I understand it, > * bsd.port.mk is a key component of the ports system, and whereas ports > * cannot be guaranteed to build under a less than current system, it is > * reasonable to allow ports to build where other changes to the system > * do not prevent it. > > But freefall is not a ports build machine! ;) I would still like to be able to fetch and checksum there without taking a detour to thud. Is this unreasonable? > Let me see, when I upgrade a port, this is what I do. > > (on my machine or thud) > cvs co portname > cd portname > <cut, paste, type, hack, slash> > make fetch > make makesum > <some more cut, paste, type, hack, slash> > make clean package > make clean > cvs -q diff -u | less > cvs -q diff -u > t > scp t freefall: > (on freefall) > cvs co portname > cd portname > patch -ps < ~/t > cvs -q diff -u | less (just to be sure) > cvs commit -m 'Upgrade, now it's at 1.2b3 and can display quoted-printables!' > cd .. > cvs -Q rel -d portname That is a lot of unnecessary work for a 1-line change to the Makefile when the new version has already been tested elsewhere. > You see that "make makesum" usually happens on the ports > building/testing machine, and it actually opens up a big hole if you > aren't careful, if you do that on freefall? It is worth being aware of potential holes and pitfalls, whichever path is taken. Should the results of 'make makesum' and 'make checksum' be inconsistent between freefall and thud? At the moment, freefall omits to expand DIST_SUBDIR into files/md5. Or would you prefer to remove bsd.port.mk from freefall altogether, since it is broken there? > There. Now you explain me why you need bsd.port.mk on freefall. :) For consistency. Otherwise using cvs commit on the local machine with a remote repository on freefall seems to be the way to go. This covers all cases except where the selection of distribution files depends on the geopolitical location of the host machine (I can legally update the checksum of an export-restricted file by performing the operation within the US). > Satoshi Adam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612261407.OAA19775>