news/nn: proposed fix to "From:" header
[I wonder if there are more than three users of the nn port...]
The nn-6.7.3 port generates broken From: headers because of
patch-an to nntp.c. I'm not certain, but I think it's because
some ifdefs in earlier versions of the base code were removed
before 6.7.3 was released, and the patch was not updated to
take that into account.
Here's the result of patch-an as it stands today:
static void
gen_frompath(void)
{
struct passwd *passwd;
char *domain;
const char *fromFormat = "From: <[EMAIL PROTECTED]>\r\n";
passwd = getpwuid(getuid());
fprintf(nntp_out, "From: ");
fprintf(nntp_out, "%s ", full_name());
domain = find_domain(DOMAIN_FILE);
if (domain == NULL) {
fprintf(nntp_out, fromFormat,
passwd->pw_name,
host_name);
} else {
fprintf(nntp_out, fromFormat,
passwd->pw_name,
domain);
}
[...]
}
As you can see, this results in a From: line that looks like:
From: Some User From: <[EMAIL PROTECTED]>
(It's likely this problem will be evident in the From: line of
this very message)
The find_domain() code (to obtain the domain name from a file)
seems to have been added as part of the FreeBSD port and is not
part of the base nn distribution. The use of "char *domain;" in
gen_frompath() obscures the global of the same name, which is
already set via set_domain().
set_domain() already has provisions for obtaining the local
domain name in various ways (local hostname, resolv.conf, etc.)
and respects HIDDENNET for those cases. (yes, I realize HIDDENNET
doesn't have a knob in the port Makefile, yet)
While I'm fixing the immediate problem (incorrect From: line format),
I'd like to modify the FreeBSD-specific implementation of find_domain()
and make it part of set_domain(), so that if a domain is not specified
in the domain file it can fall back to the assortment of mechanisms
in set_domain().
Does anyone have thoughts on this approach?
--
G. Paul Ziemba
FreeBSD unix:
11:46PM up 4 days, 14:09, 13 users, load averages: 0.20, 0.21, 0.21
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gimpshop howto start?
Hi I posted this to the gimp mailing list but the list seems to have a v. low activity and few postings. There is no reply so far. So hopefully there is someone here who can point me in the right direction. I have installed ports/gimpshop on Freebsd 6.1. I want to compare its functionality with photoshop with which I am extremely familar and use extensively on my Win XP system. I have started gimp and have two newbie questions. 1. How do I get to start gimpshop? The docs seem to have detailed documentation but although I have searched -- I seem unable to find anything that tells me how to get the gimpshop interface running :-( 2. I found that gimp will itself will open *.jpg but does not open raw files - In my case in need to be able to open canon raw files *.cr2 and would also like to be able to open photoshop *.psd files. Here is a list of the relevant gimp packages installed and OS version info: # pkg_info |grep gimp gimp-2.2.15,2 The "meta-port" for The Gimp gimp-help-0.12 GIMP user's manual gimp-print-4.2.7_3 GIMP Print Printer Driver gimpshop-2.2.11_5 GIMP fork resembling Adobe Photoshop # uname -a FreeBSD --- 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:15:57 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP amd64 Thanks in advance david ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: experimental qemu-devel port update, please test!
In article <[EMAIL PROTECTED]> you write: >0n Thu, Jul 05, 2007 at 10:31:29PM -0500, Eric Anderson wrote: > >>On 07/02/07 15:30, Juergen Lock wrote: >>> Looks like its time for this again... Many bugs have been fixed, >>> some features have been added, like, qemu-system-arm has grown >>> emulation of a few PDAs like some Zaurus models, etc. As always, >>> please test now, before I commit this, so we won't be in for >>> nasty surprises afterwards... >> >>Works great so far on -CURRENT, thanks! >>Did the vmwarevga thing ever settle down, and become stable? > >Whats the "vmwarevga thing" ? vmware svga emulation (so, display), enabled via -vmwarevga in qemu cvs and the -devel port. xorg knows it as Driver "vmware", and there are drivers for windows too. This seems to work mostly, tho sometimes the mouse cursor jumps into the bottom right corner for me with a linux guest, and it still causes FreeBSD guests failing to attach the default nic (ed0) and pcm0 (snd_es137x, only active when passing -soundhw es1370 to qemu.) Juergen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: experimental qemu-devel port update, please test!
In article <[EMAIL PROTECTED]> you write: >On 07/05/07 22:31, Eric Anderson wrote: >> On 07/02/07 15:30, Juergen Lock wrote: >>> Looks like its time for this again... Many bugs have been fixed, >>> some features have been added, like, qemu-system-arm has grown >>> emulation of a few PDAs like some Zaurus models, etc. As always, >>> please test now, before I commit this, so we won't be in for >>> nasty surprises afterwards... >> >> Works great so far on -CURRENT, thanks! >> >> Did the vmwarevga thing ever settle down, and become stable? > > > >Although now I have the issue where using kqemu-kmod causes my system to >reboot or power off. :( > >Any ideas? This seems to be a -current issue, it doesn't happen for me at least (6.2 and previously also 6.1.) You could check if it is dependent on the version of the used qemu (the 0.9.0 port, the version of qemu-devel in ports, or the not-yet-committed updated I posted), but I doubt it. What may help is finding out which commit to -current started kqemu to break (find an older version that worked, then binary-search), or at least a backtrace from a kernel compiled without -fomit-frame-pointer (putting DDB in the config seems to do that for amd64 at least, but rebuild the entire kernel.) There also is an open issue for kqemu on amd64 smp, http://www.freebsd.org/cgi/query-pr.cgi?pr=113430 dunno if its related... Juergen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keeping track of automatically installed dependency-only ports
Doug Barton said: > Jeremie Le Hen wrote: > > Hi, > > > > Is there a way to track dependency-only ports, so that if I install > > port0 which requires port1 which in turn requires port2 and so on, > > deinstalling port0 will deinstall portN up to the first one required > > by > > another port or one I explicitely installed. > > I realize that this is an old post, but the thread it generated > indicated that there is demand for this kind of functionality, and no > solutions were presented that I could see. > > Portmaster actually has what I believe you are looking for. Finding installed packages which have no REQUIRED_BY is easy, portmaster do it, check_pkg.py do it, but i don't think this is the solution of the problem. For example, port1 may require port2 which itself requires port3. Assume you remove port1, and that, as a consequence port2 and port3 are no more necessary. It is only port2 which has an empty REQUIRED_BY, as long as you have not removed port2, port3 mentions it in REQUIRED_BY. So the deletion should have to be recursive. Moreover on a large installation you may have a large number of ports that should be removed and should require user approval to do so. But it is hard to remember several months after the fact, if a port without REQUIRED_BY has been installed as a dependency or for a precise reason. The only reliable way to detect ports which have been installed as a dependency is to create a database indicating which ports have been required by the end user, and which ones have been automatically installed. Such a database doesn't exist in the FreeBSD ports system, and as a consequence, it cannot do a good job of cleaning the installed packages. Moreover due to the tendency of some "configure" scripts to detect automatically installed libraries and behave accordingly, the presence of unwanted and uncleaned ports may be not only a small inconvenience, but may have bad consequences. So i think it should be wise to introduce a database as indicated above, in the same way it has been introduced in aptitude as an enhancement of apt-get. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gimpshop howto start?
David Southwell wrote: I posted this to the gimp mailing list but the list seems to have a v. low activity and few postings. There is no reply so far. So hopefully there is someone here who can point me in the right direction. This type of question rather belongs to [EMAIL PROTECTED] I've CC'd that list. 1. How do I get to start gimpshop? The docs seem to have detailed documentation but although I have searched -- I seem unable to find anything that tells me how to get the gimpshop interface running :-( You mean how to start up the program itself? Open an xterm (or aterm, eterm or...) and type 'gimpshop' at the prompt... 2. I found that gimp will itself will open *.jpg but does not open raw files - In my case in need to be able to open canon raw files *.cr2 and would also like to be able to open photoshop *.psd files. Gimp can open and save *.psd files. Gimp can open several types of raw files, but I don't know if *.cr2 is supported. # pkg_info |grep gimp [...] gimpshop-2.2.11_5 GIMP fork resembling Adobe Photoshop --> Gimpshop is an autonomous application (see above). HTH, Philipp -- www.familie-ost.info/~pj ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keeping track of automatically installed dependency-only ports
Michel Talon wrote: > Doug Barton said: > >> Jeremie Le Hen wrote: >>> Hi, >>> >>> Is there a way to track dependency-only ports, so that if I >>> install port0 which requires port1 which in turn requires port2 >>> and so on, deinstalling port0 will deinstall portN up to the >>> first one required by another port or one I explicitely >>> installed. >> I realize that this is an old post, but the thread it generated >> indicated that there is demand for this kind of functionality, >> and no solutions were presented that I could see. >> >> Portmaster actually has what I believe you are looking for. > > Finding installed packages which have no REQUIRED_BY is easy, > portmaster do it, check_pkg.py do it, but i don't think this is the > solution of the problem. Ok, thanks for clarifying how you see the problem. :) > For example, port1 may require port2 which itself requires port3. > Assume you remove port1, and that, as a consequence port2 and port3 > are no more necessary. It is only port2 which has an empty > REQUIRED_BY, Until you remove port2. > as long as you have not removed port2, port3 mentions it in > REQUIRED_BY. So the deletion should have to be recursive. The 'portmaster -s' function is indeed recursive, for exactly the reason you suggest. > Moreover on a large installation you may have a large number of > ports that should be removed and should require user approval to do > so. But it is hard to remember several months after the fact, if a > port without REQUIRED_BY has been installed as a dependency or for > a precise reason. I tend to disagree with you here, but since this is a matter of opinion, I'll agree to disagree. :) > The only reliable way to detect ports which have been installed as > a dependency is to create a database *shudder* You just tripped over your own argument here. There are plenty of ways that we could recognize a port that was installed as a dependency. The one that comes immediately to mind is to create a flag file in /var/db/pkg/foo (or /var/db/ports/foo) to indicate that the port was installed as a dependency. It would be trivial for portmaster and portupgrade to do this, slightly more complicated for it to be done in bsd.port.mk, but not impossible. > indicating which ports have been required by the end user, and > which ones have been automatically installed. Well, what happens if an application (rather than a library) gets installed as a dependency, but you decide that you like that application, and want to keep it? How do you "promote" something from "dependency installed" to "user installed?" Personally I think that portmaster's approach is the right one. If you accidentally delete something that it turns out you really do need, you can always install it again. On the other hand, the presence of an empty +REQUIRED_BY file is a very reliable indication that something was previously installed as a dependency, but is no longer needed. I'd be interested to hear if others have opinions about this ... Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: news/nn: proposed fix to "From:" header
G. Paul Ziemba writes: >[I wonder if there are more than three users of the nn port...] I use nn on FreeBSD, but I haven't used the ports version in some time, because I've hacked the version I use too heavily to use the ports version as a starting point. But I appreciate your efforts nonetheless. -- J. Porter Clark <[EMAIL PROTECTED]> ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: graphics/jasper 1.900.1_3 added libglut dependency: Now requires X11: Why?
I am running a server without X11. I use ImageMagick-nox11-6.3.3.5_1 and GraphicsMagick-nox11-1.1.7_1 on this server. The line "USE_GL= glut" was added to the Makefile on the last update. This port now requires X11. Why was this done? It compiles and installs OK without that line. It seems to work OK. Bill ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keeping track of automatically installed dependency-only ports
On Sat, Jul 07, 2007 at 09:57:59AM -0700, Doug Barton wrote: > > > The only reliable way to detect ports which have been installed as > > a dependency is to create a database > > *shudder* You just tripped over your own argument here. There are > plenty of ways that we could recognize a port that was installed as a > dependency. The one that comes immediately to mind is to create a flag > file in /var/db/pkg/foo (or /var/db/ports/foo) to indicate that the > port was installed as a dependency. It would be trivial for portmaster > and portupgrade to do this, slightly more complicated for it to be > done in bsd.port.mk, but not impossible. > I agree completely with you. Of course when i say that a database has to be created, this may very well be reduced to a flag somewhere in /var/db/pkg. For me, /var/db/pkg is a database describing the installed ports. Wether abusing the filesystem to create this database is good for performance is a completely different problem, at least it has the advantage of being very transparent. > > indicating which ports have been required by the end user, and > > which ones have been automatically installed. > > Well, what happens if an application (rather than a library) gets > installed as a dependency, but you decide that you like that > application, and want to keep it? How do you "promote" something from > "dependency installed" to "user installed?" Indeed you are right, it should be possible to decide of such a promotion. > > Personally I think that portmaster's approach is the right one. If you > accidentally delete something that it turns out you really do need, > you can always install it again. On the other hand, the presence of an > empty +REQUIRED_BY file is a very reliable indication that something > was previously installed as a dependency, but is no longer needed. > Typically you can install the java jdk to do programming, and without any required_by stuff. If you accidently erase it, it will be expensive to recreate. Obviously this is not a very good example because this one you will remember. I was thinking more to some obscure ports that you install by curiosity. After several months, perhaps you discover it is on your machine, and you have some use for it. Perhaps if you had erased it, the distfile would have disappeared, or marked broken with new versions of FreeBSD, no more compilable, etc. > I'd be interested to hear if others have opinions about this ... Sure this is a point of interest, the more opinions, the better. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: graphics/jasper 1.900.1_3 added libglut dependency: Now requires X11: Why?
Bill Milford a écrit : I am running a server without X11. I use ImageMagick-nox11-6.3.3.5_1 and GraphicsMagick-nox11-1.1.7_1 on this server. The line "USE_GL= glut" was added to the Makefile on the last update. This port now requires X11. Why was this done? It compiles and installs OK without that line. It seems to work OK. Bill I have the same problem I am going to try what you have done. But in the future an update will reset it I think. gwa ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keeping track of automatically installed dependency-only ports
Michel Talon wrote: On Sat, Jul 07, 2007 at 09:57:59AM -0700, Doug Barton wrote: The only reliable way to detect ports which have been installed as a dependency is to create a database *shudder* You just tripped over your own argument here. There are plenty of ways that we could recognize a port that was installed as a dependency. The one that comes immediately to mind is to create a flag file in /var/db/pkg/foo (or /var/db/ports/foo) to indicate that the port was installed as a dependency. It would be trivial for portmaster and portupgrade to do this, slightly more complicated for it to be done in bsd.port.mk, but not impossible. I agree completely with you. Of course when i say that a database has to be created, this may very well be reduced to a flag somewhere in /var/db/pkg. For me, /var/db/pkg is a database describing the installed ports. Wether abusing the filesystem to create this database is good for performance is a completely different problem, at least it has the advantage of being very transparent. IMO adding packages (or ports in this case) should be done using pkg_install. It's the best means to transparently control package entries in the system, and it would probably reduce the load on the bsd.port* Makefiles. indicating which ports have been required by the end user, and which ones have been automatically installed. Well, what happens if an application (rather than a library) gets installed as a dependency, but you decide that you like that application, and want to keep it? How do you "promote" something from "dependency installed" to "user installed?" Indeed you are right, it should be possible to decide of such a promotion. Not unless you have metafiles laying around that identify leaf packages (i.e. directly user installed packages) over additional node packages (in this case dependency installed packages). Personally I think that portmaster's approach is the right one. If you accidentally delete something that it turns out you really do need, you can always install it again. On the other hand, the presence of an empty +REQUIRED_BY file is a very reliable indication that something was previously installed as a dependency, but is no longer needed. Typically you can install the java jdk to do programming, and without any required_by stuff. If you accidently erase it, it will be expensive to recreate. Obviously this is not a very good example because this one you will remember. I was thinking more to some obscure ports that you install by curiosity. After several months, perhaps you discover it is on your machine, and you have some use for it. Perhaps if you had erased it, the distfile would have disappeared, or marked broken with new versions of FreeBSD, no more compilable, etc. There really isn't a way to work around this problem I believe other than to have a huge warning banner and show what would be deinstalled prior to the operation being executed. This is a slippery slope trying to deal with corner cases like these. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keeping track of automatically installed dependency-only ports
On Sat, 07 Jul 2007 09:57:59 -0700 Doug Barton <[EMAIL PROTECTED]> wrote: > Personally I think that portmaster's approach is the right one. If you > accidentally delete something that it turns out you really do need, > you can always install it again. [...] I think that the point of this thread was how to avoid such unwanted accidental deletitions -- a very useful thing when you, for example, install/deinstall a lot of applications for testing purposes, as someone pointed out. There is down the thread a proposed idea (related to portupgrade/pkg_deinstall) about introducing a +NEVERDEINSTALL file, e.g. here: http://lists.freebsd.org/pipermail/freebsd-ports/2007-June/041997.html I don't know very much about portmaster so I don't know if something similar already exists there. Nikola Lečić ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
