Re: reason 23 why we've moved to linux
On 03/22/2014 01:57 PM, Fernando Apesteguía wrote: On Sat, Mar 22, 2014 at 7:50 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 03/22/14 11:12, Randy Bush wrote: snip At least testing branches would be appreciated. Something like ivoras@ suggested two years ago? http://lists.freebsd.org/pipermail/freebsd-ports/2010-March/060296.html Something like this? http://svnweb.freebsd.org/ports/branches/2014Q1/ -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://www.fur.com/peace/ ___ 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: LPPL10 license consequences intended? (arabic/arabtex)
On 03/22/2014 02:27 PM, Kevin Oberman wrote: On Sat, Mar 22, 2014 at 10:29 AM, John Marino freebsd.cont...@marino.stwrote: In December, Nicola set the license for Arabtex to LPPL10. The result is that the port is no longer packagable: Ignoring arabic/arabtex: License LPPL10 needs confirmation, but BATCH is defined build of /usr/ports/arabic/arabtex ended at Mon Mar 17 16:12:44 PDT 2014 From a quick conversation on IRC, I got the idea that the license was correct and many more Tex packages should also have this license. If/when that happens, does that mean Tex packages are only to be built from source? Is it correct that LPPL10 can't be built in a batch? No. You must accept the license before you can build the port, and you cannot interactively accept a license in non-interactive batch mode. See the commments in /usr/ports/Mk/bsd.licenses.mk for what to set in make.conf to automatically accept certain licenses. Aside from any possible impact of the license, the Makefile contains: NO_BUILD= yes so it ill never be packaged and redistributed. This is not an artifact of the license and I don't know of the license would also block packaging. NO_BUILD means only that the configure and compile steps are not necessary for this port. The option you're thinking of is NO_PACKAGE. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-restrictions.html -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://www.fur.com/peace/ ___ 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: LPPL10 license consequences intended? (arabic/arabtex)
On 03/22/2014 06:05 PM, Kevin Oberman wrote: On Sat, Mar 22, 2014 at 2:16 PM, CyberLeo Kitsana cyber...@cyberleo.netwrote: On 03/22/2014 02:27 PM, Kevin Oberman wrote: On Sat, Mar 22, 2014 at 10:29 AM, John Marino freebsd.cont...@marino.st wrote: snip Is it correct that LPPL10 can't be built in a batch? No. You must accept the license before you can build the port, and you cannot interactively accept a license in non-interactive batch mode. snip I have again looked over the LPPL and there is no language requiring explicit acceptance of the license that I can find. I see nothing about this more restrictive than LGPL or other standard licenses. Am I missing it? I was elucidating from the point of view of the ports license infrastructure, not the point of view of a lawyer. The code expects you to accept the license, and will not proceed until you do. It's not my call whether or not it is legal for FreeBSD to accept this license on behalf of the user. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://www.fur.com/peace/ ___ 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: Explain staging
On 10/07/2013 04:37 AM, Anton Shterenlikht wrote: snip sure, I can do /tmp/distfiles too. But that doesn't help with all the other failing targets. Then I might as well chown -R user:group /usr/ports and update the ports tree as an unprivileged user too. HOwever, security would suffer, I think. And, anyway, this would be a major change. If this were the case, it should be much better documented, I think. From my /etc/make.conf: 8 # Read-only ports tree DISTDIR=/var/ports/distfiles PACKAGES=/var/ports/packages WRKDIRPREFIX=/usr/obj 8 Solves this problem quite nicely. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://www.fur.com/peace/ ___ 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: WANTED: Tool to verify installed package/port consistancy
On 05/10/2013 03:04 PM, Ronald F. Guilmette wrote: snip pkg_sanity: ImageMagick-6.8.0.7_1: +CONTENTS file does not exist -- skipped pkg_sanity: ORBit2-2.14.19: /usr/local/lib/libORBit-2.so: File failed MD5 checksum pkg_sanity: ORBit2-2.14.19: /usr/local/lib/libORBit-imodule-2.so: File failed MD5 checksum pkg_sanity: ORBit2-2.14.19: /usr/local/lib/libORBitCosNaming-2.so: File failed MD5 checksum pkg_sanity: OpenEXR-1.7.1: /usr/local/lib/libIlmImf.so: File failed MD5 checksum pkg_sanity: aalib-1.4.r5_6: /usr/local/lib/libaa.so: File failed MD5 checksum snip Are these mismatches symlinks? If so, are you checking the contents of the symlink (with, for instance, stat(1) or readlink(1)), or the contents of the file to which the symlink is referring? -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://www.fur.com/peace/ ___ 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
[Patch] Ports and rsync
I've submitted ports/171681[1] with a patch to add rsync to the list of update methods for the ports tree. Hopefully I'm not the only one who desires such functionality. References: [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171681 -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ 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: [Patch] Ports and rsync
On 09/16/2012 01:47 PM, Jeffrey Bouquet wrote: On 09/16/12 03:42 AM CyberLeo Kitsana wrote: I've submitted ports/171681[1] with a patch to add rsync to the list of update methods for the ports tree. Hopefully I'm not the only one who desires such functionality. References: [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171681 Could this substitute for .svn for those who now use csup? Or is it maybe specific to a local network and nothing upstream. Not clear the implications, here, or entire scenario of this rsync methodology (I use it readily for a whole bunch of other stuff.) But I look forward to its implementation... if it occurs. To my knowledge, the FreeBSD foundation does not offer rsync services for ports, though nothing stops anyone from actually doing so; I run one of my own, updated via portsnap, with a custom overlay for ports that haven't much usefulness outside of my domain. It seems the easiest approach, without having to learn the intricacies of creating and maintaining custom portsnap hosts or trying to set up and feed a subversion server to host my changes. This patch just offers an easy way to invoke rsync via 'make update' without having to dig out the magical rsync invocation flags every time. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ 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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2012 07:01 PM, Baptiste Daroussin wrote: Can anyone give me he details on the security related problem? Off the top of my head, it seems to represent a break in the chain of trust: how does the bootstrapper verify that the tarball it just downloaded to bootstrap pkg is genuine, and not, for example, a trojan? The source in usr.sbin/pkg/pkg.c[1] doesn't seem to suggest it cares. [1] http://git.cyberleo.net/?p=FreeBSD/releng/9.1.git;a=blob;f=usr.sbin/pkg/pkg.c;hb=b96b623d8debed8fa8fd7df5af01a350344549c9 - -- Fuzzy love, - -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA5YRMACgkQi7w8kEi1KHLZhwCgrGb8piGeNb07IryWvoc/JdzH xfAAoNfxm+nLoXU7BUclKqnLGbkxgilX =o9Br -END PGP SIGNATURE- ___ 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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On 06/06/2012 02:18 PM, Heino Tiedemann wrote: Hi, Why this ports needs his compiler to RUN?! firefox 13.0,1 snip Required To Run: archivers/zip, lang/gcc46,... Just a shot in the dark for lang/gcc46, I'd say it's because Firefox dynamically links to a newer version of libgcc that is only available when it is installed. Its runtime dependency on archivers/zip can be explained by the fact that Firefox now packs its hundreds of GUI files (chrome) into a giant zip file (named omni.ja), for which it requires a zip library to read. You're welcome to tweak the Makefile to remove the runtime dependency and test it to see how badly it breaks; I've done the same to keep Perl and Python off my embedded system images when installing glib et alia. Glib only requires the languages for scripts used when compiling software, which is unlikely to occur on an embedded system. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ 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
Creating Portshaker-compatible Overlays
I recently heard about Portshaker, and thought I might give it a go to replace the ad-hoc script I currently use to manage local port overlays. First, are there any plans to support rsync as an update method for source trees? It was a little strange to discover that this was not directly possible. Second, after pounding my overlay into something resembling a proper tree, I encountered some strangeness with regards to custom categories. portshaker.conf: 8 use_zfs=yes mirror_base_dir=/srv/ports ports_trees=main main_ports_tree=/usr/ports main_zfs_dataset=mtumishi/devel/ports main_merge_from=freebsd cdn 8 The 'freebsd' source is updated via portsnap, and the 'cdn' source via git from http://git.cyberleo.net/cdn-ports-overlay.git branch 'portshaker'. Both updates work fine. ls -la /srv/ports/cdn: 8 drwxr-xr-x 8 root wheel13 Feb 13 10:12 .git -rw-r--r-- 1 root wheel 0 Feb 13 10:12 .gitignore -rw-r--r-- 1 root wheel19 Feb 13 10:12 Makefile.local drwxr-xr-x 2 root wheel 3 Feb 13 10:17 Mk drwxr-xr-x 7 root wheel 8 Feb 13 10:12 misc-cdn drwxr-xr-x 3 root wheel 3 Feb 13 10:12 net 8 The changes in Mk/bsd.local.mk appear to be carried over properly, but Makefile.local is ignored and portshaker appears to have trouble merging the misc-cdn category: 8 (ee95ca16)[cyberleo@mtumishi ~]$ sudo portshaker -Mv [Info 10:49:24] Cloning '/srv/ports/freebsd' to '/usr/ports'. [Info 10:49:33] Merging '/srv/ports/cdn' to '/usr/ports'. [Warn 10:49:33] misc-cdn/Makefile: No Makefile in this directory! cp: /usr/ports/misc-cdn/bash-config: No such file or directory [Error 10:49:33] Cannot merge misc-cdn/bash-config. 8 It strikes me as strange that it would assume Makefile is a directory; but, given the nature of portshaker, I would expect it to manage the category Makefile properly regardless. It also seems to forget to create custom category directories in the target, and so fails when merging the ports under them. Am I approaching this with incorrect expectations? Are there any hints to be provided on how I might more effectively leverage this tool? Thanks! -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ 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
Overriding port knobs in child ports
Hi!
In the interests of keeping my embedded installations small, I wish to
avoid installing certain run-time dependencies for unused features.
For instance, the port www/squid is set USE_PERL5, which registers perl5
as a bdep and rdep; however, the only components of squid that actually
make use of perl5 are two authentication helper scripts that I do not
use. Since nothing else on the machine uses perl5, there's no point in
actually having it installed and using up space on the flashcard.
So I figure I can change www/squid from USE_PERL5 to USE_PERL5_BUILD,
while inheriting all other settings and options; but I don't want to
tamper with the original port and introduce problems updating the tree
later on. To accommodate this, I created a child port,
www/squid-perlless, and placed the following in the Makefile:
8
MASTERDIR= ${.CURDIR}/../../www/squid
.include ${MASTERDIR}/Makefile
PORTNAME= squid-perlless
.undef USE_PERL5
USE_PERL5_BUILD=yes
8
Installing this port creates a package named 'squid-perlless', but it
still has perl5 registered as an rdep, regardless of where I put the
.include.
I even tried including bsd.port*.mk after the master makefile, but that
just spewed a bunch of 'redefined' messages, and changed nothing.
Am I missing something here, or am I approaching the problem from the
wrong angle? It seems that this is a relatively necessary bit of
functionality for child ports, but I have not discovered anything in the
porters handbook that provides any hints for changing port knobs in a
child port.
Thanks!
--
Fuzzy love,
-CyberLeo
Technical Administrator
CyberLeo.Net Webhosting
http://www.CyberLeo.Net
cyber...@cyberleo.net
Furry Peace! - http://.fur.com/peace/
___
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
