Install texlive without X11
Hello, Is there a way to install texlive without X11? My intention is to replace the teTeX port on a headless server with the newer texlive port. The old teTeX port worked fine without X11, but the new texlive-base port seems to require X11, without a way to disable it. (I do not need xdvi or similar programs. This server purely runs TeX and produces DVI and PDF files, nothing else. The number of ports on this machine must be kept to a minimum for security and maintenance reasons, so X11 is disallowed.) Any idea? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Handelsregister: Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd "That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible." -- John William Chambless ___ 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"
Question about new options framework (regression?)
Hi, What is the proper way to temporarily change an option on the command line or within a script? For example, I have a script that builds both dynamic and static zsh binaries, without user intervention. With the old options system, the script set "WITH_ZSH_STATIC=true" when building the port. With the new options framework, that doesn't work aymore. Is there a variable that can be set to override what's read from the options file? If there is none, this feels like a regression. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind 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: Question about new options framework (regression?)
Baptiste Daroussin wrote: > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote: > > What is the proper way to temporarily change an option on > > the command line or within a script? > > > > For example, I have a script that builds both dynamic and > > static zsh binaries, without user intervention. With the > > old options system, the script set "WITH_ZSH_STATIC=true" > > when building the port. With the new options framework, > > that doesn't work aymore. > > > > Is there a variable that can be set to override what's read > > from the options file? If there is none, this feels like a > > regression. > > $ OPTIONS_SET="STATIC" make showconfig > ===> The following configuration options are available for zsh-5.0.0: > DEBUG=off: Install debug symbols > DOCS=on: Build and install the documentation > GDBM=off: Enable GDBM support (GPL) > MAILDIR=on: Enable support for Maildirs in MAIL(PATH) > MEM=off: Enable zsh-mem options > MULTIBYTE=on: multibyte character support > PCRE=off: Use Perl Compatible Regular Expressions > SECURE_FREE=on: Enable zsh-secure-free > STATIC=on: Build static executable/libraries > ===> Use 'make config' to modify these settings I'm afraid it doesn't work for me: $ OPTIONS_SET="STATIC" make showconfig ===> The following configuration options are available for zsh-5.0.0: DEBUG=off: Install debug symbols DOCS=on: Build and install the documentation GDBM=off: Enable GDBM support (GPL) MAILDIR=on: Enable support for Maildirs in MAIL(PATH) MEM=on: Enable zsh-mem options MULTIBYTE=on: multibyte character support PCRE=off: Use Perl Compatible Regular Expressions SECURE_FREE=on: Enable zsh-secure-free STATIC=off: Build static executable/libraries ===> Use 'make config' to modify these settings I also tried the other settings you suggested, and none of them works. It's always overridden by the settings that are stored in $PORT_DBDIR. With the old framework, I could override $PORT_DBDIR with "WITH_ZSH_STATIC=true" ... Can't this be done with the new framework, too? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ 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: Question about new options framework (regression?)
Baptiste Daroussin wrote: > On Wed, Jul 25, 2012 at 07:09:48PM +0200, Oliver Fromme wrote: > > Baptiste Daroussin wrote: > > > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote: > > > > What is the proper way to temporarily change an option on > > > > the command line or within a script? > > > > I also tried the other settings you suggested, and none > > of them works. It's always overridden by the settings > > that are stored in $PORT_DBDIR. > > > > With the old framework, I could override $PORT_DBDIR with > > "WITH_ZSH_STATIC=true" ... Can't this be done with the > > new framework, too? > > This is because you already have a save configuration made out of make > config > > you can still override PORT_DBDIR to make sure this configuration is > not read > PORT_DBDIR=/dev/null OPTIONS_SET="STATIC" make .. But I *do* want to use the saved configuration: It enables the MEM option, and maybe other things in the future. I only want to override *one* option -- the STATIC option. The others should be taken from the saved configuration in the options file. Well, of course, my script could try to parse the options file, construct appropriate OPTIONS_SET and OPTIONS_UNSET strings, and then add STATIC. But I hoped that there still is a simple way to override single settings from the options file ... I have to say it's a little annoying that I have to jump through hoops to achieve something that was rather trivial to do before. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 ___ 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: Question about new options framework (regression?)
Jase Thew wrote: > On 25/07/2012 23:57, Baptiste Daroussin wrote: > > because the priority goes to global to specific and the most specific is > > the > > options file. > > > > if most people want the options file to not have the final priority, why > > not, > > can others spread their opinion here? > > I can't see why it would be of benefit for saved options to override > anything passed to make (either env or as an arg), as one of the reasons > you're likely to be passing them is to override any saved settings in > the first place. > > Please consider reverting back to the established and I daresay, > expected behaviour. I agree with Jase. Actually I'm not sure if PORTS_DBDIR should override make.conf or vice versa. I don't know which one should be regarded as more specific. But anything specified on the commandline is definitely more specific than PORTS_DBDIR and should override anything else. One way to do that would be to introduce another pair of variables, e.g. OVERRIDE_SET and OVERRIDE_UNSET, so you could type: make OVERRIDE_SET=STATIC Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is the only current language making COBOL look good." -- Bertrand Meyer ___ 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: Question about new options framework (regression?)
Doug Barton wrote: > Traditionally the precedence has been: > > make.conf < OPTIONS < command line Are you sure? But how did the old framework find out if a WITH_* / WITHOUT_* variable came from make.conf or from the command line? For example, say the make environment contains WITH_FOO=YES, but the OPTIONS file contains WITHOUT_FOO=YES. If the above precedence is to be followed, then the framework needed to find out whether the WITH_FOO setting came from make.conf or from the command line. I don't think there's an easy way to do that. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters ___ 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: Question about new options framework (regression?)
Oliver Fromme wrote: > Doug Barton wrote: > > Traditionally the precedence has been: > > > > make.conf < OPTIONS < command line > > Are you sure? But how did the old framework find out if a > WITH_* / WITHOUT_* variable came from make.conf or from the > command line? Uhm, please ignore what I wrote. I forgot about "?=" syntax in make.conf ... In that case it works fine, of course. So, it really should be sufficient to move the compatibility section (the one that looks at WITH_* / WITHOUT_*) to the end of bsd.options.mk, after the section that loads the options file from $PORTS_DBDIR. Then the desired behaviour should be back. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum ___ 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: Question about new options framework (regression?)
Jase Thew wrote: > On 27/07/2012 10:41, Baptiste Daroussin wrote: > > > > I think that is the more reasonnable, I'll add this when fully back. I was > > thinking of LATE_SET and LATE_UNSET but OVERRIDE_SET and OVERRIDE_UNSET > > sounds > > better to me. > > What use-case are you thinking of that requires the ability for saved > config to override manually specified config? If there isn't a > compelling reason for this, then I'd personally much rather see the > original behaviour restored rather than adding another two variables. Baptiste is right ... The original behaviour is flawed, because it depends on how the port's maintainer wrote the Makefile. For example, If you have WITH_FOO=YES in the options file, and the port's Makefile checks whether WITH_FOO is set or unset, then there is *no* way to override that, not even with the old options framework. In the case of zsh I was lucky, because the (old) Makefile checked if WITH_ZSH_STATIC is set, while the options file contained WITHOUT_ZSH_STATIC, so I could override that. If it was checking whether WITHOUT_ZSH_STATIC was unset, it wouldn't have worked. Also, if I wanted to do it the other way round, i.e. set WITH_ZSH_STATIC in the options file, there would be no way to unset that on the command line. So, Baptiste's approach to fix that alltogether is right, in my opinion. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh ___ 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: Regression in PREFIX handling in packages
I think this might be related to this thread, so I'm posting it as a follow-up ... On some FreeBSD 8.x systems, I get the following error: ===> Deinstalling for security/ca_root_nss readlink: illegal option -- f usage: readlink [-n] [file ...] It seems bsd.port.mk is trying to use /usr/bin/readlink with the -f option when checking the PREFIX, but this option isn't supported on all 8.x systems. Wouldn't it make more sense to use /bin/realpath instead of /usr/bin/readlink -f? There's no reason to break older system. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "File names are infinite in length, where infinity is set to 255 characters." -- Peter Collinson, "The Unix File System" ___ 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"
ports/graphics/netpbm out of date
Hi, Both graphics/netpbm and graphics/netpbm-devel are *WAY* out of date (5 to 6 years). Many tools listed in the documentation are not present in the FreeBSD port, and many of the tools that are present are missing features. What's making things is worse is the fact that the netpbm ports don't include any documentation. Instead they refer to the online documentation which is way ahead of the state of the FreeBSD port, as explained above. Is anybody working on updating the netpbm ports? Is there any problem with it that I'm not aware of? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman ___ 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: ports/graphics/netpbm out of date
Peter Jeremy wrote: > On 2011-Mar-29 13:51:21 +0200, Oliver Fromme wrote: > > Both graphics/netpbm and graphics/netpbm-devel are *WAY* > > out of date (5 to 6 years). > > I don't understand you. In my experience, the netpbm ports have > always been updated fairly regularly. The ports currently have: > STABLE_PORTVERSION= 10.26.64 > DEVEL_PORTVERSION= 10.35.80 > > 10.26.64 is the last of the 10.26 series and was released > almost exactly 18 months ago. > > 10.35.80 is the current "stable" version and was released > about 5 weeks ago. The port was updated the day following > the release. The problem is that 10.26 is 6 years old, and 10.35 is 5 years old. The fact that they have been updated to the latest patch releases doesn't matter much, that's just bug fixes. But they are missing a lot of functionality. For example, many tools don't support transparency via PAM yet. For example, the pngtopam and pamtopng tools (for preserving the alpha channel) don't exist; they occured in 10.44. The current "stable" version is 10.47 (.27), and the current "advanced" version (this is not the development version!) is 10.53 (.05). I think that it makes sense to update the netpbm port to the "stable" version, and the netpbm-devel port to "advanced". However, the problem with that is that the netpbm folks don't provide tarballs anymore. You have to check out the stuff from their SVN repository. SourceForge provides a download URL that automatically packages the current source tree of a specified version (stable or advanced) and returns a .tar.gz file. But of course you get a different .tar.gz file when a developer commits a patch, so this is not suitable as distfile for a FreeBSD port. I'm not sure how to resolve that problem. Maybe upload a specific .tar.gz with a time stamp to a site that can be used as master site. > > What's making things is worse is the fact that the netpbm > > ports don't include any documentation. Instead they refer > > to the online documentation which is way ahead of the > > state of the FreeBSD port, as explained above. > > I agree this is annoying and don't understand the rationale behind the > way netpbm documentation is handled but that is not the FreeBSD > maintainer's fault. You are right, that's not the maintainer's fault, of course. But updating the FreeBSD port to a more recent version would make the problems smaller that are caused by the netpbm documentation policy. > > Is anybody working on updating the netpbm ports? Is there > > any problem with it that I'm not aware of? > > A quick check would have identified the maintainer (now Cc'd). Thank you. I'm sorry, I should have done that in the first place. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 ___ 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"
editors/joe + textproc/aspell: dependency problem?
Hi, I just csupped fresh ports on a new stable/8 box, installed textproc/aspell-without-dicten (i.e. with WITHOUT_DICTEN=YES) and then proceeded to install editors/joe. Both installed successfully, as far as I can tell. There were no error messages, and joe seems to work fine. But ... joe has a dependency on aspell (both build dependency _and_ run dependency), so I expected it to be recorded in the package database. But it isn't. pkg_info -r joe\* and pkg_info -R aspell\* don't report this dependency. While building joe, it _does_ display that it depends on aspell, and it correctly reports it as "found". It also depends in libiconv, which _is_ correctly recorded in the package database. Am I doing something wrong, or is there a bug somewhere? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 ___ 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: editors/joe + textproc/aspell: dependency problem?
Erik Trulsson wrote: > On Mon, Mar 08, 2010 at 12:50:05PM +0100, Oliver Fromme wrote: > > I just csupped fresh ports on a new stable/8 box, installed > > textproc/aspell-without-dicten (i.e. with WITHOUT_DICTEN=YES) > > and then proceeded to install editors/joe. Both installed > > successfully, as far as I can tell. There were no error > > messages, and joe seems to work fine. But ... > > > > joe has a dependency on aspell (both build dependency _and_ > > run dependency), so I expected it to be recorded in the > > package database. But it isn't. pkg_info -r joe\* and > > pkg_info -R aspell\* don't report this dependency. > > If there is a bug it is in the ports system in general when a given > dependency can be fulfilled by more than one port. > > If a port declares that it depends on file/library/whatever "foo" from > the port "bar", but you have "foo" installed from the port "baz" then > the dependency check will be fine (since it finds "foo") but when the > dependency should be registered in the package database it will try to > register a dependency on the package "bar", which is not installed, and > then no dependency is registered. > (In your case "foo" = "/usr/local/bin/aspell", "bar" = "textproc/aspell", > and "baz" = "textproc/aspell-without-dicten".) > > It might be better if a dependency was registered on the package that > the depended-on file actually was installed from, but this is currently > not done. Thanks for the insights. That explains what I'm seeing. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd ___ 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: editors/joe + textproc/aspell: dependency problem?
Lars Eighner wrote: > On Mon, 8 Mar 2010, Oliver Fromme wrote: > > joe has a dependency on aspell (both build dependency _and_ > > run dependency), so I expected it to be recorded in the > > package database. But it isn't. pkg_info -r joe\* and > > pkg_info -R aspell\* don't report this dependency. > > joe does not really depend upon aspell. It comes with a macro that assumes > aspell, and of course the macro won't work without aspell. The joe binary > uses different configuration files depending upon how it is called (i.e. > one to make it act like pico if you call joe with jpico, act like emacs if > called as jmacs, etc.) > > The binary runs fine without aspell. In fact you can edit the configuration > files, which are plain ascii so that one of joe's faces uses ispell, one > uses aspell, and another has no mapping for a speller. If you had ispell > instead of aspell you could simply edit the configuration of the one(s) you > want to use. The joe macro language is very easy, but just changing one > letter in the spelling filter is a true no-brainer. > > It would be wrong for the joe build to fail without aspell because aspell > has nothing whatever to do with the joe binary. It would be great if the > build could rewrite the spelling macro according to which speller it could > find or disable the macro if it couldn't find any. > > With joe you can filter text through just about anything that can read from > STDIN and write to STDOUT: sed, tr, etc., including really heavy stuff like > (o)nsgmls. But it would be silly to say joe depends on them. It's the > bundled macro that uses aspell, and it can easily be edited to use anything > else. Yeah, I know all of that. I'm using joe for about 20 years. That doesn't explain the problem I'm seeing, though. (But Erik explained that very well.) Actually I don't need no freakin' spell checker at all, but the joe port insists on installing one. If it weren't for my lazyness I had submitted a patch for WITHOUT_ASPELL a long time ago ... ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is the only current language making COBOL look good." -- Bertrand Meyer ___ 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: How to deal with conflict between graphics/libGL and x11/nvidia-driver?
Conrad J. Sabatier wrote: > Does anyone have any suggestions on how to deal with the conflict > between the ports libGL and nvidia-driver? > > Both install their own version of /usr/local/lib/libGL.so.1. Obviously, > if you're using the nvidia driver, you need nvidia's version and not > libGL's version, but many other ports also depend on libGL. > > I'm not quite sure how to deal with this so that any portupgrades, etc. > won't keep trampling over my nvidia GL libraries. I was going to use > an ALT_PKGDEP for portupgrade, but the problem is that libGL also > installs some include files that nvidia-driver does not, so that's not > a sufficient solution. Maybe it would be helpful to add libGL as a dependency to the nvidia-driver port. That means, when the libGL port is updated, the nvidia-driver port will be rebuilt, too, because it depends on the libGL port, which means that the nvidia-driver's library will always override the one installed by the libGL port. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ 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: Ports system quality
(Not replying to any particular post in this thread.) I think the current ports system in FreeBSD is not bad. Sure, it could be better (but this would probably require more manpower, which is a problem in a volunteer project), but it also could be a *lot* worse. I know of several people who are typical "release users". They install a FreeBSD release from CD/DVD and use the ports or packages that came with that release. Usually that works very well because of the testing during the ports freeze that happens in preparation for every release. They never update (or maybe only when there are serious security issues) and happily keep using those very ports until they update to a newer release, one or two (or more) years later. The other extreme are people who run a cron job every night that updates /usr/ports (*) and runs "400.status-pkg" (from /etc/periodic/weekly), possibly even followed by an automated update (**). Of course this will sometimes break. That's normal and to be expected, because the ports collection is changed and modified constantly by many people, except during freeze. There is always something that's broken. If you're affected, you need to postpone the update of the respective ports until someone (possibly including yourself) unbreaks it. That's the price to pay when you want to be on the "bleeding edge" instead of waiting for the next freeze and updating the ports to the release tag only. Personally, on my workstation at home I make a complete update every few months (2 to 4 times a year). If there are any security vulnerabilities reported by portaudit, I update the affected ports immediately, of course. (By the way, I use neither portupgrade nor portmaster, but a self-made script. However, portmaster really isn't that bad and should work fine for most users. :-) Finally, I recommend to install ports-mgmt/pkg_cutleaves and run it regularly after updates. It helps removing ports that you don't need. Rule of thumb: The less ports you have, the less dependencies exist, so updates will be less complex, and you're less likely to be affected by breakage. With that in mind, I keep the ports count on my workstation on a moderate level: $ pkg_info | wc -l 559 Best regards Oliver (*) For example: http://www.secnetix.de/olli/scripts/ports-check-update (**) http://www.secnetix.de/olli/scripts/ports-update-list -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal ___ 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: Ports system quality
Doug Barton wrote: > On 09/02/2011 02:24, Oliver Fromme wrote: > > Finally, I recommend to install ports-mgmt/pkg_cutleaves and > > run it regularly after updates > > portmaster -s does the same thing. No. pkg_cutleaves finds ports that I have installed at some point in the past and then forgot about (and never used again), and offers me to delete them. portmaster -s doesn't find those. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth ___ 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: Ports system quality
Alexander Leidinger wrote: > Quoting Oliver Fromme (from Fri, 2 Sep 2011 > 11:24:16 +0200 (CEST)): > > > The other extreme are people who run a cron job every night > > that updates /usr/ports (*) and runs "400.status-pkg" (from > > /etc/periodic/weekly), possibly even followed by an automated > > update (**). Of course this will sometimes break. That's > > normal and to be expected, because the ports collection is > > changed and modified constantly by many people, except during > > freeze. There is always something that's broken. If you're > > affected, you need to postpone the update of the respective > > ports until someone (possibly including yourself) unbreaks it. > > That's the price to pay when you want to be on the "bleeding > > edge" instead of waiting for the next freeze and updating the > > ports to the release tag only. > > No, Yes, it is. :-) > that's the price to pay if you do not use all available tools. > Personally I make a FS snapshot before updating. We should recomment > to do this in all sensible places, and maybe even add code to > portmaster/portupgrade which tells to make a snapshot if there is none > (where possible). This way a rollback to a known good state is > possible if someone gets hit by an instability (someone still can get > hit, but the impact is a lot lower). Yes, I know that ZFS (the FS > where it is very easy to snapshot and rollback) is not used > everywhere, but the new installer for 9.0 offers now the possibility > and we should tell the people what is possible now. I wrote that the price to pay is that you have to postpone the update of respective ports. And this is true, no matter if you use snapshots or not (or something else). Having to roll back to a working system is a problem that I didn't talk about at all. Snapshots can be used for this, of course. Personally I cannot use snapshots, but I keep packages of all working ports (created with "make package" or "pkg_create -b"), so I can easily roll back if necessary. However, that happens very rarely because I watch the mailing lists carefully before updates, so I notice in advance if there is any major breakage. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "A language that doesn't have everything is actually easier to program in than some that do." -- Dennis M. Ritchie ___ 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: sysutils/cfs
per...@pluto.rain.com wrote: > Chris Rees wrote: > > Whoops, also missed a CVE -- buffer overflows can cause a DoS. > > Er, am I the only one who does not recognize what "CVE" stands for? "CVE" == Common Vulnerabilities and Exposures To put it simply, it's a database of security threats maintained by MITRE: http://cve.mitre.org Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie. ___ 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: reasons for rewriting regular memory
per...@pluto.rain.com wrote: > Matthias Andree wrote: > > > I agree, but I can think of another valid exception. System with > > > Hamming correction on the memory, gets a single bit (correctable) > > > error. Need to rewrite the memory contents to reset all the parity > > > bits! > > That's a matter of the EDAC stuff, not the business of applications. > > True, but it may explain why clang does not flag "*x = *x;" when it > does flag "x = x;". A compiler cannot know the context in which the > compiled code will be used. No -- If a program requires that an access to a variable must not be optimized away by the compiler (because it is a hardware register or something similar), then it must declare the variable as "volatile". But there is a simple reason that "x = x;" is flagged while "*x = *x;" is not. It is trivial to detect that the former does not have any effect. No operators are involved (except for the assignment itself), so the compiler just has to compare the _names_. But in the latter case, it is not trivial at all, because the compiler has to compare the _values_ of the expressions and detect any side effects, and it has to take a lot of things into account. For example, x could be part of the struct to which x points, so the assignment could change the contents of the struct. Detecting these cases would involve a rather deep and extensive analysis of the code. Obviously clang isn't going that far (although, maybe a higher optimization level could change that). > BTW I agree that an understanding is needed of _why_ the code in > question was included. I think someone else already explained that in this thread. The GIT reposity reveals that the author removed a variable that was not used anymore, and replaced all occurences of it, probably with automated search&replace, which lead to the line in question, which is now superfluous. It should just be removed. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke ___ 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: sysutils/cfs
Erik Trulsson wrote: > On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote: > > On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov wrote: > > > What about requiring that the ports deprecated should be either broken > > > or have known published vulnerabilties for a long period of > > > time (say 6 months) for the start? > > > > This might be reasonable for broken ports but ports with known > > vulnerabilities should either be fixed or removed promptly. > > That depends somewhat on the exact nature of the vulnerability. > Depending on how the port is used a given vulnerability might not > be a problem. (E.g. if a port has a vulnerability which allows a local > user to become root, then it is a problem for multi-user systems with > untrusted users, but for a system which only has a single user or only > trusted users it would not be a significant problem.) > > If a port can be used safely despite existing vulnerabilities it is not > at all clear it need to be removed quickly even if it is not fixed. > > (Marking it FORBIDDEN so potential users are warned about known > problems is another thing.) I tend to agree with Erik here. In my opinion, the important thing is to let the user know about the problem, so the *user* can make an educated decision instead of having ports committers force the decision upon all users. There are many examples of security problems that might not affect all users. Users might also decide to take the risk, especially if the software in question provides a unique feature that is essential to the user and cannot be replaced. Appropriate measures can be taken to contain the risk, such as running the software inside a jail or VM. The question is how to inform the user in a reasonable and reliable way. I think ports-mgmt/portaudit already does a very good job, but it is optional, and I guess that many (maybe even most) "non-expert" users don't install it or don't even know about it. It might be a good idea to make portaudit a mandatory part of the ports framework and enable it by default. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing." -- Dick Brandon ___ 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: Print +REQUIRED_BY as tree?
Lev Serebryakov wrote: > Is here console tool, which shows dependency tree of installed ports > from "required" port to "users"? pkg_tree performs opposite task. Maybe this script is helpful: http://www.secnetix.de/olli/scripts/pkg_dep_view By default it displays the dependency graph of your installed packages, similar to pkg_tree, I assume (though I've never used pkg_tree). With the -t option it does the "reverse", for example "pkg_dep_view -at png-1.4.8" displays a tree of the packages that require png-1.4.8 to run. If you suspect that your package information might be broken or inconsistent, I recommend you first run "pkg_check_dependencies -q" (from the same URL directory as the first script). It will display any inconsistencies. > I need to investigate exact path why this port is installed on my > system :) Well, that's not easy to do after the fact, especially if it's only a build dependency. In this case, using "make all-depends-list" in the ports collection might be the best way to track it down. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd ___ 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: Thank you (for making the ports less boring).
Stephen Montgomery-Smith wrote: > particularly nasty thing to do. I get the impression that each > committer has his own special way of doing this. For example, I have > personally found that a simple grep won't work, because "grep xxx > /usr/ports/*/Makefile*" just creates a line too long for the shell to > handle. I use a shell construction involving "find" but I wonder how > others do the same thing. cd /usr/ports echo */*/Makefile* | xargs grep xxx If your shell is zsh, you can also use zargs (see the man page for details): zargs */*/Makefile* -- grep xxx On the topic of this thread: I also use FreeBSD as desktop OS on my workstations, both at home and at the office, for about 15 years. My impression is that the quality of the ports collection improved during all that time, except for a few specific incidents. Of course it does sometimes happen that something doesn't work. That's a natural thing, given that there are more than 20k ports and several hundred people are working on it at the same time. These things are usually fixed very quickly. Sometimes there's an obscure problem that doesn't seem to happen to anybody else, so I have to debug and fix it myself (followed by PR'ing the issue, of course), but that's ok, too. This is open source after all. It should also be emphasized that old libraries should always be saved when updating ports. This would have saved Michal from the gdbm problem. portupgrade does that by default (as does portup), while portmaster requires the -w option to do that (which is unfavorable, in my opinion; it should do that by default, too). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is executable pseudocode. Perl is executable line noise. ___ 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: Thank you (for making the ports less boring).
Stephen Montgomery-Smith wrote: > On 09/13/2011 09:11 AM, Oliver Fromme wrote: > > Stephen Montgomery-Smith wrote: > > > particularly nasty thing to do. I get the impression that each > > > committer has his own special way of doing this. For example, I have > > > personally found that a simple grep won't work, because "grep xxx > > > /usr/ports/*/Makefile*" just creates a line too long for the shell to > > > handle. I use a shell construction involving "find" but I wonder how > > > others do the same thing. > > > > cd /usr/ports > > echo */*/Makefile* | xargs grep xxx > > That's amazing. > > It would never have occurred to me that "echo */*/Makefile*" works when > "grep xxx */*/Makefile*". Is that because "echo" is a builtin command > in csh (which is what I use)? I notice "/bin/echo */*/Makefile*" > doesn't work. Yes, exactly. When the shell executes an external command, it uses the execve(2) syscall, which has a limit for the size of the argument list. This is why xargs(1) exists. In the past century this limit was 64 KB, then it was raised to 256 KB when people started measuring RAM in GB. There's a read-only sysctl for that value: $ sysctl kern.argmax kern.argmax: 262144 Built-in commands are not affected by the limit because they run inside the shell process itself, so the execve(2) syscall is not involved. echo(1) is a built-in command in all common shells, so "echo ... | xargs" always works. However, if you type /bin/echo, you force the shell to execute the external command, so the limit applies again. You can also write "for i in */*/Makefile*; do ..." or similar (in /bin/sh) without worrying for limits, for the same reason. > Is this documented somewhere? Good question. It should be mentioned in the shells' man- pages, e.g. csh(1) mentions it in the "LIMITATIONS" section (among other strange limitations specific to csh). Also, the xargs(1) manpage mentions ARG_MAX, and the execve(2) manpage explains that the syscall will fail (errno E2BIG) if "the number of bytes in the new process' argument list is larger than the system-imposed limit". I'm pretty sure that _every_ book on shell scripting will explain the argument list limit, and how to circumvent it. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ 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: Detecting dependencies
Jason Hellenthal wrote: > On Thu, Sep 15, 2011 at 12:06:03AM +0300, chukha...@mail.ru wrote: > > There have been a discussion about finding interdependencies of ports. > > I have a relatively simple Python script for that. There is a pr > > ports/160007 > > to add its early version. Unfortunately, I missed a reply to it, so there > > is > > an issue which I have not yet addressed... > [...] > > 1. Would be cool if this would work on already installed ports or packages > too! just a thought. That's what a script of mine does (it's also in Python): http://www.secnetix.de/olli/scripts/pkg_dep_view > 2. If it would detect the presence of UTF-8 in the LANG or LC_ALL > environment vars and use the appropriate drawing method for each rather > than a default to UTF-8. "I am happy with it as is though" Maybe have a look at my script, it might help. It uses Python's curses module to display graphical line characters using the ACS feature (alternate character set). This is independent from the local (UTF-8, ISO8859, ASCII) and works very well with terminals that support line drawing characters, such as xterm, vt100 and so on. When there is no such support (dumb terminal, or not supported by termcap, or stdout is a pipe), normal ASCII characters are used instead. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe ___ 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: Detecting dependencies
Michel Talon wrote: > Oliver Fromme wrote: > > > > That's what a script of mine does (it's also in Python): > > > > http://www.secnetix.de/olli/scripts/pkg_dep_view > > Waooh! this is very cute. > > While we are in python i have something which draws > graphviz dependency graphs for ports here > http://www.lpthe.jussieu.fr/~talon/pkg_check.py Very nice! Your script seems to do several jobs at once, while I have separate scripts for those tasks. E.g. I have a separate script for checking origins and the consistency of dependencies. > Seeing things like your script, the perl script port-easy by des, etc. > i really wonder why people write stuff in C or worse shell for ports. > One could write ten times smarter and ten times shorter things in real > languages like python, lisp, etc. This argument of being "included in > base system" is so completely bogus ... I think "high-level" languages like Python are very well suited for managing data structures like dependency graphs. These structures are native to the language, so reading the +REQUIRED_BY files into a tree structure is absolutely trivial and requires just a few lines, wereas in C it gets a lot more complicated and a lot more error-prone. In Python you don't have to care about pointers and memory allocation (the same is true for Ruby, Perl and others, of course, but I think that Perl's syntax is horrible). As for "it's not in the base system": I don't care much. The Python port is easy enough to install, and in fact it's installed on most machines anyway because quite a lot of ports depend on it. Actually, some of my scripts that deal with package began as awk scripts, precisely for the reason that it's in the base system. But while awk supports dynamic arrays and associative arrays, it doesn't support nesting them, so you can't directly make a tree-like structure (well, you can, but it gets ugly very quickly). So I started porting them to my favourite scripting language, which is Python. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman ___ 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: amd64: cc -dumpmachine [ffmpeg]
Andriy Gapon wrote: > > [sorry for spamming so many lists but all of them seem to be relevant] > > $ uname -srm > FreeBSD 6.2-RELEASE-p2 amd64 > $ cc -dumpmachine > > $ I get the same empty result on a 32bit RELENG_6 (i386) machine here. It seems to be normal. > At least configure script of the latest ffmpeg-devel port seems to be > confused by this. Works fine here on said i386 machine. So it must be something else, no related to the -dumpmachine output, but maybe amd64-related. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Printing with Acrobat Reader
Hi,
I've configured Adobe Reader to use "/usr/bin/lpr -Plaser"
for printing ("laser" is the name of the printing queue for
my PostScript printer). But when I try to print a document,
I get the error message "/usr/bin/lpr not found".
Obviously Adobe Reader tries to locate the given binary in
/compat/linux. When I copy /usr/bin/lpr (FreeBSD binary)
to /compat/linux/usr/bin, printing from Adobe Reader works
fine.
Now I have a few questions ... :-)
First, copying the FreeBSD binary to /compat/linux seems
like a dirty hack. Is there a better way to solve the
problem?
Second, if there's no better way, then shouldn't the port
already copy the lpr binary upon install (and remove it
upon deinstall), so printing works out of the box? Or
install a small shellscript wrapper in /compat/linux that
calls /usr/bin/lpr. (Or at least add a message to the
FreeBSD port to hint users that they need to copy the
binary.)
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
-- Chris Torek
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Printing with Acrobat Reader
Alexander Leidinger wrote:
> Oliver Fromme wrote:
> > I've configured Adobe Reader to use "/usr/bin/lpr -Plaser"
> > for printing ("laser" is the name of the printing queue for
> > my PostScript printer). But when I try to print a document,
> > I get the error message "/usr/bin/lpr not found".
>
> Try without the path...
Interesting idea. I guess I didn't thought of that because
the _default_ entry in Adobe Reader is "/usr/bin/lp". So I
just tried adding an "r" to it, which failed.
I think it would be desirable to have the Adobe Reader port
work out of the box without _any_ change by the user.
That's why I suggest having the port add a wrapper script
as /compat/linux/usr/bin/lp. A simple one line script like
this one should be sufficient:
#!/bin/sh -
exec /usr/bin/lpr "$@"
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"I made up the term 'object-oriented', and I can tell you
I didn't have C++ in mind."
-- Alan Kay, OOPSLA '97
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Printing with Acrobat Reader
Alexander Leidinger wrote: > Oliver Fromme wrote: > [...] > > I think it would be desirable to have the Adobe Reader port > > work out of the box without _any_ change by the user. > > That's why I suggest having the port add a wrapper script > > as /compat/linux/usr/bin/lp. A simple one line script like > > Not the acroread port, but I would not object if the linux_base ports > would install such a wrapper... That would be fine with me. I don't care which port installs it, as long as it works. :-) > > this one should be sufficient: > > > > #!/bin/sh - > > exec /usr/bin/lpr "$@" > > When I remember your initial mail right, you did test this and it > works... right? No, I copied /usr/bin/lpr to /compat/linux/usr/bin/lpr and then told Adobe Reader to use "/usr/bin/lpr" (instead of the defdault "/usr/bin/lp"). The above wrapper script (as /compat/linux/usr/bin/lp without "r") should have exaxtly the same effect, except that the Adobe Reader's default need not be changed. I can give it a try in the evening. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Printing with Acrobat Reader
Roman Divacky wrote: > > > Acroread will use linux system calls to start the shell. This results > > in the linux shell (/compat/linux/bin/sh) to start (linuxulator > > directory prefixing). The linux shell will use the same linuxulator > > directory prefixing to start /compat/linux/usr/bin/lpr. So we're in > > the same situation like with Acroread. So when you play around with it > > also try to not specify a path to the lpr call and tell us which one > > works. > > this is not entirely true (or I just read it wrong). it works like this > > any binary (fbsd or linux) can run any binary (fbsd or linux). its just that > when linux binary wants to run "xyz" it searches /compat/linux first and then > falls back to / > > just a clarification I think you both mean to say exactly the same, you just express it in different ways. :-) Since there is no /compat/linux/usr/bin/lpr, it should fall back to using /usr/bin/lpr. Anyway, I will test it, as Alexander suggested. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "File names are infinite in length, where infinity is set to 255 characters." -- Peter Collinson, "The Unix File System" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Printing with Acrobat Reader
Alexander Leidinger wrote: > I think you said the same than I did, just differently (Oliver did > call lpr with the full (correct?) path in acroread and somehow it > didn't work for him). That's correct. Obviously Adobe Reader performs some kind of sanity check on the path (if one is given), and for some reason it always prepends /compat/linux in that case. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd cat man du : where Unix geeks go when they die ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Printing with Acrobat Reader
Alexander Leidinger wrote: > Oliver Fromme wrote: > > That's correct. Obviously Adobe Reader performs some kind > > of sanity check on the path (if one is given), and for some > > reason it always prepends /compat/linux in that case. > > No linux application does this, it's the kernel. It tries with the > compat path first and then with the normal path. I don't know why it > does not work in acroread, I never investigated this issue. An > application should not be able to know if the command is from compat > or not. Adobe Reader does. Dont ask me how and why, but it does. Any other explanation of the symptom is even less likely. As a matter of fact, when I configure it to use /usr/bin/lpr for printing, it reports "/usr/bin/lpr not found", and when I copy /usr/bin/lpr to /compat/linux/usr/bin/lpr, it works. > I'm a little bit puzzled, but not puzzled enough to > investigate further. OK. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "FreeBSD is Yoda, Linux is Luke Skywalker" -- Daniel C. Sobral ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Printing with Acrobat Reader
OK, now I've tested it thoroughly. This is on a RELENG_6 machine with current acroread7 and linux_base-fc-4_9 from ports, and compat.linux.osrelease is set to 2.4.2. $ pwd /usr/compat/linux/usr/bin $ ls -l lp* -rwxr-xr-x 1 root wheel 35 Apr 15 12:32 lp $ cat lp #!/bin/sh - exec /usr/bin/lpr "$@" Works perfectly well with Adobe Reader's default setting of "/usr/bin/lp" for the printer program. I have also tested it without the path in the script (i.e. only "lpr" instead of "/usr/bin/lpr"). It works just as well, but might be dependant on PATH settings, so I would prefer to keep the full path there, just in case. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence" -- Jacek Generowicz ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: xorg upgrade and /etc/ttys regression
Just to be clear ... Am I understanding things right that the new X server requires hald and dbus running? It won't work anymore without them? (That would be a good reason for me not to update.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh ___ 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: ports using sdp when mpeg4ip is installed
Iain Hibbert wrote: > Guido Falsi wrote: > > I second this idea and it sure will solve the includes problem. > > > > It will not solve the problem with libsdp.so though. > > would it make sense to merge the sdp functions into libbluetooth? > IIRC with BlueZ only one library is required.. Either that, or rename it to libbtsdp. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Software gets slower faster than hardware gets faster." -- Niklaus Wirth ___ 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"
dns/bind96 doesn't register idnkit dependency
Because of the recent security problem with BIND I decided to replace the base system's version with the dns/bind96 port. It compiled, installed and started without any problems (this is on a 7-stable system). However, pkg_infor -r doesn't list any dependencies. I compiled bind96 with the IDN option, so it also compiled and installed dns/idnkit. ldd confirms that dig, host and nslookup are indeed linked against the libidnkit library. For now I have manually added the dependecy data to the $PKG_DBDIR files, so idnkit isn't accidentally removed because it's a "leaf" port ... Is this is a know problem or did I do something wrong? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Whatever happened to the days when hacking started at the cerebral cortex, and not at the keyboard?" -- Sid on userfriendly.org by Illiad, 2007-06-20 ___ 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"
