Re: mail/mu does not install mu4e
Jo! Mon, Feb 17, 2014 at 04:45:29PM +0100, _1126 wrote: The port mail/mu builds its Emacs extension mu4e, but it does not install it. I had to manually copy 'work/mu4e' into '/usr/local/share/emacs/site-lisp/' in order to be able to use mu4e. I am not yet experienced in working with ports, so I am not (yet) able to provide a patch, but maybe it is easy for you to do so ;) Relatively easy. The reason why I wasn't included mu4e is that I am not using Emacs, so wasn't able to test it. Will send you patch to enable this in a couple of days. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpIQTTgNjGfD.pgp Description: PGP signature
Re: need help building port with clang
Tue, Sep 04, 2012 at 01:45:51AM -0400, AN wrote:
I use the base compiler for world and most ports, I do not want to
change at this time. So, my question is how can I tell
Firefox-nightly to use clang? Is there an equivalent to
USE_GCC=4.8+ for clang that I can put in the makefile? I want to
use clang to compile this specific port, and let the base compiler
build the rest.
Add the following lines to your /etc/make.conf
{{{
.if ${.CURDIR:M/usr/ports/www/firefox-nightly}
CC=clang
CXX=clang++
CPP=clang-cpp
.endif
}}}
Adjust the path to the port to your taste, but keep in mind that
this should be the realpath(1) of your port location.
For multiple ports you can use
{{{
.if ${.CURDIR:Mpath1}
I_WANT_CLANG=desperately
.endif
.if ${.CURDIR:Mpath2}
I_WANT_CLANG=desperately
.endif
.ifdef I_WANT_CLANG
CC=clang
CXX=clang++
CPP=clang-cpp
.endif
}}}
to avoid useless repetition.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgp7tLBIlhknj.pgp
Description: PGP signature
[CFT] net/gatekeeper: fixed DoS, CVE-2012-3534
I had backported denial-of-service fixes from version 3.1, http://codelabs.ru/fbsd/ports/gatekeeper/gnugk-fix-cve-2012-3534.diff but I don't use GNU gatekeeper in production. Patched version contains new configuration knob, MaxStatusClients, that is 20 by-default and is used to limit the number of simultaneous connections. I am interested in - testing that the patched version works and has no regressions; - MaxStatusClients really works. Thanks in advance. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpnXw9npJuzq.pgp Description: PGP signature
Re: cvs commit: ports/x11/slim Makefile pkg-plist ports/x11/slim/files pam.conf slim.sh.in
Wed, Jul 18, 2012 at 08:37:30AM +0400, Eygene Ryabinkin wrote: Thu, Jul 12, 2012 at 12:26:15AM -0400, Henry Hu wrote: For the png problem, I think that we can use png_jmpbuf for any libpng = 1.2.5? It seems to be exist at least from libpng 1.2.5 (http://www.libpng.org/pub/png/libpng-1.2.5-manual.html) so it's safe to use it? Should be. But according to the portability note at http://www.libpng.org/pub/png/libpng.html The libpng 1.5.x series continues the evolution of the libpng API, finally hiding the contents of the venerable and hoary png_struct and png_info data structures inside private (i.e., non-installed) header files. So it is normal to use the new API only for = 1.5.x. Mon, Jul 16, 2012 at 01:07:06AM -0700, Doug Barton wrote: Where are we at with this? I'm using the latest png with your patch and it is working fine, although only a few of my backgrounds are PNGs. I had tested it with PNG 1.4.10 -- works fine. So, I had changed the required library version for png from '15' to '1[45]'. The patch was modified accordingly, http://codelabs.ru/fbsd/ports/slim/upgrade-1.3.3-to-1.3.4.diff Ping! Were there any testers of the updated slim port? If yes, please, speak up. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpnJrHKNoLnG.pgp Description: PGP signature
Re: cvs commit: ports/x11/slim Makefile pkg-plist ports/x11/slim/files pam.conf slim.sh.in
Volodymyr, good day. Mon, Jul 30, 2012 at 01:51:32PM +0300, Volodymyr Kostyrko wrote: Eygene Ryabinkin wrote: Ping! Were there any testers of the updated slim port? If yes, please, speak up. WFM now, Great, thanks for testing! the only problem I had faced is introduced incompatibility with clang but that has mostly nothing to do with the port. I filed a bug at http://developer.berlios.de/bugs/?func=detailbuggroup_id=2663bug_id=18667 but with no progress though. I am currently rebuilding all my ports with clang on my workstations, so once the dust will be settled, I'll probably fix slim's clang problems if they will be still there at that time. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpeEPcy2FGmY.pgp Description: PGP signature
Re: cvs commit: ports/x11/slim Makefile pkg-plist ports/x11/slim/files pam.conf slim.sh.in
Thu, Jul 12, 2012 at 12:26:15AM -0400, Henry Hu wrote: For the png problem, I think that we can use png_jmpbuf for any libpng = 1.2.5? It seems to be exist at least from libpng 1.2.5 (http://www.libpng.org/pub/png/libpng-1.2.5-manual.html) so it's safe to use it? Should be. But according to the portability note at http://www.libpng.org/pub/png/libpng.html The libpng 1.5.x series continues the evolution of the libpng API, finally hiding the contents of the venerable and hoary png_struct and png_info data structures inside private (i.e., non-installed) header files. So it is normal to use the new API only for = 1.5.x. Mon, Jul 16, 2012 at 01:07:06AM -0700, Doug Barton wrote: Yesterday I had looked at the libpng and it seems that this patch should include 1.4.* for the new variant of the setjmp code -- I need some hours to try to build it with png 1.4. Where are we at with this? I'm using the latest png with your patch and it is working fine, although only a few of my backgrounds are PNGs. I had tested it with PNG 1.4.10 -- works fine. So, I had changed the required library version for png from '15' to '1[45]'. The patch was modified accordingly, http://codelabs.ru/fbsd/ports/slim/upgrade-1.3.3-to-1.3.4.diff -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgplk92KXQJ7b.pgp Description: PGP signature
Re: cvs commit: ports/x11/slim Makefile pkg-plist ports/x11/slim/files pam.conf slim.sh.in
Tue, Jul 10, 2012 at 12:27:27AM -0700, Doug Barton wrote: On 07/09/2012 01:13, Eygene Ryabinkin wrote: This very error should be fixed by the patch Yes, I'm an idiot. :) I successfully applied your patch and forgot to move the new patch- file into files/. Shouldn't it appear in files/ automatically or you're using some strange variant of patch utility? Or you're patching in some other place and then moving the result elsewhere? Once I fixed the PEBKAC it worked as expected on 10-current amd64, and 8-stable i386. Cool, thanks! Henry, if you'd like me to apply the patch just let me know. Yesterday I had looked at the libpng and it seems that this patch should include 1.4.* for the new variant of the setjmp code -- I need some hours to try to build it with png 1.4. Eygene, thanks for doing this. You're welcome ;)) -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpRALjdUKDgz.pgp Description: PGP signature
Re: cvs commit: ports/x11/slim Makefile pkg-plist ports/x11/slim/files pam.conf slim.sh.in
Thu, Jul 05, 2012 at 05:09:30PM +0400, Eygene Ryabinkin wrote: I am running 1.3.4 for some time: most of my workstations are fine with it, but one fails to start the desktop, though it has a mix of old and new packages, so I am rebuilding them just now. Was a problem with D-BUS an newer Xorg, unrelated to SLiM. Any others who had experience with my patch? -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgp2NFo5d3tW2.pgp Description: PGP signature
Re: cvs commit: ports/x11/slim Makefile pkg-plist ports/x11/slim/files pam.conf slim.sh.in
Wed, Jul 04, 2012 at 03:04:44PM -0700, Doug Barton wrote: Thanks for taking this one on. I was also looking at the new version of slim that's out recently: http://slim.berlios.de/ I am running 1.3.4 for some time: most of my workstations are fine with it, but one fails to start the desktop, though it has a mix of old and new packages, so I am rebuilding them just now. The patch is available at http://codelabs.ru/fbsd/ports/slim/upgrade-1.3.3-to-1.3.4.diff Testing and feedback are welcome. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpHjbwpTVksu.pgp Description: PGP signature
Re: DKIM-Milter in Freebsd 9.0
Hi!
This question really belongs to freebsd-ports, redirecting there.
Sat, Mar 10, 2012 at 05:41:27PM +, Elman wrote:
I install freebsd 9.0 release for the mail server, but no
dkim-milter in freebsd 9.0. I've been looking there, but it doesn't
exist and only open-dkim in freebsd 9.0. Is freebsd 9.0 no longer
providing dkim-milter again in freebsd port.? Before I was use
freebsd 8.2 for mail server, there are still exist dkim-milter. I
finally install dkim-milter from source and manual compile.
/usr/ports/MOVED suggests that
{{{
mail/dkim-milter|mail/opendkim|2011-11-23|Has expired: switch to mail/opendkim
instead
}}}
Since OpenDKIM provides the milter interface and dkim-milter
is no longer developed,
http://sourceforge.net/projects/dkim-milter/
I would suggest you to move to the OpenDKIM. Seems like the
README will help with installation and configuration,
http://opendkim.org/opendkim-README
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgp1CldM8rc7N.pgp
Description: PGP signature
Re: When to expect www/apache24
Sat, Mar 10, 2012 at 01:46:34PM +0100, Jake Smith wrote: Does anyone know when we can expect to see apache24 in the ports tree? Is a new port currently being worked on or is it waiting for someone to pick it up? I think that Apache mailing list for FreeBSD project will be the slightly better place to ask. Cc'ing there. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgp8hKVj0G8BN.pgp Description: PGP signature
Re: No working IDE in FreeBSD!
Thu, Mar 01, 2012 at 02:31:06PM +0200, Alexander Yerenkow wrote: I tried to take some time of Philip Paeps, but he is always busy with something. Maybe someone of you guys could be interested in filling request for open source license. Are you requesting someone to create FreeBSD port for this IDE or you meant something else? -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpMqHVL2jm9j.pgp Description: PGP signature
CFT: sudo 1.8.4p2
Good day.
I had submitted a PR with sudo update,
http://www.freebsd.org/cgi/query-pr.cgi?pr=165528
For your convinience, here are the patch
http://codelabs.ru/fbsd/ports/sudo/update-1.8.3p2-to-1.8.4p2.diff
and the shar(1) archive with new port version
http://codelabs.ru/fbsd/ports/sudo/update-1.8.4p2.shar
Patch should be applied like this,
{{{
cd /usr/ports
patch -p1 downloaded-patchfile
}}}
Can people who use sudo test the new port and reply to the PR
with positive or negative experience?
Replies should be directed to bug-follo...@freebsd.org
and the subject line should be set to
Re: ports/165528: [patch] security/sudo: update to 1.8.4p2
Thanks!
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpWV8VBcnkp5.pgp
Description: PGP signature
Re: CFT: OfflineIMAP 6.5.2.1
Mon, Feb 13, 2012 at 11:10:32AM +0400, Eygene Ryabinkin wrote: I had updated the OfflineIMAP port to 6.5.2.1 and it is currently being tested by me and some other persons. The patch is at http://codelabs.ru/fbsd/ports/offlineimap/port-update-6.4.0-to-6.5.2.1.diff I will be testing it for 2-3 more days on my environment, but the wider testing is appreciated. Testing showed two regressions, so the diff was updated and changes were submitted upstream. The URL for the patch is the same, additional testing is welcome, as always. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpDkdQk4vQTg.pgp Description: PGP signature
Re: [CFT] Hadoop preliminary port
Sun, Feb 12, 2012 at 11:57:03PM -0800, Bleakwiser wrote:
On Mon, Feb 13, 2012 at 1:49 AM, Eygene Ryabinkin-2 [via FreeBSD]
ml-node+s1045724n547842...@n5.nabble.com wrote:
Sun, Feb 12, 2012 at 11:44:03PM -0800, Bleakwiser wrote:
I know this isn't exactly the place for it but I really have no idea
what to
do with this .diff file.
Try
{{{
cd /usr/ports
fetch -o - http://people.freebsd.org/~clement/hadoop/hadoop-1.0.0.diff |
patch -p1
}}}
then go to the relevant port directory (devel/hadoop, I suppose)
and build the port.
Kidding right?
No, I am dead serious.
patch -p1 isn't even mentioned in the man pages.
'patch -p1' can't be mentioned on the man pages, because 'patch' is
the utility and '-p1' is the argument to that utility. Invoke 'man patch'
and look for '-p[number]'.
And again, i've ran,
patch hadoop-1.0.0.diff
Nothing happens, just blank cursor.
Well, it just happened that your mail reader broke the line starting
with 'fetch -o -' into two. You should invoke the command
{{{
fetch -o - http://people.freebsd.org/~clement/hadoop/hadoop-1.0.0.diff | patch
-p1 -E
}}}
with everything on one line: fetch should feed its output to the patch utility.
By the way, I forgot the -E flag -- it could be needed too.
For starters it isn't really clear what I'm even supposed to be applying
the patch to.
I think that the Wikipage article about patch is a good thing to start from,
http://en.wikipedia.org/wiki/Patch_%28Unix%29
In a nutshell, since you're doing 'cd /usr/ports', patchfile contents specify
that diffs are relative to the ports directory,
{{{
--- ports/devel/Makefile30 Jan 2012 09:15:00 - 1.4819
+++ ports/devel/Makefile1 Feb 2012 16:26:31 -
}}}
and -p1 instructs 'patch' utility to strip one directory level
from the file names to be patched, you'll be patching every file
that is mentioned in the diff, but without the leading 'ports/'
prefix, and the base directory will be the $PWD (/usr/ports).
If you really want to understand, what files will be patched, then
here we go:
{{{
$ fetch -qo - http://people.freebsd.org/~clement/hadoop/hadoop-1.0.0.diff |
grep -E '^(---|\+\+\+) ' | grep -v /dev/null | awk '{print $2;}' | sort | uniq
| sed -e's,^,/usr/,'
/usr/ports/GIDs
/usr/ports/UIDs
/usr/ports/devel/Makefile
/usr/ports/devel/hadoop/Makefile
/usr/ports/devel/hadoop/distinfo
/usr/ports/devel/hadoop/files/000.java_home.env.in
/usr/ports/devel/hadoop/files/datanode.in
/usr/ports/devel/hadoop/files/hadoop.in
/usr/ports/devel/hadoop/files/jobtracker.in
/usr/ports/devel/hadoop/files/namenode.in
/usr/ports/devel/hadoop/files/patch-build.xml
/usr/ports/devel/hadoop/files/patch-src__c++__libhdfs__hdfs.c
/usr/ports/devel/hadoop/files/patch-src__c++__libhdfs__hdfsJniHelper.c
/usr/ports/devel/hadoop/files/patch-src__native__Makefile.in
/usr/ports/devel/hadoop/files/patch-src__native__configure
/usr/ports/devel/hadoop/files/patch-src__native__configure.ac
/usr/ports/devel/hadoop/files/patch-src__native__src__org__apache__hadoop__io__nativeio__NativeIO.c
/usr/ports/devel/hadoop/files/patch-src__native__src__org__apache__hadoop__security__JniBasedUnixGroupsNetgroupMapping.c
/usr/ports/devel/hadoop/files/pkg-deinstall.in
/usr/ports/devel/hadoop/files/pkg-install.in
/usr/ports/devel/hadoop/files/secondarynamenode.in
/usr/ports/devel/hadoop/files/tasktracker.in
/usr/ports/devel/hadoop/pkg-descr
/usr/ports/devel/hadoop/pkg-plist
}}}
Again, the command, starting from 'fetch' and ending on 'sed'
must be on a single line.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpiLf0Y8brBf.pgp
Description: PGP signature
CFT: OfflineIMAP 6.5.2.1
Me again. I had updated the OfflineIMAP port to 6.5.2.1 and it is currently being tested by me and some other persons. The patch is at http://codelabs.ru/fbsd/ports/offlineimap/port-update-6.4.0-to-6.5.2.1.diff I will be testing it for 2-3 more days on my environment, but the wider testing is appreciated. Please, report any outcome, good or bad, from the update to this thread. Thanks! -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpRhPJPQsgOR.pgp Description: PGP signature
CFT: CUPS 1.5.2 and CUPS pstoraster 9.0
Ladies and gentlemen, good day. I had created the updates to the CUPS-related ports: the CUPS itself and cups-pstoraster, - http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/165084 the patch is at http://codelabs.ru/fbsd/ports/cups-pstoraster/update-to-9.0.diff - http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/164293 the patch is at http://codelabs.ru/fbsd/ports/cups/update-1.5.0-to-1.5.2.diff I had noticed that there were some threads in this list about problems with CUPS 1.5.0, the topic starters are included to the recipients of this message -- may be the raw update to 1.5.2 will help to solve the raised issues. If not, please, report the troubles to the respective PR. The update of cups-pstoraster is a way more intrusive: it had dropped the original ESP Ghostscript from cups.org, since it was merged with GNU Ghostscript years ago, http://www.cups.org/articles.php?L463+TNews+Q So, I just took the guts that are needed for CUPS and made them to use plain Ghostscript. The original espgs binary was turned into the wrapper for GNU Ghostscript, since many other ports depend on it. It will be very good if people will be able to test the both updates and report their findings (either positive or negative) to the respective PRs. For everyone's convinience, here are the subjects of mail to bug-follo...@freebsd.org that will make one to report his findings into these PRs: - CUPS 1.5.2: ports/165084: [patch] print/cups: upgrade to 1.5.2 - CUPS pstoraster 9.0: ports/164293: print/cups-pstoraster failed Thanks! -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpViILYDI0aC.pgp Description: PGP signature
Re: [CFT] Hadoop preliminary port
Hi.
Sun, Feb 12, 2012 at 11:44:03PM -0800, Bleakwiser wrote:
I know this isn't exactly the place for it but I really have no idea what to
do with this .diff file.
Try
{{{
cd /usr/ports
fetch -o - http://people.freebsd.org/~clement/hadoop/hadoop-1.0.0.diff | patch
-p1
}}}
then go to the relevant port directory (devel/hadoop, I suppose)
and build the port.
Then try to reading 'man diff' and 'man patch' and understand what
you did with the fetch/patch combo ;))
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpNv4T13L4ar.pgp
Description: PGP signature
CFT: Exim 4.77
Good day. I had created and tested at our local resources the update of mail/exim to 4.77. Here is the patch: http://codelabs.ru/fbsd/ports/exim/update-4.76-to-4.77.diff I will be grateful if other people can try it and report back if it works for them or not. The preferred way to reporting is the answer to the PR 161482: send mail to bug-follo...@freebsd.org setting Subject to Re: ports/161482: upgrade mail/exim to 4.77. Thanks! -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpm9hXfVgIw2.pgp Description: PGP signature
Re: INDEX build failed for 7.x
Sun, Sep 25, 2011 at 06:45:06PM +, Erwin Lansing wrote:
INDEX build failed with errors:
Generating INDEX-7 - please wait../a/erwin/tindex/ports/Mk/bsd.port.mk,
line 2323: Malformed conditional (${PREFIX} == /usr)
/a/erwin/tindex/ports/Mk/bsd.port.mk, line 2959: Malformed conditional
(${PREFIX} == /usr)
/a/erwin/tindex/ports/Mk/bsd.port.mk, line 3060: Malformed conditional
(${PREFIX} == /usr)
/a/erwin/tindex/ports/Mk/bsd.port.mk, line 3062: if-less else
/a/erwin/tindex/ports/Mk/bsd.port.mk, line 3064: if-less endif
/a/erwin/tindex/ports/Mk/bsd.port.mk, line 5774: Malformed conditional
((${PREFIX} != ${LOCALBASE} ${PREFIX} != ${X11BASE} ${PREFIX} !=
${LINUXBASE} ${PREFIX} != /usr))
/a/erwin/tindex/ports/Mk/bsd.port.mk, line 5779: if-less endif
/a/erwin/tindex/ports/Mk/bsd.port.mk, line 6292: if-less endif
/a/erwin/tindex/ports/Mk/bsd.port.mk, line 6295: if-less endif
make: fatal errors encountered -- cannot continue
=== databases/postgresql-docs failed
*** Error code 1
*** Error code 1
Sorry, it was me. I beleive it will be fixed with this commit:
http://lists.freebsd.org/pipermail/cvs-ports/2011-September/226337.html
At least it fixes that for me.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpL3AAfYvkcL.pgp
Description: PGP signature
Re: Same concerns about our postgresql and plpython ports
Thu, Sep 08, 2011 at 02:17:09PM +0400, Ruslan Mahmatkhanov wrote: Hi, for me it's too many time has passed for maintainer timeout. Please commit this anybody, until this port wasn't removed because it doesn't builds with some NOTEXISTENT PostgreSQL version. Ruslan Mahmatkhanov wrote on 31.08.2011 11:11: [...] http://www.freebsd.org/cgi/query-pr.cgi?pr=159842 2. postgresql-plpython unbreak: http://www.freebsd.org/cgi/query-pr.cgi?pr=159843 3. postgresql9x-client unbreak: http://www.freebsd.org/cgi/query-pr.cgi?pr=159844 Taking those three. Will test them on the coming Monday and will commit afterwards. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpip4MYn3Pad.pgp Description: PGP signature
Re: Same concerns about our postgresql and plpython ports
Fri, Sep 09, 2011 at 06:26:13PM +0400, Eygene Ryabinkin wrote: 3. postgresql9x-client unbreak: Taking those three. Will test them on the coming Monday and will commit afterwards. Hmm, actually only http://www.freebsd.org/cgi/query-pr.cgi?pr=159844 the others are already committed. Sorry, should have been checked them before writing the mail. -- rea ___ 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: Extra fields in INDEX
Chris, good day.
Fri, Aug 19, 2011 at 03:32:43PM +0100, Chris Rees wrote:
I'm having a look at modifying INDEX to have a field at the end (to
cause minimum breakage), but I've discovered that in a few ports there
(6630 out of 22731) appears to be extra 'stuff' in fields past field
10 (which is for the first WWW: line in pkg-descr).
Can anyone with knowledge of make index explain why this is happening?
Using the command line at [1] gets a list
[crees@hydra]~% alias findextrasinindex `make -C /usr/ports -V
INDEXDIR`/`make -C /usr/ports -V INDEXFILE` grep -n
'^\([^|]*|\)\{11\}[^|]\+'
This regexp won't catch empty field #12, so you're effectively counting
the number of entries with non-empty field #12:
{{{
$ cat INDEX-9 | cut -f 12 -d '|' | grep -v '^$' | wc -l
6221
$ grep -n '^\([^|]*|\)\{11\}[^|]\+' INDEX-9 | wc -l
6221
}}}
Every line in INDEX has 13 fields:
{{{
$ grep -n '^\([^|]*|\)\{12\}[^|]*$' INDEX-9 | wc -l
22287
$ wc -l INDEX-9
22287 INDEX-9
}}}
as every line in 'make describe':
{{{
$ make -C archivers/fastjar describe | tr '|' '\n' | wc -l
13
}}}
They have extra fields on the end ... Where have they come from??
There are no extra fields, but /usr/ports/Tools/make_index just
reorders them: the order becomes 0...6, 10, 11, 7...9, 12 if compared
to the initial field indices. What is effectively done by 'make
index' in the case of fastjar index line is the following:
{{{
(make -C archivers/fastjar describe; \
make -C lang/perl5.8 describe; \
make -C devel/gmake describe) | \
perl /usr/ports/Tools/make_index 2/dev/null | \
sed -e 's/ */ /g' -e 's/| */|/g' -e 's/ *|/|/g' -e 's./.^A.g' | \
sort -t '|' +1 -2 | sed -e 's.^A./.g' | grep ^fastjar
}}}
and '^A' here is the real '^A', not two chars '^' and 'A'.
make_index respects the trailing fields (those that come after 13th)
and they will be put to the end, so if you will add something
as additional trailing field produced by 'make describe', it will
survive piping through make_index and will be in its place in the
INDEX file.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpuCiHcPVrcG.pgp
Description: PGP signature
Re: Would anyone like to volunteer to take over sysutils/fcron?
Mon, Jul 18, 2011 at 08:10:49PM +0100, Chris Rees wrote: On 18 July 2011 19:47, Bob Eager r...@tavi.co.uk wrote: OK, I'll do it. My experience: two ports of my own released, plus two more I made for private use. Done. Bob, since you're the new maintainer for fcron, please, look at http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/152304 and do some real-life testing of the provided patch. Thanks! -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgplIPq95mJ1Q.pgp Description: PGP signature
Re: FreeBSD Port: minidlna-2010.12.12
Jan, good day. Fri, Feb 04, 2011 at 11:50:34AM +0100, Jan ??olc wrote: With help from the maker of miniupnpd I have done patches for minidlna. patch-ssdpd ??? minidlna can use minissdpd when you need using more upnp services at once (in example miniupnpd and minidlna simultaneously). patch-zsamsung ??? it???s latest patch for better cooperation with samsung televisions Cool, thanks for your work! I'd suggest to open the PR for this case to track the modifications. It is fairly easy, http://www.freebsd.org/doc/en/articles/problem-reports/article.html -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpKY0xGJ4Ems.pgp Description: PGP signature
Re: Busybox update, call for testers on amd64
Chris, good day. Tue, Jan 25, 2011 at 07:18:56PM +, Chris Rees wrote: New patch to stop use of utmp.h when FEATURE_UTMP is off. Try these now (I tried them in my Tinderbox for 9-CURRENT, so they do work on i386) Works on my amd64/-CURRENT host. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpbZ3t5XCdmC.pgp Description: PGP signature
Re: how do i suggest a program for your ports collection?
Thomas, good day.
Sun, Jan 23, 2011 at 08:25:23AM +0100, Thomas Dettbarn wrote:
is there some formal way of suggesting a program for your ports
collection?
Yes, it is described in
http://www.freebsd.org/doc/en/books/porters-handbook/book.html#PORTING-SUBMITTING
The thing is, i wrote this hex editor:
http://www.freshmeat.net/projects/dhex which i am rather proud of.
and now i would like to spread it.
You should create the port by yourself and become the maintainer
or you should find some other person who will do it (and become the
maintainer of the FreeBSD port for your software).
however, i am an openbsd user. so i don't know how to exactly make a
port for freebsd.
There is a Porter's Handbook,
http://www.freebsd.org/doc/en/books/porters-handbook/book.html
but if you don't want to port the stuff (or have not enough time),
I should say that having used DHEX for a couple of minutes I should
say that it is a good tool for my ocassional hex-related work, so
I can port and maintain it or I can help you to port it.
And may I also suggest the attached patch to the DHEX Makefile:
it will allow people to set their own values of CC, CFLAGS, CPPFLAGS
and LDFLAGS. For example, FreeBSD has the stock settings for the
CFLAGS and currently we can choose the compilers to be at least
gcc or clang. The stuff is described in
http://www.freebsd.org/doc/en/books/porters-handbook/book.html#DADS-CC
and
http://www.freebsd.org/doc/en/books/porters-handbook/book.html#DADS-CFLAGS
Hope that sheds some light on the topic.
And the additional nit: compiling dhex on the FreeBSD 9.x shows some
signedness warnings:
{{{
output.c: In function 'printmainmenu':
output.c:410: warning: pointer targets in initialization differ in signedness
output.c:411: warning: pointer targets in initialization differ in signedness
output.c:412: warning: pointer targets in initialization differ in signedness
output.c:413: warning: pointer targets in initialization differ in signedness
output.c:414: warning: pointer targets in initialization differ in signedness
output.c:415: warning: pointer targets in initialization differ in signedness
output.c:416: warning: pointer targets in initialization differ in signedness
output.c:417: warning: pointer targets in initialization differ in signedness
output.c:418: warning: pointer targets in initialization differ in signedness
output.c:419: warning: pointer targets in initialization differ in signedness
output.c:422: warning: pointer targets in initialization differ in signedness
output.c:423: warning: pointer targets in initialization differ in signedness
output.c:424: warning: pointer targets in initialization differ in signedness
output.c:425: warning: pointer targets in initialization differ in signedness
output.c:426: warning: pointer targets in initialization differ in signedness
output.c:427: warning: pointer targets in initialization differ in signedness
output.c:428: warning: pointer targets in initialization differ in signedness
output.c:429: warning: pointer targets in initialization differ in signedness
output.c:430: warning: pointer targets in initialization differ in signedness
output.c:431: warning: pointer targets in initialization differ in signedness
main.c: In function 'main':
main.c:450: warning: pointer targets in passing argument 3 of 'gotomask' differ
in signedness
main.c:459: warning: pointer targets in passing argument 4 of 'searchmask'
differ in signedness
main.c:509: warning: pointer targets in passing argument 3 of 'searchfor'
differ in signedness
configfile.c: In function 'readconfigfile':
configfile.c:183: warning: pointer targets in passing argument 2 of 'getcolors'
differ in signedness
configfile.c:184: warning: pointer targets in passing argument 2 of
'configkeytab' differ in signedness
}}}
I am not sure if they are harmful or harmless, but I usually it worth
to consider compiler's warnings. Don't know if you had seen them
on the systems you were testing/using DHEX, so reproducing them there.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
--- Makefile.orig 2011-01-23 11:09:21.676581518 +0300
+++ Makefile 2011-01-23 11:18:17.417579047 +0300
@@ -1,11 +1,12 @@
-CC= gcc
-LDFLAGS= -L/usr/lib -L/usr/local/lib -L/usr/lib/ncurses -L/usr/local/lib/ncurses
-CPPFLAGS= -I/usr/include -I/usr/local/include -I/usr/include/ncurses -I/usr/local/include/ncurses
-CFLAGS= -O3 -Wall -std=c99
+CC?= gcc
+LDFLAGS?= -L/usr/lib -L/usr/local/lib -L/usr/lib/ncurses -L/usr/local/lib/ncurses
+CPPFLAGS?= -I/usr/include -I/usr/local/include -I/usr/include/ncurses -I/usr/local/include/ncurses
+CFLAGS?= -O3
+CFLAGS+= -Wall -std=c99
#CFLAGS+= -ffunction-sections -fdata-sections
#LDFLAGS+= --gc-sections
LIBS= -lncurses
-DESTDIR= /usr/local/bin
+DESTDIR?= /usr/local/bin
OFILES=buffers.o input.o output.o
Re: Busybox update, call for testers on amd64
Chris, good day.
Sun, Jan 23, 2011 at 04:38:36PM +, Chris Rees wrote:
I've finished updating busybox to 1.18.1, but I need someone on amd64
to test it please!
It doesn't build on the 9-CURRENT, because of new utmpx:
{{{
CC libbb/messages.o
In file included from libbb/messages.c:51:
/usr/include/utmp.h:2:2: error: #error utmp.h has been replaced by utmpx.h
libbb/messages.c:59:2: error: #error unknown path to wtmp file
libbb/messages.c:65: error: expected expression before 'char'
}}}
It was amd64 machine, but the error will show up for i386
and others: bb still uses utmp.h that was deprecated starting
from 9.x.
Seems like that the fair number of files should be adopted
to 9.x:
{{{
./libbb/messages.c:#include utmp.h
./libbb/utmp.c:#include utmp.h
./loginutils/login.c:# include utmp.h /* USER_PROCESS */
./loginutils/getty.c:# include utmp.h /* LOGIN_PROCESS */
./loginutils/getty.c:#ifdef LOGIN_PROCESS/* defined in
System V utmp.h */
./coreutils/who.c:#include utmp.h
./init/init.c:# include utmp.h /* DEAD_PROCESS */
./init/halt.c:#include utmp.h
./miscutils/last.c:#include utmp.h
./miscutils/runlevel.c:#include utmp.h
./miscutils/last_fancy.c:#include utmp.h
./miscutils/wall.c:#include utmp.h
./networking/telnetd.c:# include utmp.h /* LOGIN_PROCESS */
}}}
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpIlSoTFLBE7.pgp
Description: PGP signature
Re: Attention ports committers
Joeb, good day.
Wed, Jan 19, 2011 at 11:59:24AM -0500, joeb wrote:
Eygene Ryabinkin you sure missed the point of my post. Your
forensic investigation of my port is far outside the review of the
make file to commit the port.
That is my personal opinion as if I would wrote the port myself and
will then critically review it. If I am committing something, I am
trying to make it as good as I can, at least in the majority of cases.
Scrubbing through your email content I only see you voicing your
personal preferences without any makefile statement errors, which
would make the Makefile invalid. This is a very simple Makefile so
lets not make a mountain out of a molehill.
Do you realize that not every valid Makefile will be perfectly
maintainable? That's like a program that does the current work, but
if you'll look at it in the perspective of maintaining it and making
further modifications, it poses some challenges, because, in our case,
many standard constructs aren't used and substitute for the homebrew
ones.
Almost all my comments were related to the constructs that can be
substituted by the standard FreeBSD port makefile ones. And users
of the ports expect the standard behaviour from the ports, so native
constructs are almost always better than the ones written by hand,
just because they
a. provide the standard behaviour now;
b. will provide it later even if the behaviour will be redefined
or extended; no one should rewrite the Makefile or, in the
worst case, it should be only lightly touched.
And using standard constructs you'll get this basically for free:
that's good, isn't it?
The port description is within the max size and is very
detailed on purpose. I plan to keep it that way.
Porter's Handbook,
http://www.freebsd.org/doc/en/books/porters-handbook/book.html#AEN89
asks the pkg-descr to be concise, so if you really want the
detailed description, you should justify it. And not just because
it is long to my taste, but because the standard rules are saying
it too.
While I must confess that we have even 154-line pkg-descr file in the
current tree (sysutils/dirdiff and it just copies the README/INSTALL,
the thing that the handbook warns about), you can glance at the
statistics
{{{
Ports Lines
1 154L
1 65L
1 57L
1 56L
1 53L
2 52L
1 50L
1 48L
2 47L
3 46L
3 45L
1 43L
1 42L
1 41L
1 39L
3 38L
4 37L
2 36L
1 35L
3 34L
4 33L
4 32L
8 31L
5 30L
5 29L
10 28L
17 27L
18 26L
20 25L
214 24L
208 23L
226 22L
237 21L
248 20L
305 19L
274 18L
338 17L
395 16L
424 15L
561 14L
592 13L
777 12L
851 11L
1076 10L
1252 9L
1467 8L
1839 7L
2251 6L
2427 5L
2521 4L
2464 3L
242 2L
267 1L
}}}
and get a feeling of how the length distibution looks like.
Everything that is longer than 24 lines has negligible contribution,
something like 0.2%.
The whole point of the post is that I am not a port Makefile coder.
I wrote a script for jails and it has taken longer to get the
Makefile correct then the coding of the original qjail script.
May I ask, had you read the Porter's Handbook before you had started
creating your Makefile or you had adopted some other port sources?
I have a gut feeling that the latter case was in action.
If the install of the RC_SUBR script can be done in a more reliable
way then what I need is the Makefile statements to perform this
action so I can update the port (shar) file with them.
The goal here is to get this port committed, not waste time trying
to teach me the secret internal details of port makefiles
construction.
If you want to produce the good FreeBSD port, then you'll need to
know some internals. Becides, they aren't real internals, most
of stuff I am saying about the Makefile is written in the Porter's
Handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/book.html
Nothing I am telling about the port is the Real Arcane Stuff (TM).
You can freely skip the part of my review that touches the code
of the qjail and its manual pages; I just wanted to share some
experience that I thought would be handy for you and, perhaps,
other people.
My goal was to create the compact port that will be almost
perfect ;))
With all respect.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpo9iT5MvK90.pgp
Description: PGP signature
Re: Help with audio/mangler and gsm
Janik, good day.
Sat, Jan 15, 2011 at 10:26:32PM -0500, Janik Galasso wrote:
Here's the error I get when trying to configure it with the gsm codec
(which was installed when I activated it in multimedia/ffmpeg)
checking for gsm_create in -lgsm... no
Error: cannot find libgsm: Is it installed? Also make sure you have the
libgsm development packages installed.
exit: Illegal number: -1
=== Script configure failed unexpectedly.
Please report the problem to ja...@hikarihq.com [maintainer] and attach
the
/usr/ports/audio/mangler/work/mangler-1.2.1/config.log including the
output
of the failure of your make command. Also, it might be a good idea to
provide
an overview of all packages installed on your system (e.g. an `ls
/var/db/pkg`).
*** Error code 1
Stop in /usr/ports/audio/mangler.
*** Error code 1
Try using
{{{
CONFIGURE_ENV= CFLAGS=${CFLAGS} LDFLAGS=${LDFLAGS}
CFLAGS+=-I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib
}}}
inside you port's Makefile if you really have the audio/gsm
installed and configure just unable to locate it.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpHgdaM3sANN.pgp
Description: PGP signature
Re: multimedia/libxine (libxine-1.1.19_1) (fetch error)
Sun, Jan 16, 2011 at 10:30:30AM +, David Southwell wrote: Thanks in advance for a fix for: [...] Was already fixed by makc@, http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/libxine/Makefile.diff?r1=1.164;r2=1.165 please, update your ports, and try again. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgp71YvoRIXgT.pgp Description: PGP signature
Re: multimedia/libxine (libxine-1.1.19_1) (fetch error)
John, good day. Sun, Jan 16, 2011 at 12:01:21PM +0100, John Marino wrote: 1) David Southwell found a problem with the libxine port missing a source file 2) He posted what he found here, expecting it to be fixed (presumably immediately) Wouldn't the proper procedure be to document this in a problem report so it can go through the established process? The best is to fill a PR, because is most likely won't be lost in the noise or forgotten and it will keep the history of an entire problem. But there are other means, for example, the problem David was referred to was fixed as the result of the IRC chat with Maxim, as said in the commit message http://lists.freebsd.org/pipermail/cvs-ports/2011-January/210424.html IRC/Jabber/e-mail is likely the best for the simple problems, but if they aren't addressed quickly -- open the PR. The definition of quickly is rather vague and left for the originator's discretion ;)) What I can't get a feel for is how long it actually takes to process a PR. It obviously depends on a PR's content, the people who're on the loop, the time period (ports freeze, etc) and so on. I had seen PRs that were closed in tenth of minutes and I had seen PRs that stay in the queue for years. Everything depends on the specifics of the problem and the people who are involved in the loop. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpF9xbymWXr5.pgp Description: PGP signature
Re: Help with audio/mangler and gsm
Ruslan, good day.
Sun, Jan 16, 2011 at 02:26:27PM +0300, Ruslan Mahmatkhanov wrote:
There is also --disable-gsm in CONFIGURE_ARGS that should be removed.
Judging by
{{{
checking for gsm_create in -lgsm... no
Error: cannot find libgsm: Is it installed? Also make sure you have the
libgsm development packages installed.
exit: Illegal number: -1
}}}
in the original post, Janik already enabled GSM library, because
autoconf-produced configure won't check for the functions that
live in the disabled components.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpZl48zc7HYw.pgp
Description: PGP signature
Re: Attention ports committers
Sat, Jan 15, 2011 at 02:05:40AM -0800, per...@pluto.rain.com wrote: Eygene Ryabinkin r...@freebsd.org wrote: And please, please, please, try to put your shar(1) archive somewhere to the Web and add the link to the PR: mail over gnats if not uuencoded properly makes attachments with partial quoted-printable stuff left ... Sounds as if Sec. 3.6 of the Porter's Handbook needs a revision Sorry, I should have been more precise: the shar(1) archive from the original submission is just fine, because it was sent by the send-pr. But the shar(1) archives from the followups resulted from the fixes of the port content were sent by the ordinary mailer as attachments and were attachments were encoded as quoted-printable. query-pr.cgi currently is not good at handling them and giving away unencoded content in all cases. I have plans to improve query-pr.cgi, but not instantly. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgp8FmXY7ab9e.pgp Description: PGP signature
Re: snort and daq ports
Dean, good day. Fri, Jan 14, 2011 at 05:03:19PM -0500, Dean Freeman wrote: I've submitted an update to the Snort port which will bring it to 2.9.0.3, as well as a port for DAQ, which is a dependency for current versions of snort in the 2.9.x branch and higher. I'll take care of the DAQ stuff. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpxrE6wLCzKh.pgp Description: PGP signature
Re: Attention ports committers
Good day.
Fri, Jan 14, 2011 at 01:18:52PM -0500, joeb wrote:
I would like to draw the attention of a ports committer to port
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148777
If it needs further work please provide feedback.
A couple of things about the port:
- you can just use plain SF instead of a long to type
${MASTER_SITE_SOURCEFORGE}; moreover, plain SF/${PORTNAME}
and no MASTER_SITE_SUBDIR will work too and save you
one more line;
- share/examples/qjail in the pkg-plist is better spelled
as %%EXAMPLESDIR_REL%%; and its ${PREFIX}/share/examples/qjail
in the Makefile should really be ${EXAMPLESDIR}; also
you can consider using PORTEXAMPLES to use port's procedures
to install the examples and to avoid installing them when
NOPORTEXAMPLES is set;
- it is better to remove the commented DISTFILES, since
it is not needed thus just adds the visual clutter;
- pkg-descr is a way too chatty (in my taste); it can be
definitely stripped down to provide the idea about
what qjail is and the whole text can be put to the
project's Web site;
- you can put your rc.d script into USE_RC_SUBR inside
the Makefile; just put your scripts into WRKDIR during
the build phase; this will enable your port to survive
any modifications to the process of installation of
the rc.d scripts, because they will be handled by the
ports subsystem;
- pkg-message can be stripped down as well: first line
looks redundant, since people already know why they
had installed the port; the other two lines, perhaps,
can be condensed into Read qjail-intro(8) for to get
started. The said manual page has reference to the
qjail(8), so people will know what to do after reading
the introduction.
And please, please, please, try to put your shar(1) archive somewhere
to the Web and add the link to the PR: mail over gnats if not
uuencoded properly makes attachments with partial quoted-printable
stuff left, so download of, for example,
http://www.freebsd.org/cgi/query-pr.cgi?prp=148777-3-sharn=/shar-3.sh
will give a non-working shar(1) archive for starters and when '=0A='
will be removed, one will need to dance with the QP '=' characters,
newlines and alike.
May I also add, your software's manual pages can be improved:
- don't insert empty lines into the groff files, use the
lone dot if you want the visual separator inside the
groff sources;
- use standard macros like .Pa, .Xr, .Nm, .Qq and others
instead of doing bold font, quoting and other stuff by hand;
- avoid unneeded usage of the bold attribute; for example,
qjail-intro(8) needs no bold for the 4th generation,
user friendliness and other stuff;
- start each sentense inside the manual source from the
new line: this will provide two spaces between sentences
in the formatted manual pages and will ease the diffs
between revisions of the makefile (for you and other
developers of the qjail, because this way changes in the
manual pages will show up in the diff output only inside
their own sentenses; they won't have the parts of other
sentences in the + and - lines and that's good);
- you have many trailing spaces; whilst they typically do
not harm, why to keep them?
And for the qjail scripts themselves:
- currently qjail is a single block with no subroutines;
it _may_ be better to split it into logical parts,
because it will be easier to read, navigate and understand
for Other People (TM) ;))
- perhaps you'll be able to use exit codes from sysexits(3).
- what does jail2 rc.d script? It terribly reminds me
/etc/rc.d/jail and diffing the two one finds mostly
cosmetic differences. So, what's the point of having
jail2 at all?
Sorry for a long letter and slightly mentorish tone: meant
no offense, just wanted to improve the stuff.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpS1sPQSOaRR.pgp
Description: PGP signature
Re: Attention ports committers
Sat, Jan 15, 2011 at 12:46:02AM +0300, Eygene Ryabinkin wrote:
A couple of things about the port:
[...]
Two more things.
There is INSTALL_MAN macros that should be used for manpage
installation. Also, ${MANPREFIX}/man/man8/ is better spelled as
${MAN8PREFIX}/man/man8/ and you can use the following construct:
{{{
.for m in ${MAN8}
${INSTALL_MAN} ${WRKSRC}${m} ${MAN8PREFIX}/man/man8/${m}
.endfor
}}}
to automate the installation.
Perhaps, ${CAT} ${PKGMESSAGE} is better be silenced by writing
'@${CAT} ${PKGMESSAGE}'.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgp4NtyfSjpBi.pgp
Description: PGP signature
Re: Attention ports committers
Fri, Jan 14, 2011 at 10:47:36AM -0800, Chuck Swiger wrote: Have you addressed the problems mentioned by Chris Rees utis...@gmail.com yet? Almost all of them were addressed, as I can judge. But I had spotted some more nits ;)). -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgp3j5twM0z62.pgp Description: PGP signature
Re: incomplete pkg-plist for print/teTeX-texmf
Anton, good day.
Mon, Jan 10, 2011 at 02:01:45PM +, Anton Shterenlikht wrote:
I think there are five ls-R files, installed by teTeX-texmf,
which are not included in pkg-plist.
% cat ls-R-which.sh
#!/bin/sh
for file in `find /usr/local/share/texmf* -name ls-R`
do
echo $file
pkg_info -W $file
done
% ./ls-R-which.sh
/usr/local/share/texmf/ls-R
/usr/local/share/texmf-config/ls-R
/usr/local/share/texmf-dist/ls-R
/usr/local/share/texmf-dist/ls-R was installed by package teTeX-texmf-3.0_6
/usr/local/share/texmf-local/ls-R
/usr/local/share/texmf-var/ls-R
Others belong to tex-texmflocal package:
{{{
$ cd /var/db/pkg grep -r ls-R . | grep unexec
./teTeX-texmf-3.0_6/+CONTENTS:@unexec rm -f %D/share/texmf-dist/ls-R
./tex-texmflocal-1.9/+CONTENTS:@unexec /bin/rm -f /usr/local/share/texmf/ls-R
/dev/null 21 || true
./tex-texmflocal-1.9/+CONTENTS:@unexec /bin/rm -f
/usr/local/share/texmf-local/ls-R /dev/null 21 || true
./tex-texmflocal-1.9/+CONTENTS:@unexec /bin/rm -f
/usr/local/share/texmf-var/ls-R /dev/null 21 || true
./tex-texmflocal-1.9/+CONTENTS:@unexec /bin/rm -f
/usr/local/share/texmf-config/ls-R /dev/null 21 || true
}}}
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpvAMInyRF3f.pgp
Description: PGP signature
Re: incomplete pkg-plist for print/teTeX-texmf
Mon, Jan 10, 2011 at 02:54:26PM +, Anton Shterenlikht wrote: But still, why doesn't pkg_info -W say so? Because it operates on the real entries of +CONTENTS, but ls-R are created via @exec and removed via @unexec. From the other hand, @unexec is spawned after the ls-R from teTeX-texmf will be removed, so such construction (when some file contains both in the pkg-plist and is removed via @unexec using rm -f file) will be harmless and will make that file to appear in 'pkg_info -W file'. I don't know what is the general policy for such occurences, porter's handbook has no such information and I had faced such thing for the first time. Anyone? -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpYmFlqnCxTt.pgp Description: PGP signature
Re: FreeBSD Port: sysutils/userinfo
Ben, good day.
Sun, Jan 09, 2011 at 10:54:28AM -0500, Ben Kibbey wrote:
I noticed a build failure for the userinfo utility not too long ago.
There is no longer a ports maintainer for this one so I thought I'd try
to get it fixed here. Could someone see if the following patch fixes it
as I don't have a FreeBSD box.
I believe that the attached patch will fix the utility. The need of
login.{h,c} hunks is obvious, the need for the configure one should
be explained, I think. At my machine when I had compiled the code
the number of the active sessions was 0; so getutxent() will return NULL.
I think that the test should really be using UTXDB_LOG that has all
entries for utmpx. And that check was implemented.
Two more nits:
- I wasn't able to invoke 'ui -O login.so -la -- `users`', it were
giving me the main help until I had killed the chaining test
just after option parsing;
- at least login.c uses unsafe constructions like
{{{
for (i = 0; i cnt; i++) {
...
strncat(line, buf, sizeof(line));
...
}
}}}
It won't protect you from overrunning 'line', because the last
argument of that strncat specifies how many bytes from _buf_
we want to copy at most. You will likely want to read the
Security considerations section of
http://www.freebsd.org/cgi/man.cgi?query=strncatapropos=0sektion=0manpath=FreeBSD+8.1-RELEASEformat=html
or to use strlcpy/strlcat (but they aren't the standard ones
on all platforms).
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
--- src/modules/login.c.orig2011-01-09 22:06:08.813688876 +0300
+++ src/modules/login.c 2011-01-10 00:27:50.225685582 +0300
@@ -24,7 +24,6 @@
#include time.h
#include pwd.h
#include ctype.h
-#include utmp.h
#ifdef HAVE_CONFIG_H
#include config.h
@@ -32,6 +31,11 @@
#include login.h
+#ifndef FREEBSD_UTMPX
+/* FreeBSD with utmpx support has utmp.h that will #error us. */
+#include utmp.h
+#endif
+
#ifndef HAVE_STRSEP
#include ../strsep.c
#endif
@@ -338,6 +342,40 @@
return;
}
+#ifdef FREEBSD_UTMPX
+/*
+ * Get the last login data for the given user
+ * via utmpx(3) interface.
+ *.
+ * Has a side effect of setting the current database
+ * to the LASTLOGIN one.
+ */
+static char *lastloginx(const char *name, char *tf)
+{
+static char buf[LINE_MAX];
+struct utmpx *last = NULL;
+
+if (setutxdb(UTXDB_LASTLOGIN, NULL)) {
+warn(setutxdb(UTXDB_LASTLOGIN));
+return NULL;
+}
+
+while ((last = getutxent()) != NULL) {
+if (last-ut_type == USER_PROCESS
+strcmp(last-ut_user, name) == 0)
+break;
+}
+if (last == NULL)
+return NULL;
+
+snprintf(buf, sizeof(buf), %s,%s,%s,
+ (last-ut_line[0] == '\0' ? ! : last-ut_line),
+ (last-ut_host[0] == '\0' ? - : last-ut_host),
+ stamp(last-ut_tv.tv_sec, tf));
+
+return buf;
+}
+#else /* defined(FREEBSD_UTMPX) */
/* Get the lastlog structure from the lastlog file. */
static char *lastlogin(uid_t uid, char *tf)
{
@@ -423,6 +461,7 @@
return buf;
}
+#endif /* defined(FREEBSD_UTMPX) */
/* This will return an array of utmp structures if a user is logged in, NULL
* otherwise. We'll try to keep the utmp file descriptor open if possible to
@@ -452,10 +491,18 @@
login_count = 0;
#ifdef UTMPX_FORMAT
+#ifdef FREEBSD_UTMPX
+setutxent();
+#else
setutent();
+#endif
while ((u = getutxent()) != NULL) {
+#ifdef FREEBSD_UTMPX
+ if (strcmp(u-ut_user, user) == 0) {
+#else
if (strcmp(u-ut_name, user) == 0) {
+#endif
#else
lseek(fd, 0, SEEK_SET);
@@ -481,7 +528,11 @@
strncpy(logins[login_count]-ut_host, u-ut_host, UTX_HOSTSIZE);
logins[login_count]-ut_pid = u-ut_pid;
#else
+#ifdef FREEBSD_UTMPX
+ strncpy(logins[login_count]-ut_user, u-ut_user, UT_NAMESIZE);
+#else
strncpy(logins[login_count]-ut_name, u-ut_name, UT_NAMESIZE);
+#endif
strncpy(logins[login_count]-ut_line, u-ut_line, UT_LINESIZE);
strncpy(logins[login_count]-ut_host, u-ut_host, UT_HOSTSIZE);
logins[login_count]-ut_tv.tv_sec = u-ut_tv.tv_sec;
@@ -639,7 +690,13 @@
add_string(strings, (u) ? idle(u, multi) : !);
break;
case 'l':
- last_strings(lastlogin(pw-pw_uid, tf));
+ last_strings(
+#ifdef FREEBSD_UTMPX
+ lastloginx(pw-pw_name,tf)
+#else
+ lastlogin(pw-pw_uid, tf)
+#endif
+ );
break;
case 'h':
for (i = 0; i login_count; i++) {
--- src/modules/login.h.orig2011-01-09 23:40:11.136688587 +0300
+++ src/modules/login.h 2011-01-09 23:41:18.568686438 +0300
@@ -51,6 +51,9 @@
#endif
#ifdef UTMPX_FORMAT
+#ifdef __FreeBSD__
+#define FREEBSD_UTMPX
+#endif
Re: mplayer options patch
Fri, Jan 07, 2011 at 09:58:17AM +, Anton Shterenlikht wrote:
Error: Runtime CPU detection only works for x86, x86-64 and PPC!
Here's a patch:
--- Makefile 2010-12-03 03:38:31.0 +
+++ Makefile.new 2011-01-07 09:38:50.0 +
@@ -13,7 +13,7 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS= DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+=RTCPU Allow runtime CPU detection on
+OPTIONS+=RTCPU Allow runtime CPU detection off
OPTIONS+=OCFLAGS Use optimized compiler flags on
OPTIONS+=IPV6 Include inet6 network support on
OPTIONS+=X11 Enable X11 support for mplayer's video output on
It would be better to make it conditional on ARCH, but
I don't know how to do it.
Please, try the following snippet:
{{{
.if ${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc
OPTIONS+= RTCPU Allow runtime CPU detection on
.else
OPTIONS+= RTCPU Allow runtime CPU detection off
.endif
}}}
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpFg3IMvCRy7.pgp
Description: PGP signature
Re: mplayer options patch
Fri, Jan 07, 2011 at 01:32:39PM +, Anton Shterenlikht wrote:
I don't think I need to change any other options from
the current default to make it build and run on my ia64.
So if this patch seems reasonable, can somebody submit it?
many thanks
anton
--- Makefile 2010-12-02 09:18:00.0 +
+++ Makefile.new 2011-01-07 11:16:56.0 +
@@ -13,7 +13,6 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS= DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+=RTCPU Allow runtime CPU detection on
OPTIONS+=OCFLAGS Use optimized compiler flags on
OPTIONS+=IPV6 Include inet6 network support on
OPTIONS+=X11 Enable X11 support for mplayer's video output on
@@ -75,6 +74,12 @@
BROKEN= Does not compile on sparc64
.endif
+.if ${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc
+OPTIONS+= RTCPU Allow runtime CPU detection on
+.else
+OPTIONS+= RTCPU Allow runtime CPU detection off
+.endif
Having thinked about it for a while, I wonder if we need to have
RTCPU knob on non-{i386,amd64,powerpc}? From the one hand, the
knob isn't functional, so it is redundant, because mplayer will
refuse to build. On the other hand, once mplayer will gain the
ability to make run-time CPU detection on other platforms, this
knob will be usable again and it will be good to add it to the
relevant architectures.
I think that this should be left to the maintainers decision.
Please, submit a PR that describes the problem and contains
the patch. If submitting PR is something you hadn't done before,
please, take a look at
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html
You can add me to the X-GNATS-Notify header -- I'll take the PR
and once/if Thomas will approve it, I'll commit the modifications.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpRMftPbUoMb.pgp
Description: PGP signature
Re: C12
Thu, Dec 30, 2010 at 01:41:32PM +, Robin Carey wrote: I have written (and perfected) some open source software called C12. It is an E-mail security and file encryption/decryption tool for *BSD and Linux. Out of curiosity, what was changed in the C12 since the original advertising in 2006, https://groups.google.com/group/comp.security.pgp.tech/browse_thread/thread/f9539971798f15a1?hl=am# -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpvmTGmmo6Ql.pgp Description: PGP signature
Re: multimedia/mencoder - why do we build it without fontconfig support?
Thu, Dec 30, 2010 at 06:53:09PM +0100, Michal Varga wrote: So the question stands - is there anything to gain by having fontconfig support forcefully disabled? After all this is mencoder we're talking about, one dependency more or less is just a drop in the ocean. And the current state really makes our mencoder kind of crippled... That's an almost obvious statement, but we can introduce an OPTION for the fontconfig support. What to have as the default, ON or OFF, is the question about why currently fontconfig is disabled. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpf7d6JLT4O1.pgp Description: PGP signature
Re: portmaster: print /usr/ports/UPDATING on update
Tue, Dec 28, 2010 at 04:31:08PM -0800, Doug Barton wrote: You bring up a very good point here that someone in #bsdports also mentioned, that having UPDATING in xml would allow us to easily produce an HTML version of the file for use on the web site. Yes, third-party that may use the UPDATING.ng is the very good argument for the standard format. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpPVtmwwJNbU.pgp Description: PGP signature
Re: portmaster: print /usr/ports/UPDATING on update
Wed, Dec 29, 2010 at 01:00:47PM +0100, Lars Engels wrote: Is anyone aware of pkg_updating(1)? It's in base for 2 years. No, thanks for the hint. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgplXy6Zg5wAX.pgp Description: PGP signature
Re: portmaster: print /usr/ports/UPDATING on update
Peter, good day.
Tue, Dec 28, 2010 at 10:27:55AM +0200, Peter Pentchev wrote:
- I personally would prefer a human-readable file (and yes, I *can*
read XML; that doesn't mean it's easy or I *want* to :)
...so how about a JSON representation? Human-readable, human-editable,
but still capable of being formalized and validated
JSON is a bit better (it has no tag overwhelming), but why not just
adopt the current mail-like entry format with each entry idented at two
spaces and preceded by a timestamp in format 'MMDD:'?
It is fairly easy to write a validator for such entries, since it is
rather simple to parse it and the validation logics will be programmed
in any way if we will still lean toward the human-readable format.
There is JSON Schema, but this way we will need something like
{{{
{date: 20100101,
affected:{
category:www,
name:elinks,
version:blah
}
body:a long body comes here
}
}}}
to validate the individual category, name, version and others.
Such entries are human-readable, but not as pretty as the current
UPDATING entries, in my opinion.
- ...and as for an implementation, there is a mini-JSON library in
NetBSD's netpgp implementation -
src/crypto/external/bsd/netpgp/dist/src/libmj/ in NetBSD CVS
Does it has the schema validation? From what I seen at the NetBSD
CVS, there is not XML Schema implementation yet.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster: print /usr/ports/UPDATING on update
see such entries if he upgrades the port X from version N to the version = N. Entries of type b tend to say the following: if you had ports A, B, C, ... installed before the date Z, then you should do so-and-so to upgrade them without troubles. So, user should see such entries if either A, B, C, ... are upgraded and old version of ports being upgraded were built before the date Z. There can also be differences in when user should see the UPDATING entries: before or after port building/installation. Some entries can say in order to successfully build port A, you should to smth; others can say you can remove this-and-that after you had upgraded port B. So, the tool that will present the relevant updating entries should have at least the following modes: - show me all UPDATING entries that will affect my upgrade (of the whole ports tree, for starters); - show me UPDATING entries I should read before upgrading port X; - show me UPDATING entries I should read after upgrading port X. I think that the syntax/semantics problem is more-or-less orthogonal to the matters of the UPDATING source language and tools that are used to create/maintain it, and, to some extent, this problem is much more vital to the business of making UPDATING entries to be user-presentable. Since I am trying to push the pkg_audit tool (that will intersect the currently-installed ports and auditfile to give the caller that set of VuXML entries that are applicable to his ports) to the base, I am more-or-less familiar of a business of writing such a tool, so I am taking the responsibility to write it once (and if) we will agree on how to move UPDATING to the next stage of its life. And I'll try to make the architectural stage of these changes to be alive too. But in order to move this activity any further, I'll need for a constructive feedback. I think that I'll try to summarize the current thoughts at the FreeBSD Wiki, will post the link once I'll do that. Sorry for a long letter ;)) -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpDQJouUwhz7.pgp Description: PGP signature
Re: portmaster: print /usr/ports/UPDATING on update
Tue, Dec 28, 2010 at 11:31:13PM +0300, Eygene Ryabinkin wrote: But in order to move this activity any further, I'll need for a constructive feedback. I think that I'll try to summarize the current thoughts at the FreeBSD Wiki, will post the link once I'll do that. http://wiki.freebsd.org/EygeneRyabinkin/PortsUpdatingNg -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpjt9HApPp7h.pgp Description: PGP signature
Re: problem with port gobject-introspection on 9.0-CURRENT
Sun, Dec 26, 2010 at 02:49:40PM +0100, Goran Gajic wrote: I am using glib-2.26.1_1 built from ports too as I have started with complete fresh 9.0-CURRENT (removed all previously installed ports and with no ports installed at all in chroot environment).. OK. Can you show the contents of your /usr/local/share/gir-1.0 directory? I can't reproduce your problem on the fresh i386/9-CURRENT box, so I suspect that something in your current configuration breaks g-ir stuff. Thanks! -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster: print /usr/ports/UPDATING on update
Mon, Dec 27, 2010 at 05:57:53PM -0800, Doug Barton wrote:
The Real AnswerTM is that we need a tool with striking similarities to
portaudit. The basic idea would be that UPDATING entries would be done
in xml, and then the user can either run portupdating (or whatever the
name ends up being, that's a really bad name but I suck at naming tools)
either by default for their whole system, or vs. a specific port. I
would strongly recommend that the behavior, command line options, etc.
be consistent with portaudit. Download it and check the man page if
there are any questions. :)
There are two questions that arise with this approach:
- we should find a way to keep an old UPDATING file in place;
obviously, it can be easily created from the XML file, but
currently UPDATING is delivered via CVS and it will be good
to allow this behaviour even with the XML'ized version;
but keeping the plain-text UPDATING in CVS while UPDATING.xml
will be used is a bad idea -- UPDATING will be non-master
file, so its history will be redundant. From the other hand,
we have no XML tools in the base tree, so UPDATING can't be
easily created from the XML version at the user machine;
- currently, UPDATING has only port names, but not their versions;
one takes the entry timestamp and if he had not yet upgraded
the relevant port(s) after this timestamp, then the corresponding
entry is for him. I see there two cases:
a) there is a specific port version at which some crucial change
that demands the UPDATING entry had happened; if the version
specification will be included in UPDATING, then we won't
even need the timestamp -- one should just take the currently
installed version and the version to be installed; the the
entry's version lies between those two, user will surely need
to read the UPDATING entry;
b) there is a infrastructural changes that affect all or some ports
that will be built after some date; again, the logics of choosing
the entry to be presented is the same as above, but one should use
timestamps, not ports versions.
But having thinked about this a bit, now I am favoring another approach:
one should not rely on the portmaster/portupgrade/OtherTool to present
the UPDATING entries: the best place is the ports infrastructure itself
(or pkg_install suite). This way, any tool that will do upgrades will
receive the UPDATING stuff for free.
Currently I am trying to figure out if it will be sufficient to have the
appropriate machinery in the pkg_delete tool: the old port version and
timestamp are already there; the new timestamp is more-or-less the
current date; the only needed piece is the new port version. It can be
provided via the environment variable by the portmaster-like tool; such
variable will trigger the processing of the UPDATING file. This is
rather rough plan, feel free to correct/criticize it or show why it is
not doable using such approach.
The other thing this entails is portmaster actually storing
information of its own completely aside from /var/db/{pkg|ports}. I'm
really sort of nauseous about that whole idea since it's a slippery
slope that I don't want to travel down. But I'm not seeing any other
way to accomplish the task of make sure that the user knows that they
should read UPDATING without doing something very much like this. Of
course, if someone else has a better idea, I'm all ears. :)
What I do _not_ want to do is write an UPDATING text file parser
myself. Not only do I think that's a bad idea generally, it's not a
project that I am at all interested in, and I don't see it as
something that should be part of portmaster to start with. I could be
talked into the UPDATING.xml project if someone were to come up with
funding for it, but (just being frank and honest) it's too big a
project for me to tackle on a volunteer basis atm.
I had shown the simple shell script that will parse the UPDATING and
present the entries for the given port if the fall into the last N
days category. If you had missed it -- ping me, I'll show it to you
once again.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster: print /usr/ports/UPDATING on update
David, good day. Sat, Dec 25, 2010 at 12:16:05PM +0100, David Demelier wrote: Each entry in UPDATING is like AFFECTS: users of net-mgmt/flowd so if an update of net-mgmt/flowd is available and a *recent* entry in UPDATING talks about then print the message. This can prevent a lot of breakage and useless noise on lists. What do you think ? I think that the attached script is a good starting point. Comments are welcome ;)) And, for sure, it will be good to enforce the AFFECTS line to contain the full port origin (or shell glob of it). This can be trivially done as the script that will periodically check the UPDATING and mail people about troubles. I can write it if this will be really needed. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster: print /usr/ports/UPDATING on update
Sat, Dec 25, 2010 at 07:38:14PM -0600, Ade Lovett wrote: Just be prepared for infrastructural changes, for which working out a specific AFFECTS line would take longer than the patch itself, to simply say: AFFECTS: * The point is taken, thanks! Updated script is attached. It - adds handling of '*'; - eliminates the need to invoke 'date' for each entry; - uses slightly stricter check for origin detection within AFFECTS. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
RFC: 'make makepatch' and alternatives
Greetings!
I had a dispute with Olli Hauer about the usage of the 'makepatch'
target for generating port patchfiles.
I am currently using patchfiles for my ports that are generated by the
version control systems and are grouped by-commit. But there is an old,
good makepatch target that creates per-file diffs based on all applied
patches.
Section 4.4 of Porters Handbook says that there should be no two patch
files that modify the single source file, so, in general, my approach is
a kind of herecy. As I understand, there are just two sound reasons to
use the makepatch:
- one has no need to worry about the patch order: hunks are
grouped by-file, so any patch order will go;
- one can simply invoke 'make makepatch' to produce all patchfiles
automatically after the virgin sources were patched and .orig
files were left in place.
There is the third reason from the Porters Handbook: To make fixes and
upgrades easier, you should avoid having more than one patch fix the
same file, but frankly, I don't quite understand its meaning, apart
from the reasoning in the point 1 raised above.
From the other hand, by-commit patchfiles have the good property that
they carry the vital metadata: the grouping of hunks and, in some
cases, the comments about the patch itself (Git patches are good example
of this). And, if the author of the patch makes a reasonable effort
to make single commits to be grouped by-topic (rather than squelching
multiple unrelated or loosely related modifications into a single
commit), such metadata is rather useful both for maintainer and persons
who will add/modify port patches. Here are my reasons:
- suppose, one is upgrading the port from version X to version Y
and he finds that the patch A doesn't apply; the most common reasons
for this are
a) upstream sources were changed in some non-trivial way, but
there is still a need to patch, but the original one should
be modified for the new version;
b) the patch was taken upstream (perhaps, with some modifications,
but there is no need to modify the original patch, since the
original problem was fixed, but, may be, in the different way);
In either case, by-commit grouping will permit the porter to immediately
identify the hunks that should be either thrown out or modified;
with the by-file approach, one will need to identify all hunks in
different patchfiles that are related to the said modification;
- suppose, the non-maintainer has to create new patch for the port
because he want to fix some problem, upgrade the port or for some
other reason; he looks into the files/ directory and sees a bunch
of patch files with a bunch of hunks inside each, but he can't
easily track their interrelations -- a time should be spent to
figure out what hunks serve what purpose. By-commit patchfiles
have no such problem -- the metadata is already here.
Olli said to me that by-file grouping makes it easier to understand
what files were patched. That's true, but it is not so hard to
get this information from the by-commit patchfiles: it is a trivial
scripting that can be added to the bsd.port.mk (I can provide it
if it is really needed).
And, transforming the by-commit patches into by-file is a loss of
data in a strict mathematical sense: transformation by-commit -
by-file has no single inverse function, there are multiple variants
how by-file hunks can be regrouped into by-commit ones.
There is a slight problem with the by-commit patches: their order
can matter, but if _PATCHFILES inside bsd.port.mk will be sorted
alphabetically, then a simple naming like 'patch-[abcd]-whatever'
will be sufficient: suppose there are already patches
{{{
patch-0001-fix-one
patch-0002-fix-two
patch-0003-fix-three
}}}
and we want to insert another patch between 2nd and 3rd. The name
like patch-0002a-fix-two-prime will do the trick.
I am obviously not trying to force anyone to move to the by-commit
patchfiles, but I just want to know
- if I am missing something with the generally-adopted scheme with
make makepatch
- if it seems reasonable to other people to employ the by-commit patch
grouping.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: (no subject)
Tue, Dec 29, 2009 at 10:40:02AM +0300, Yuri Pankov wrote:
On Tue, Dec 29, 2009 at 01:28:46AM -0600, Scot Hetzel wrote:
dv8t01# make do-check
File /usr/local/etc/rc.d/motd exists
File /usr/local/etc/rc.d/hald doesnt exist
This Makefile fails due to LOCALBASE is not defined at the time that
the exists check is run.
How come that ${DATADIR} (and ${LOCALBASE}) are correctly expanded in
${ECHO_MSG} then?
.if and .for are unrolled and evaluated while parsing the makefile
and make transforms it to bare @${ECHO_MSG} ... lines with the
content that depends on the if-else-endif evaluation. LOCALBASE
isn't defined at that time
And targets are executed after the whole Makefile was read, so
LOCALBASE is here. Actually, the found /usr/local/etc/rc.d/motd
is really an /etc/rc.d/motd.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: (no subject)
Tue, Dec 29, 2009 at 02:50:25PM +0300, Yuri Pankov wrote:
Thanks for explanation.
Welcome ;))
I just wonder how PREFIX is different from
LOCALBASE (i.e., devel/gettext uses .if exists(${PREFIX}/.) without
including bsd.port.pre.mk).
It is no different. Using PREFIX without bsd.port.pre.mk is
an error. CC'ing gettext maintainers.
Gentlemen, you have an error of using PREFIX inside .if clause
without prior inclusion of bsd.port.pre.mk before it. With the
current Makefile, make tries to search /bin/kaffe. The below
transript shows the problem:
-
$ pwd
/usr/ports/devel/gettext
$ LANG=C ls -l /usr/local/bin/kaffe /bin/kaffe; make pre-extract
ls: /usr/local/bin/kaffe: No such file or directory
-rw-r--r-- 1 root wheel 0 Dec 29 17:46 /bin/kaffe
Gettext won't build with Kaffe's jar utility. Doing:
/bin/mv /usr/local/bin/jar /usr/local/bin/jar.backup
mv: rename /usr/local/bin/jar to /usr/local/bin/jar.backup: Permission denied
*** Error code 1 (ignored)
Be sure to mv /usr/local/bin/jar.backup /usr/local/bin/jar
if you abandon your attempt to build gettext.
^C
-
The following patch should fix the things:
--- Makefile.orig 2009-12-29 17:49:56.0 +0300
+++ Makefile2009-12-29 17:51:06.0 +0300
@@ -53,6 +53,8 @@
EXTRA_PATCHES+=${FILESDIR}/extra-patch-nodocs
.endif
+.include bsd.port.pre.mk
+
pre-extract:
.if exists(${PREFIX}/bin/kaffe)
@${ECHO_MSG} Gettext won't build with Kaffe's jar utility. Doing:
@@ -88,4 +90,4 @@
@${MKDIR} ${LOCALBASE}/share/locale
@cd ${WRKSRC}/gettext-tools/doc make install-info-am
-.include bsd.port.mk
+.include bsd.port.post.mk
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: Need help disabling (re-)configure step
Ronald, good day.
Tue, Dec 29, 2009 at 07:33:32PM -0800, Ronald F. Guilmette wrote:
So anyway, I've found that if I just take the ./configure command as
it appears in the config.log file, and edit it to remove this option:
--with-dbus-system-socket=unix:path=/var/run/dbus/system_bus_socket
replacing that instead with:
--disable-dbus --disable-gdbm
then I can at least get the bleepin' thing to configure properly. (It
appers that it subsequently dies during the actual build, but let me
worry about that part.)
So anyway, the good news is that I know how to at least get this thing
to configure without dying during the execution of ./configure.
It is good.
The bad news is that once I do that, if I cd back up two levels (../..)
and then just try to do make, for some reason the ports building system
insists on re-running the configure step again, thus wiping out my
adjustments which allowed avahi-app to at least finish the pre-build
configure step.
It is perfectly explainable -- FreeBSD ports makesystem keeps track
of all stages that the port was get through and will never rerun them.
On the other hand, it will run the stages that weren't already executed.
You run ./configure manually, but the makesystem isn't aware of it, so
it executes ./configure once more. Watch for the CONFIGURE_COOKIE
and ${${target:U}_COOKIE} in the /usr/ports/Mk/bsd.port.mk.
So, could somebody please tell me how to suppress this behavior? Why is
it the case that when I am cd'd into /usr/ports/net/avahi-app and when I
then type make, the bleedin' thing forces a re-run of the ./configure
step, even though I have already done that manually.
Basically, because you're not intended to mess with the manual invocation
of configure script. The proper thing to do is to edit avahi-app
port's Makefile and replace
-
--with-dbus-system-socket=unix:path=/var/run/dbus/system_bus_socket \
-
with
-
--disable-dbus --disable-gdbm \
-
or whatever suits you.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] Tools/ script for automatically making a tar out of svn sources
Thu, Dec 10, 2009 at 02:08:43PM -0800, Xin LI wrote:
On Thu, Dec 10, 2009 at 1:58 PM, Eitan Adler eitanadlerl...@gmail.com wrote:
The attachment never made it through (not sure why: in my MUA it looks
like it was sent) and after some more looking I decided I was probably
a bit to fast. I'll send a repost when I improve it
Try sending it inline. Certain attachment mime types are being
filtered by the list program.
Or, better, place it to HTTP/FTP and give the link.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: Depending on a Python egg
Wed, Dec 09, 2009 at 12:54:43PM +, Kevin Golding wrote:
RUN_DEPENDS=${PYTHON_SITELIBDIR}/${PYLXML_EGG}:${PORTSDIR}/devel/py-
lxml
What about
-
RUN_DEPENDS=${PYTHON_PKGNAMEPREFIX}lxml=0:${PORTSDIR}/devel/py-lxml
-
that should be specified after the inclusion of bsd.port.pre.mk?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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/libcdio provides no cdio_paranoia.0 for ports/devel/gvfs
Sun, Nov 15, 2009 at 10:51:55PM +0100, Julian H. Stacey wrote:
A hint would be welcome please with sysutils/libcdio, Paranoia stuff seems
broken, but I'm not clear what's intended, hence mail rather than a send-pr.
uname -a
FreeBSD laps.js.berklix.net 7.2-RELEASE FreeBSD 7.2-RELEASE #2: \
Wed Sep 9 11:33:57 CEST 2009 \
j...@laps.no.net:/usr/src/sys/i386/compile/LAPS.small i386
cd /usr/ports/net-mgmt/etherape ; make
=== gvfs-1.2.1 depends on shared library: cdio_paranoia.0 - not found
===Verifying install for cdio_paranoia.0 in \
/usr/ports/sysutils/libcdio
=== Returning to build of gvfs-1.2.1
Error: shared library cdio_paranoia.0 does not exist
Do you have /usr/ports/sysutils/libcdio/work? If yes, remove it
and try the build once again.
Do you really have nothing between Verifying install for cdio_paranoia.0
and Returning to build of gvfs? Not even a try to build libcdio port?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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 creating a port for saga gis
Sun, Nov 15, 2009 at 02:35:19AM -0600, Scott Bennett wrote:
Why are you putting saga into math? It should be in databases, like
grass and postgis are,
Let's see. /usr/ports/databases/postgis/pkg-descr:
-
PostGIS adds support for geographic objects to the PostgreSQL
object-relational database. In effect, PostGIS spatially enables the
PostgreSQL server, allowing it to be used as a backend spatial database
for geographic information systems (GIS), much like ESRI's SDE or
Oracle's Spatial extension. PostGIS follows the OpenGIS Simple
Features Specification for SQL and will be submitted for conformance
testing at version 1.0.
PostGIS has been developed by Refractions Research Inc as a research
project in open source spatial database technology. PostGIS is released
under the GNU General Public License. We intend to continue development
as time and resources permit. Our list of future projects includes
enhanced technology for data loading and dumping, user interface tools
for direct data access and manipulation, and support for advanced
topologies at the server side, such as coverages, networks, and
surfaces.
-
No a surpsise that it is in the databases, heh ;))
/usr/ports/databases/grass/pkg-descr:
-
Geographic Resources Analysis Support System
(GRASS GIS)
An open source Geographical Information System (GIS) with raster,
topological vector, image processing, and graphics production functionality
that operates on various platforms through a graphical user interface and
shell in X-Windows. It is released under GNU General Public License (GPL).
WWW: http://grass.itc.it/
-
Grass seem to use database-like store for the objects and subsequently
manipulates this data by applying various processing methods, so may be
this was the reason to put it under databases.
But read
http://sourceforge.net/apps/trac/saga-gis/wiki/The%20Philosophy%20of%20SAGA
it clearly states that The heart of SAGA is it's C++ and thus object
oriented Application Programming Interface (API), providing data object
definitions and computational methods for raster, vector and tabular
^
data. As a normal user, you will not get into touch with the API. But as
an interested scientist or coder you will soon discover it's great
flexibility.. So I would say that math is justified here.
or conceivably in science.
Science -- yes, looks good too.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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 creating a port for saga gis
Sat, Nov 14, 2009 at 10:41:58AM +0100, Rainer Hurling wrote:
The original configure script of SAGA GIS expects 'wx-config', but in
newer FreeBSD systems there only is e.g. wxgtk2-2.8-config.
The porters handbook shows how to configure the ports Makefile to let
the port know what wxWidget version to use. I patched the original
configure script but obviously that's not enough. The attached files
are saved under math/saga and show what I have tried.
Seems like spawning REINPLACE_CMD over the whole horde of Makefile.in
files will do the trick:
-
post-patch:
@for f in `${FIND} '${WRKSRC}' -name Makefile.in` \
${WRKSRC}/configure; do \
${REINPLACE_CMD} -e's|wx-config |${WX_CONFIG} |g' $$f; \
done
-
It would be nice if someone with more experience could give me a hint
how to do it right.
I am not sure for 100% that the above is the Only Right Way (tm), but
the Porter's Handbook suggests that in such cases (when wx-config is
hardcoded), the best thing is to patch the sources and that's what I did.
BTW, there is absolutely no need to specify WX_CONFIG in your Makefile,
bsd.wx.mk will take care of it. WX_CONF_ARGS seems redundant too:
SAGA's configure understands no --with-wx-config option, so it is just
a no-op.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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 creating a port for saga gis
Sat, Nov 14, 2009 at 02:58:02PM +0100, Rainer Hurling wrote:
BTW, there is absolutely no need to specify WX_CONFIG in your Makefile,
bsd.wx.mk will take care of it. WX_CONF_ARGS seems redundant too:
SAGA's configure understands no --with-wx-config option, so it is just
a no-op.
Both are deleted now from my Makefile and everything build and install
just fine.
Cool.
So far, I only tested my new port math/saga under very recent
9.0-CURRENT, both i386 and amd64. Is there any need for me to let it
test on other platforms and/or system versions before requesting a
commit?
If you have access to other variants of systems, it will be good, but if
you can't -- just submit it. If there will be build troubles when the
port will be included to the ports collection, then you'll be warned
about this as the maintainer.
'portlint -A' gives me the following errors:
FATAL: Makefile: MASTER_SITES appears out-of-order.
FATAL: Makefile: order must be
PORTNAME/PORTVERSION/DISTVERSIONPREFIX/DISTVERSION/DISTVERSIONSUFFIX/PORTREVISION/PORTEPOCH/CATEGORIES/MASTER_SITES/MASTER_SITE_SUBDIR/PKGNAMEPREFIX/PKGNAMESUFFIX/DISTNAME/EXTRACT_SUFX/DISTFILES/DIST_SUBDIR/EXTRACT_ONLY.
WARN: Makefile: BUILD_DEPENDS has to appear earlier.
2 fatal errors and 1 warning found.
I think there is no chance to avoid the fatal errors with the used URL?
Why? Just move DISTNAME below the MASTER_SITES and MASTER_SITE_SUBDIR
and that's it. What worried you about the URL?
Irritating is the warning about the position of BUILD_DEPENDS. I am
not sure if this is the right way to optionally install a library. What
do you think?
This is the right way. The thing is that the only BUILD_DEPENDS is
OPTION-dependent, so you can't use WITH/WITHOUT_HARU prior to the
inclusion of bsd.port.options.mk and this will enable portlint to emit
warnings. So, if I am not missing some important point, you should live
with it.
But I had glanced over Haru usage inside the current sources and it
turns out that Haru is disabled: preprocessor symbol _SAGA_DONOTUSE_HARU
is defined throughout the whole load of the Makefiles. This symbol is
actively used only inside src/saga_core/saga_api/doc_pdf.cpp and, in
fact, PDF generation is disabled if _SAGA_DONOTUSE_HARU is here.
I see no knobs to enable it without manual patching, so, if you really
don't need PDFs -- you can drop haru dependency completely. If you
still want to have it -- patch Makefile.in files once again (basing on
the value of WITH_HARU), add the needed link knobs to the LDFLAGS and,
possibly, some stuff to the CFLAGS.
Attaching slightly cleaned-up version of the Makefile from which
OPTIONS were removed.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
# Ports collection makefile for: saga
# Date created:13 November 2009
# Whom:Rainer Hurling rhur...@gwdg.de
#
# $FreeBSD$
#
PORTNAME= saga
PORTVERSION=2.0.4
CATEGORIES= math
MASTER_SITES= SF
MASTER_SITE_SUBDIR=
saga-gis/SAGA%20-%20${PORTVERSION:C/\.[[:digit:]]*$//}/SAGA%20${PORTVERSION}
DISTNAME= ${PORTNAME}_${PORTVERSION}_src_linux
MAINTAINER= rhur...@gwdg.de
COMMENT=System for Automated Geoscientific Analyses
LIB_DEPENDS=proj.5:${PORTSDIR}/graphics/proj \
gdal.14:${PORTSDIR}/graphics/gdal \
jasper.4:${PORTSDIR}/graphics/jasper \
tiff.4:${PORTSDIR}/graphics/tiff
WRKSRC= ${WRKDIR}/saga-${PORTVERSION:C/\.[[:digit:]]*$//}
USE_LDCONFIG= yes
GNU_CONFIGURE= yes
USE_WX= 2.8
CFLAGS+=-I${LOCALBASE}/include
post-patch:
@for f in `${FIND} '${WRKSRC}' -name Makefile.in` \
${WRKSRC}/configure; do \
${REINPLACE_CMD} -e's|wx-config |${WX_CONFIG} |g' $$f; \
done
@${REINPLACE_CMD} -e 's,malloc.h,stdlib.h,' \
${WRKSRC}/src/saga_core/saga_api/api_memory.cpp \
${WRKSRC}/src/modules_projection/pj_georeference/pj_georeference/lmdif0.c
.include bsd.port.mk
___
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 creating a port for saga gis
Sat, Nov 14, 2009 at 05:09:53PM +0100, Rainer Hurling wrote:
Thank you again, Eygene.
You're welcome ;))
I will now prepare for submitting a PR with this new port.
I'll try to do a Tinderbox build of your port to see if the packaging
and dependency list is complete. I think that the committer who will
take care of this will do it by himself, but since I had already spent
some time on this, I'll try to do this validation.
So, please, Cc me when you'll be making your send-pr submission.
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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 creating a port for saga gis
Rainer, good day.
Fri, Nov 13, 2009 at 10:48:15AM +0100, Rainer Hurling wrote:
Unfortunately I have problems to let the port fetch the distfile. I
tried many ways described in the porters handbook without success.
The distfile is located at
http://sourceforge.net/projects/saga-gis/files/SAGA%20-%202.0/SAGA%202.0.4/saga_2.0.4_src_linux.tar.gz/download
No, this is the location of the fancy page with ads that will allow one
to select mirrors and other stuff. It will select the mirror
automatically, so you're seeing it as the download URL, but it's not so,
it is just a redirector.
I tried for example with combinations of
PORTNAME= saga
PORTVERSION= 2.0.4
DISTNAME= saga_2.0.4_src_linux
MASTER_SITES=
http://sourceforge.net/projects/saga-gis/files/SAGA%20-%202.0/SAGA%202.0.4/
but the main problem seems to be the '/download' after the filename.
Fetching the file by hand works but I have no clue how to describe this
path in the ports Makefile.
The following mini-Makefile does the trick for me:
-
PORTNAME= saga
PORTVERSION=2.0.4
DISTNAME= saga_2.0.4_src_linux
MASTER_SITES=
SF/saga-gis/SAGA%20-%20${PORTVERSION:C/\.[[:digit:]]*$//}/SAGA%20${PORTVERSION}/
CATEGORIES= devel
.include bsd.port.mk
-
Please, note that the SF word is expanded to the full list of the
SourceForge mirrors known to the FreeBSD ports subsystem, so you need
not to explicitely list any URLs -- just use SF for SourceForce
mirrors.
And the snippet I showed above is yet better rewritten as
-
PORTNAME= saga
PORTVERSION=2.0.4
DISTNAME= saga_2.0.4_src_linux
MASTER_SITES= SF
MASTER_SITE_SUBDIR=
saga-gis/SAGA%20-%20${PORTVERSION:C/\.[[:digit:]]*$//}/SAGA%20${PORTVERSION}
CATEGORIES= devel
.include bsd.port.mk
-
It does the same, but has better semantics.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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 creating a port for saga gis
Fri, Nov 13, 2009 at 11:54:08AM +0100, Rainer Hurling wrote:
thank you for your answers. Now I am able to fetch directly :-)
You're welcome ;))
CATEGORIES= devel
My plans are to use math for SAGA GIS because there is no 'gis'
category. And 'graphics' or 'database' do not suit well enough I
think.
I used devel just to stuff some CATEGORIES into the test Makefile --
this variable is mandatory and bsd.port.mk will error us out if this
won't be specified. You can use any category that suits you. By
the way, you can specify multiple categories and, probably, astro
is worth considering too. But the primary category is math, so
you're right and the port most probably should go into math/saga.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: Getting MASTER_SITES for sourceforge ports more easily
Sat, Nov 14, 2009 at 07:04:17AM +0300, Dmitry Marakasov wrote:
Recently there have been at least two questions about a correct way
of defining MASTER_SITES for SourceForge-hosted projects. Here's a
way to make it a bit easier: it's a GreaseMonkey
(https://addons.mozilla.org/en-US/firefox/addon/748) script that
converts links on sourceforge pages to direct links.
http://userscripts.org/scripts/show/50136
With this, links like .../download will be changed to direct ones, which
can be copypasted to SF/...
The attached shell script should produce the MASTER_SITE_SUBDIR for the
SF-hosted ports for each URL given in the command-line.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: Getting MASTER_SITES for sourceforge ports more easily
Sat, Nov 14, 2009 at 09:16:47AM +0300, Eygene Ryabinkin wrote:
The attached shell script should produce the MASTER_SITE_SUBDIR for the
SF-hosted ports for each URL given in the command-line.
Inlining the script -- it was dropped by the Mailman:
-
#!/bin/sh
while [ -n $1 ]; do
echo $1 | sed
-Ee's%^htt(p|ps)://(sourceforge|sf)\.net/projects/(.*)/[^/]*/download$%MASTER_SITE_SUBDIR=
\3%'
shift
done
-
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: Issues with devel/boost-* on Sparc64
Alexander, good day.
Wed, Nov 11, 2009 at 11:04:59PM +0300, Alexander Churanov wrote:
It seems that I have found a workaround. It is to store the address of
the variable in a register and then issue the CAS instruction, which
only accepts register for an address. I am currently testing it.
I hadn't seen the code you're testing, but it seems to me that the
attached patch should automatically take care of making the address to
be in some register (if it isn't already in the register). It compiles
well, and even works as a stand-alone function, but I hadn't yet tested
if boost built with such a atomic primitive really works fine. Have
some $JOB to do prior to the testing.
If you're storing the address in the register manually -- there is no
need for it: you can use assembly constraints; this also makes less
headache, because compiler decides what register should be allocated by
its own and typically it is doing this job well. Anyway, I hadn't seen
your patch, so may be you already doing this.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
--- boost/smart_ptr/detail/sp_counted_base_gcc_sparc.hpp.orig 2009-03-02 11:22:16.0 -0500
+++ boost/smart_ptr/detail/sp_counted_base_gcc_sparc.hpp 2009-11-12 09:51:25.0 -0500
@@ -30,10 +30,10 @@
inline int32_t compare_and_swap( int32_t * dest_, int32_t compare_, int32_t swap_ )
{
-__asm__ __volatile__( cas %0, %2, %1
-: +m (*dest_), +r (swap_)
-: r (compare_)
-: memory );
+__asm__ __volatile__( casa [%3] 0x80, %2, %1
+ : =m (*dest_), =r (swap_)
+ : r (compare_), r (dest_), 1 (swap_), m (*dest_)
+ : memory );
return swap_;
}
___
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: nagios 3.1.x request
Wed, Nov 11, 2009 at 07:55:09PM +0100, Achim Hut wrote:
Hi Portslist, dear Nagios-port Maintainer
How about cleaning the Nagios Core Ports a bit?
1) The actual stable Nagios Realease is 3.2.0 dated 2009/08/12
What do we have in ports:
a) nagios-2.12_5
b) nagios-3.0.6_3
c) nagios-devel-3.1.2_1
maybe its an good idea to delete port a) and
build one nagios 3.2 port out of b) and c)
I see that you hadn't used PR search, aren't you? If you would, you'll
find that an upgrade to 3.2.0 is hanging since September 28th:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/139210
Martin, were there any problems with the port or you were just
overwhelmed with other business?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: Issues with devel/boost-* on Sparc64
Sat, Nov 07, 2009 at 09:11:56PM -0500, Boris Kochergin wrote:
As I know, currently devel/boost-libs port fails to build on sparc64.
I had a discussion of this in September. The root cause is unknown for
me. To investigate into this further I need either access to a sparc64
box or a person who has access and whom I may instruct with the
actions to perform.
From the preliminary investigations I done on the Boris's machine,
it turns out that as(1) chokes on the cas instruction that looks
like cas [%l0+12], %g2, %g1. The instruction itself looks sane,
so I'll try to understand if as(1) has some bugs inside it or something
isn't good with the instruction itself.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: Issues with devel/boost-* on Sparc64
Mon, Nov 09, 2009 at 04:12:01PM +0300, Eygene Ryabinkin wrote:
Sat, Nov 07, 2009 at 09:11:56PM -0500, Boris Kochergin wrote:
As I know, currently devel/boost-libs port fails to build on sparc64.
I had a discussion of this in September. The root cause is unknown for
me. To investigate into this further I need either access to a sparc64
box or a person who has access and whom I may instruct with the
actions to perform.
From the preliminary investigations I done on the Boris's machine,
it turns out that as(1) chokes on the cas instruction that looks
like cas [%l0+12], %g2, %g1. The instruction itself looks sane,
so I'll try to understand if as(1) has some bugs inside it or something
isn't good with the instruction itself.
Hmm, looks like only memory address taken straight from the register is
allowed for the Sparc. So, [%l0] will be good, but [%l0+12] -- won't.
So it seems to me that g++ is generating improper assembly code. Will
look into it a bit further.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: Issues with devel/boost-* on Sparc64
Boris, good day.
Sat, Nov 07, 2009 at 09:11:56PM -0500, Boris Kochergin wrote:
Alexander Churanov wrote:
HI folks!
As I know, currently devel/boost-libs port fails to build on sparc64.
I had a discussion of this in September. The root cause is unknown for
me. To investigate into this further I need either access to a sparc64
box or a person who has access and whom I may instruct with the
actions to perform.
Are there any plans to fix ports for sparc64 before the release?
Sincerely,
Alexander Churanov,
maintainer of devel/boost-*
___
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
Ahoy. I can give you shell access to a reasonably-speedy sparc64 machine
(4 x 300 MHz) running 8.0-BETA.
I am willing to try. How to proceed? If you'll need my SSH key, it is
in the attachment.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
ssh-rsa
B3NzaC1yc2EBIwAAAgEAxC5Iw8CyS+dpx1VEVV59NCt/UTnO+VcYFnbs526OPjuLiAOSkBItSqlWE96Bpwi+vgUMpDYNW8nlaahVzotoQyjge/vL/o8hZ1fr+WdLGr4HTKWhiESe7qfsnNCmY56irx1a35DwMDiPgM948jkkz0HoK2flCAj5cU29mez2a23th5fJZXo4NCyb0jzewp0vqDRX6MW1Qmg/rBfUdFbu2v9VUmemK9Uxs6LBAYRkkfaugHw+LIj7WKBvaSfyBDu55ID6ve5L78Ai6YAKPF+WiILkFw5z/TCzuFLpL0JN7Im1YxJOmGHMfGrFrY2h7gSQAdtrQvDBG/A4wToMLqneqvOe1VYSPwO8+jEH9CwkybRy77USrxlZBbXHOJ/hPNa+HSEoTuJAwolSpItDZCAnoVr8v51yzFr1L238DLFId4y05tiU6ioJWGjGX+75iEcL2BHaNBpk6a1n+dx13c87HAKX2VCLFrhi1xD0IviD3WPGM+ELOC46wTvabXFhtXxzOhakdbcNZhQ830KmtRu0I2sO4yh7oTT85tcbKhQP6J2SNE0J7wIlo0VX2WdsPgPDeo4scnJWLFeQysC4CjbGj8eiiJt5yP7oOXLM075sRgt8xZZdQCTyniQf3gSWclPzeia0tqAMvnkc85zWfTlJWvGszzjAfmcPHIVRkURxkYE=
r...@void.codelabs.ru
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Port Request: Bongo
Sat, Nov 07, 2009 at 04:27:44AM +0300, Eygene Ryabinkin wrote:
I hadn't tested it in the Tinderbox for the clean build, but I'll
try to do it next week. If you're interested -- I'll post the
results and modifications to the port.
Some iterations over the Tinderbox helped to bring the port to the
much better shape and now it gained some more dependencies, plist
was fixed and some patches were updated.
Sat, Nov 07, 2009 at 11:31:41AM +0100, Gary Jennejohn wrote:
Attachment stripped. How about a URL?
http://codelabs.ru/fbsd/ports/bongo-0.6.1.shar
It contains the latest version with all fixes embedded. Still, I
hadn't tested if it really works :((
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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
Renaming port when it forks to two different branches
Good day.
I am maintaining net-mgmt/pnp and it was recently brought to my
attention that the current port development line (0.4.x) will cease in
some time and now we have 0.6.x that is better, will be supported and
developed further. But it requires PHP = 5.2. I am planning to
upgrade the net-mgmt/pnp to 0.6.x and make request to repocopy the
current (0.4.x-based) port to net-mgmt/pnp-legacy.
Here comes a question: does anyone sees any drawbacks from such
a plan and may be there are better ways to do it?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: [headsup] call for assistance with ports broken on -current
Mark, good day.
Sun, Mar 01, 2009 at 06:45:39PM -0600, Mark Linimon wrote:
With 8.0 coming up, it's time to take a look at the ports that have
been broken by some recent changes to freebsd-current. I have put
a list of these ports, categorized by which change, on the wiki at
http://wiki.freebsd.org/PortsBrokenOnCurrent.
Could you or someone else add ports/129881 as the ARPv2 changes
resolution fix for the ospfd? I am not eligible to edit the wiki
pages, so can't do it for myself.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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: [headsup] call for assistance with ports broken on -current
Florent, good day.
Mon, Mar 02, 2009 at 11:03:38AM +, Florent Thoumie wrote:
On Mon, Mar 2, 2009 at 9:34 AM, Eygene Ryabinkin rea-f...@codelabs.ru wrote:
Could you or someone else add ports/129881 as the ARPv2 changes
resolution fix for the ospfd? I am not eligible to edit the wiki
pages, so can't do it for myself.
Isn't this PR ready for commit already? It seems that the only thing
blocking it is maintainer approval, but we're well beyond that now.
Precisely. If someone will take the powers and commit the patches from
PR, I will be very grateful.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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/128999: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829
Number: 128999 Category: ports Synopsis: [vuxml] [patch] update audio/streamripper to 1.64.0, fix CVE-2008-4829 Confidential: no Severity: serious Priority: high Responsible:freebsd-ports-bugs State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Wed Nov 19 21:30:14 UTC 2008 Closed-Date: Last-Modified: Originator: Eygene Ryabinkin Release:FreeBSD 7.1-PRERELEASE i386 Organization: Code Labs Environment: System: FreeBSD 7.1-PRERELEASE i386 Description: Streamripper 1.64.0 is out and this release fixes security vulnerability discovered by Secunia. How-To-Repeat: http://streamripper.cvs.sourceforge.net/viewvc/streamripper/sripper_1x/CHANGES?revision=1.196 http://secunia.com/secunia_research/2008-50/ Fix: The following patch updates the port to 1.64.0. It works for me: MP3 streams are ripped perfectly. --- 1.63.5-to-1.64.0-fix-cve-2008-4829.diff begins here --- diff -urN ./Makefile ../streamripper/Makefile --- ./Makefile 2008-11-19 23:50:33.0 +0300 +++ ../streamripper/Makefile2008-11-19 23:57:00.0 +0300 @@ -6,7 +6,7 @@ # PORTNAME= streamripper -PORTVERSION= 1.63.5 +PORTVERSION= 1.64.0 CATEGORIES=audio MASTER_SITES= SF \ http://gd.tuwien.ac.at/hci/cdk/:cdk diff -urN ./distinfo ../streamripper/distinfo --- ./distinfo 2008-11-19 23:50:33.0 +0300 +++ ../streamripper/distinfo2008-11-19 23:57:19.0 +0300 @@ -1,6 +1,6 @@ -MD5 (streamripper-1.63.5.tar.gz) = 73a63383dca00615c3328cf51bf2fa56 -SHA256 (streamripper-1.63.5.tar.gz) = 877aed28880b904383c4e761c0ecb1e046dbe45126e648110c0292991d1e5b93 -SIZE (streamripper-1.63.5.tar.gz) = 1302177 +MD5 (streamripper-1.64.0.tar.gz) = f8754813ddc2bc96c4c3440e25aca8b6 +SHA256 (streamripper-1.64.0.tar.gz) = a53f50d26de3610e59a07eaf81cc9da348aaf7b35bc4a302f2e5f6defb1297ae +SIZE (streamripper-1.64.0.tar.gz) = 839535 MD5 (cdk-5.0-20060507.tgz) = 0ec2460a4484d5f5595d8faca61bc9c5 SHA256 (cdk-5.0-20060507.tgz) = e823bfcce52916727cb23d6d549a64347c45c364b3c628d6a352c407fce8f4b4 SIZE (cdk-5.0-20060507.tgz) = 396514 --- 1.63.5-to-1.64.0-fix-cve-2008-4829.diff ends here --- The following VuXML entry should be evaluated and added: --- vuln.xml begins here --- vuln vid=unknown topicstreamripper -- user-assisted arbitrary code execution/topic affects package namestreamripper/name rangelt1.64.0/lt/range /package /affects description body xmlns=http://www.w3.org/1999/xhtml; pSecunia Research has discovered some vulnerabilities in Streamripper, which can be exploited by malicious people to compromise a user's system:/p blockquote cite=http://secunia.com/secunia_research/2008-50/; ol liA boundary error exists within http_parse_sc_header() in lib/http.c when parsing an overly long HTTP header starting with ldquo;Zwitterion vrdquo;./li liA boundary error exists within http_get_pls() in lib/http.c when parsing a specially crafted pls playlist containing an overly long entry./li liA boundary error exists within http_get_m3u() in lib/http.c when parsing a specially crafted m3u playlist containing an overly long ldquo;Filerdquo; entry./li /ol pSuccessful exploitation allows execution of arbitrary code, but requires that a user is tricked into connecting to a malicious server./p /blockquote /body /description references cvenameCVE-2008-4829/cvename urlhttp://secunia.com/secunia_research/2008-50//url urlhttp://streamripper.cvs.sourceforge.net/viewvc/streamripper/sripper_1x/CHANGES?revision=1.196/url /references dates discovery2008-11-19/discovery /dates /vuln --- vuln.xml ends here --- Release-Note: Audit-Trail: Unformatted: ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/128754: [port infrastructure] implement master sites randomization
Tue, Nov 11, 2008 at 07:19:03PM +0300, Eygene Ryabinkin wrote:
On Tue, Nov 11, 2008 at 03:23:50AM +, RW wrote:
On Mon, 10 Nov 2008 18:56:16 +0300 (MSK)
I think it would be sensible to seed srand from a hash of something
reproducible to make better use of caches - maybe DISTNAME+DISTVERSION.
For the feeding the hashes: RW, do you mean HTTP caches? In principle,
this is a neat idea: it will achieve load-balancing between the sites.
But as it will use the same master sites order for the given port, this
will be failing when the first download site is almost down: the
download will take very long. But probably stable order of the sites
can be made settable via the variable, e.g.
RANDOMIZE_MASTER_SITE_REPRODUCIBLY. Will it be fine? Please, note that
this can be achievable only for the awk script: random(6) can not be
currently directed to do this.
OK, I reworked the patch to add RANDOMIZE_MASTER_SITE_REPRODUCIBLY:
it guarantees the same order of master sites for the given combination
of the port name and version.
Please, give it a shot and comment.
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 40644084ccdb42bd34bf85cf43088c3ecb3e205f Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin [EMAIL PROTECTED]
Date: Mon, 10 Nov 2008 18:38:01 +0300
Subject: [PATCH] Add awk randomization script
Currently port download sites can be randomized only if the system has
/usr/games/random installed. I introduce the script that acts as the
replacement for /usr/games/random and needs no parts that are not exists
in the base system (only AWK is needed ;))
I had also added new directive, RANDOMIZE_MASTER_SITE_REPRODUCIBLY. It
applies randomization, but guarantees that the site order for the given
portname and portversion will be the same. Might be useful when one
uses HTTP caching and have many FreeBSD servers behind the cache.
Signed-off-by: Eygene Ryabinkin [EMAIL PROTECTED]
---
Mk/bsd.port.mk | 15 +--
Mk/rnd.awk | 26 ++
2 files changed, 39 insertions(+), 2 deletions(-)
create mode 100644 Mk/rnd.awk
diff --git a/Mk/bsd.port.mk b/Mk/bsd.port.mk
index 85ec297..dcc2d31 100644
--- a/Mk/bsd.port.mk
+++ b/Mk/bsd.port.mk
@@ -2169,11 +2169,22 @@ FETCH_REGET?= 0
FETCH_CMD?= ${FETCH_BINARY} ${FETCH_ARGS}
.if defined(RANDOMIZE_MASTER_SITES)
-.if exists(/usr/games/random)
+.if defined(RANDOMIZE_MASTER_SITES_REPRODUCIBLY)
+RANDOM_CMD?= ${AWK}
+RANDOM_SEED!= ${ECHO} ${DISTNAME} | ${MD5}
+RANDOM_ARGS?= -v value='${RANDOM_SEED}' -f ${PORTSDIR}/Mk/rnd.awk
+.elif exists(/usr/games/random)
RANDOM_CMD?= /usr/games/random
RANDOM_ARGS?= -w -f -
-_RANDOMIZE_SITES= |${RANDOM_CMD} ${RANDOM_ARGS}
+.else
+RANDOM_CMD?= ${AWK}
+RANDOM_ARGS?= -v value='' -f ${PORTSDIR}/Mk/rnd.awk
.endif
+.if defined(RANDOMIZE_MASTER_SITES_REPRODUCIBLY)
+RANDOM_CMD?= ${AWK}
+RANDOM_ARGS?= -v value=`echo ${DISTNAME}-${DISTVERSION} | md5` -f ${PORTSDIR}/Mk/rnd.awk
+.endif
+_RANDOMIZE_SITES= |${RANDOM_CMD} ${RANDOM_ARGS}
.endif
TOUCH?= /usr/bin/touch
diff --git a/Mk/rnd.awk b/Mk/rnd.awk
new file mode 100644
index 000..ce9943f
--- /dev/null
+++ b/Mk/rnd.awk
@@ -0,0 +1,26 @@
+BEGIN {
+ count = 0;
+ if (length(value) != 0)
+ srand(value);
+ else
+ srand();
+}
+{
+ for (i = 1; i = NF; i++)
+ array[count++] = $i;
+}
+END {
+# Need to drop a couple of initial rand() values: they tend
+# to be around 0.8 - 0.9, so for fairly small array length
+# they will produce identical values at the beginning.
+ rand(); rand(); rand(); rand();
+
+ for (i = count - 1; i 0; i--) {
+ j = int(10*count*rand()) % i;
+ if (j == i) continue;
+ t = array[i]; array[i] = array[j]; array[j] = t;
+ }
+
+ for (i = 0; i count; i++)
+ print array[i];
+}
--
1.6.0.3
From ffcaf1247756f403dc1e7308b1c68f6d6fcea524 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin [EMAIL PROTECTED]
Date: Fri, 14 Nov 2008 23:33:39 +0300
Subject: [PATCH] ports(7): document new option RANDOMIZE_MASTER_SITES_REPRODUCIBLY
Applies master site randomization, but guarantees that for the given
combination of the port name and version, the order of the download
sites will be the same at the each invocation.
Signed-off-by: Eygene Ryabinkin [EMAIL PROTECTED]
---
share/man/man7/ports.7 |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/share/man/man7/ports.7 b/share/man/man7/ports.7
index 7f8fb07..08c109b 100644
--- a/share/man/man7/ports.7
+++ b/share/man/man7/ports.7
@@ -420,6 +420,12 @@ Try going to these sites for all files and patches, first.
Try going to these sites for all files and patches, last.
.It Va RANDOMIZE_MASTER_SITES
Try
Re: ports/128754: [port infrastructure] implement master sites randomization
Tue, Nov 11, 2008 at 04:35:54PM +0100, Alexey Shuvaev wrote:
On Tue, Nov 11, 2008 at 03:23:50AM +, RW wrote:
On Mon, 10 Nov 2008 18:56:16 +0300 (MSK)
I think it would be sensible to seed srand from a hash of something
reproducible to make better use of caches - maybe DISTNAME+DISTVERSION.
Maybe I don't understand something, but is RANDOMIZE_MASTER_SITES
(see bsd.port.mk for details) not enough? It affects though all
sites, not only SF.
It is enough, but it requires /usr/games/random to be present. Not all
servers have 'games' distribution installed, but I want them to
randomize master sites.
For the feeding the hashes: RW, do you mean HTTP caches? In principle,
this is a neat idea: it will achieve load-balancing between the sites.
But as it will use the same master sites order for the given port, this
will be failing when the first download site is almost down: the
download will take very long. But probably stable order of the sites
can be made settable via the variable, e.g.
RANDOMIZE_MASTER_SITE_REPRODUCIBLY. Will it be fine? Please, note that
this can be achievable only for the awk script: random(6) can not be
currently directed to do this.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgp7toHGdAGHq.pgp
Description: PGP signature
ports/128754: [port infrastructure] implement master sites randomization
Number: 128754
Category: ports
Synopsis: [port infrastructure] implement master sites randomization
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-ports-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Mon Nov 10 16:00:09 UTC 2008
Closed-Date:
Last-Modified:
Originator: Eygene Ryabinkin
Release:FreeBSD 7.1-PRERELEASE i386
Organization:
Code Labs
Environment:
System: FreeBSD 7.1-PRERELEASE i386
Description:
Today I was hit by the very bad connectivity with twaren.net and
nchc.dl.sourceforge.net (the first site in the SF mirrors list in the
FreeBSD ports .mk files) is hosted by Taiwan REN. So, I decided to
implement simple randomization that will enable to evenly distribute
the downloads between SF mirrors.
I had made it only for the SF mirrors, but it can be done for the other
well-known download locations as well.
How-To-Repeat:
Look at ${PORTSDIR}/Mk/bsd.sites.mk: it uses statical assignment to
the MASTER_SITE_SOURCEFORGE.
Fix:
The following patch works for me. It places simple script rnd.awk to
the ${PORTSDIR}/Mk -- I don't think that this is the most appropriate
place to put it, but I can't think of another place now -- the script is
too ports-specific to put it into, for example, /usr/bin/.
--- 0001-Implement-randomization-of-main-SourceForge-sites.patch begins here ---
From d48aa3982a5ca6192fad561462c3ba9da2b38cfa Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin [EMAIL PROTECTED]
Date: Mon, 10 Nov 2008 18:38:01 +0300
The reasoning behind this is simple: today I had experienced very bad
connectivity with twaren.net and it is the first mirror in the list.
So, for automated upgrades of ports that are using SourceForge mirrors,
the download was very time-consuming. Such round-robin randomization
of the download sites helps to improve the situation.
Signed-off-by: Eygene Ryabinkin [EMAIL PROTECTED]
---
Mk/bsd.commands.mk |1 +
Mk/bsd.sites.mk|9 ++---
Mk/rnd.awk | 14 ++
3 files changed, 21 insertions(+), 3 deletions(-)
create mode 100644 Mk/rnd.awk
diff --git a/Mk/bsd.commands.mk b/Mk/bsd.commands.mk
index aa8bde8..0b2a58b 100644
--- a/Mk/bsd.commands.mk
+++ b/Mk/bsd.commands.mk
@@ -69,6 +69,7 @@ PASTE?= /usr/bin/paste
PAX?= /bin/pax
PRINTF?= /usr/bin/printf
PW?= /usr/sbin/pw
+RANDLIST?= ${AWK} -f ${PORTSDIR}/Mk/rnd.awk
REALPATH?= /bin/realpath
RM?= /bin/rm
RMDIR?=/bin/rmdir
diff --git a/Mk/bsd.sites.mk b/Mk/bsd.sites.mk
index 41b3f93..bd9a2a6 100644
--- a/Mk/bsd.sites.mk
+++ b/Mk/bsd.sites.mk
@@ -1188,20 +1188,23 @@ MASTER_SITE_SAVANNAH+= \
.if !defined(IGNORE_MASTER_SITE_SOURCEFORGE)
.for mirror in nchc kent easynews ufpr umn mesh heanet
-MASTER_SITE_SOURCEFORGE+= \
+MASTER_SITES_SOURCEFORGE+= \
http://${mirror}.dl.sourceforge.net/sourceforge/%SUBDIR%/
.endfor
+MASTER_SITE_SOURCEFORGE != ${RANDLIST} ${MASTER_SITES_SOURCEFORGE}
.endif
# official sf.net mirrors that don't mirror all projects, check
# http://prdownloads.sourceforge.net/%SUBDIR%/
.if !defined(IGNORE_MASTER_SITE_SOURCEFORGE_EXTENDED)
.for mirror in easynews switch puzzle belnet osdn ovh keihanna
-MASTER_SITE_SOURCEFORGE_EXTENDED+= \
+MASTER_SITES_SOURCEFORGE_EXTENDED+= \
http://${mirror}.dl.sourceforge.net/sourceforge/%SUBDIR%/
.endfor
-MASTER_SITE_SOURCEFORGE_EXTENDED+= \
+MASTER_SITES_SOURCEFORGE_EXTENDED+= \
${MASTER_SITE_SOURCEFORGE}
+MASTER_SITE_SOURCEFORGE_EXTENDED != \
+ ${RANDLIST} ${MASTER_SITES_SOURCEFORGE_EXTENDED}
.endif
.if !defined(IGNORE_MASTER_SITE_SOURCEFORGE_JP)
diff --git a/Mk/rnd.awk b/Mk/rnd.awk
new file mode 100644
index 000..fbfcad7
--- /dev/null
+++ b/Mk/rnd.awk
@@ -0,0 +1,14 @@
+BEGIN {
+# Need to drop a couple of initial rand() values: they tend
+# to be around 0.8 - 0.9, so for fairly small array lenght
+# they will produce identical values at the beginning.
+ srand(); rand(); rand(); rand(); rand();
+ for (i = ARGC - 1; i 0; i--) {
+ j = int(10*ARGC*rand()) % i + 1;
+ if (j == i) continue;
+ t = ARGV[i]; ARGV[i] = ARGV[j]; ARGV[j] = t;
+ }
+
+ for (i = 1; i ARGC; i++)
+ print ARGV[i];
+}
--
1.6.0.3
--- 0001-Implement-randomization-of-main-SourceForge-sites.patch ends here ---
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Mel, good day.
Mon, Oct 06, 2008 at 11:24:54AM +0200, Mel wrote:
On Monday 06 October 2008 07:23:37 Eygene Ryabinkin wrote:
But downloading the INDEX file from the central server seemed to be the
best way, since it almost always gives one the latest port versions, so
I had implemented this in a first place.
I've been following this, but I don't agree that (port|pkg_)audit should do
this, from the very perspective you're writing this program from:
The download is done not by the portaudit itself, but by the helper
script, portaudit-checknew.
On Sunday 28 September 2008 11:49:18 Eygene Ryabinkin wrote:
4. I feel that it is Unix-way to do the things: create small utilities
that do their (small) job in a proper fashion.
Instead, it can provide installed-pkgnameseperatorpkgorigin output. Then,
any utility can check whether a new version is available, using what ever
source it finds relevant.
For example, it is completely irrelevant if a new version is available on the
FreeBSD servers, when your machine uses a buildserver in a local network. For
those machines it's relevant whether their build server has a new version and
one can automatically upgrade if one so desires.
Similarly, if your /usr/ports is ahead of the FreeBSD's INDEX.bz2, you're
again reporting false information.
I hear you, but it seems to me that I should just equip
portaudit-checknew with the other sources of a new ports information and
provide tunables for their location (on-disk path, URL, etc). I am
planning to do this, but first I want to know if these patches will be
viable for the project: feeding these into the /dev/null or just using
them locally, but equipping with a lot of functionality, is not what I
really want ;))
It's also quite trivial to provide this availibility information in a daily
security script, for the majority of cases
Didn't get it, sorry. Could you, please, elaborate a bit?
and it's better to have tunables
like _use_remote_portindex, _use_portsdir=/bigdisk/usr/ports in a script.
Yes, it was what I had talked about above in this mail.
Thanks for the input!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpuKwPqDpxaN.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Miroslav,
Mon, Oct 06, 2008 at 10:59:46AM +0200, Miroslav Lachman wrote:
I have '/usr/sbin/portsnap cron' and '/usr/sbin/portsnap -I update' in
my crontab, so I get INDEX updated every night before nightly security
e-mail is generated.
Ah, I see. Thanks!
But downloading the INDEX file from the central server seemed to be the
best way, since it almost always gives one the latest port versions, so
I had implemented this in a first place.
My previous question was not against your solution, it seems useful to
have really actual data from the fresh INDEX. It was just a question
how it is done. Maybe someone will be happier to use the existing
INDEX because of traffic on some GPRS internet connection or because of
the own INDEX creation. (it is not my case, I have all machines as the
servers with enough connectivity) ;)
OK, fine. I will implement the usage of the local INDEX file in some
days.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpSeTErdor9O.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Mel,
Mon, Oct 06, 2008 at 01:07:51PM +0200, Mel wrote:
On Monday 06 October 2008 12:28:48 Eygene Ryabinkin wrote:
Once you have the origin of the port, you can:
- make -C $PORTSDIR/$origin -V PKGNAME
- get the matching origin(s) out of ${INDEXDIR}/${INDEXFILE}
- get the matching origin(s) out of a downloaded INDEX.bz2
This covers the majority of cases.
What portaudit lacks, is providing the origin along with the installed package
name in easily parseable format. So, a central server wanting to query all
the machines for vulnerable packages, now has to do an extra step of going
into $PKG_DBDIR/$pkgname/+CONTENTS and getting the @comment ORIGIN: line,
while (port|pkg_)audit has just been there.
This would be something I'd expect:
ssh clientmachine /usr/sbin/pkg_audit -l
foo-1.2,3:misc/foo
bar-4.5_6:devel/bar
...
OK, got it. There is one neat: pkg_audit should be feeded with the
contents of the auditfile and the latter is located in the tar archive.
So, if you wouldn't mind about the following sequence
-
tar xf /var/db/portaudit/auditfile.tbz
pkg_audit auditfile | portaudit-checknew -o | cut -d '|' -f1,4,5
-
then I can add the flag '-o' to the portaudit-checknew: it will
additionally output the port origin along with the new version.
Is that what you meant?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpuMhKJfYS6l.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Mel,
Mon, Oct 06, 2008 at 02:40:48PM +0200, Mel wrote:
What I meant is the '-o' flag in pkg_audit, so I can figure out myself whether
it's new or not and my buildserver can prioritize it's builds based on
vulnerable packages it's clients have installed. The origin is the unique key
that identifies any port, so that's vital information in a pipeline.
Ah, OK: no problems, will do it.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpXKuYuEjsHH.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Mon, Oct 06, 2008 at 02:30:29PM +0400, Eygene Ryabinkin wrote: OK, fine. I will implement the usage of the local INDEX file in some days. OK, I had implemented both '-o' option to pkg_audit and the usage of the local INDEX file. I had reworked pkg_audit and portaudit a bit further, mostly fixing some issues (both mine and existing). Here we go. Patches for pkg_install that adds pkg_audit: http://codelabs.ru/fbsd/patches/portaudit/0001-Add-functions-for-traversing-package-database-and-ma.patch http://codelabs.ru/fbsd/patches/portaudit/0002-Add-function-match_get_pkgorigin.patch http://codelabs.ru/fbsd/patches/portaudit/0003-New-utility-pkg_audit.patch http://codelabs.ru/fbsd/patches/portaudit/0004-pkg_audit-add-option-to-print-origins.patch Mega-patch for pkg_install: http://codelabs.ru/fbsd/patches/portaudit/pkg_install-megapatch-pkg_audit.diff Patches for portaudit: http://codelabs.ru/fbsd/patches/portaudit/0001-Avoid-usage-of-global-variables-N-in-the-print_affe.patch http://codelabs.ru/fbsd/patches/portaudit/0002-Separate-vulnerable-ports-search-from-the-formatter.patch http://codelabs.ru/fbsd/patches/portaudit/0003-Use-pkg_audit-utility-if-it-is-available.patch http://codelabs.ru/fbsd/patches/portaudit/0004-Implement-checking-for-a-new-package-versions.patch Mega-patch for portaudit: http://codelabs.ru/fbsd/patches/portaudit/portaudit-megapatch_pkg_audit-and-checknew.diff Opinions are welcome! -- Eygene ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Forgot to say: Tue, Oct 07, 2008 at 12:30:58AM +0400, Eygene Ryabinkin wrote: OK, I had implemented both '-o' option to pkg_audit and the usage of the local INDEX file. The latter can be activated by writing something like - portaudit_pkg_index=file:///usr/ports/INDEX-%d - to the /usr/local/etc/portaudit.conf. -- Eygene ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Miroslav, good day.
Sun, Sep 28, 2008 at 04:14:24PM +0400, Eygene Ryabinkin wrote:
If I read nightly security e-mail with for example 4 vulnerable
packages, then I need to log in to server and manualy try, if newer
(fixed) packages are available. It seems not so hard to check output of
`pkg_version -vIL =` and compare both versions (installed and available)
with portaudit in some shellscript, I didn't start to write it yet ;).
I think it won't be very hard: I'll try to see how to extend portaudit
with such functionality -- it would be very handy, in my opinion.
OK, I extended portaudit with this -- flag '-n' will do it. Currently
this option requires network access, but I think that it is perfectly
fits into the security check -- it downloads auditfile anyway.
I had greatly reworked the old part of patch and I have series of
4 patches that implement both my pkg_audit stuff and the '-n' stuff.
I am also attaching the mega-patch, it can be applied to the current
port sources to give the port version that includes both mentioned
enchancements. If you have no pkg_audit -- this isn't a problem:
portaudit fill fall back to the awk script.
I had also changed the output format for pkg_audit, so I am attaching
another version of the second patch for the pkg_install bundle.
I had briefly tested my modifications -- they work for now, but I will
continue testing. Any bug reports or thoughts about these patches are
more that welcome.
Hadn't you have a chance to test my patch?
Miroslav, still: had you tested the pkg_audit thingy?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 88a3659c2d941e27de698fe05e4852a9f418f16e Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin [EMAIL PROTECTED]
Date: Tue, 26 Aug 2008 15:08:46 +0400
Subject: [PATCH] New utility: pkg_audit
It is mainly a helper for portupgrade to avoid awk scripting and
numerous calls for pkg_info. This utility speeds up portaudit by a
factor of 10 on a system with 521 installed ports and the auditfile that
contains 3213 entries:
-
$ ls -d /var/db/pkg/* | wc -l
521
$ tar xOf /var/db/portaudit/auditfile.tbz auditfile | sed -e'/^#/d' | wc -l
3213
$ time ./portaudit
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- DNS spoofing vulnerability.
Reference: http://www.FreeBSD.org/ports/portaudit/959d384d-6b59-11dd-9d79-001fc61c2a55.html
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- DoS vulnerability in WEBrick.
Reference: http://www.FreeBSD.org/ports/portaudit/f7ba20aa-6b5a-11dd-9d79-001fc61c2a55.html
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- multiple vulnerabilities in safe level.
Reference: http://www.FreeBSD.org/ports/portaudit/c329712a-6b5b-11dd-9d79-001fc61c2a55.html
3 problem(s) in your installed packages found.
You are advised to update or deinstall the affected package(s) immediately.
real0m0.107s
user0m0.116s
sys 0m0.012s
$ time portaudit
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- multiple vulnerabilities in safe level.
Reference: http://www.FreeBSD.org/ports/portaudit/c329712a-6b5b-11dd-9d79-001fc61c2a55.html
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- DoS vulnerability in WEBrick.
Reference: http://www.FreeBSD.org/ports/portaudit/f7ba20aa-6b5a-11dd-9d79-001fc61c2a55.html
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- DNS spoofing vulnerability.
Reference: http://www.FreeBSD.org/ports/portaudit/959d384d-6b59-11dd-9d79-001fc61c2a55.html
3 problem(s) in your installed packages found.
You are advised to update or deinstall the affected package(s) immediately.
real0m1.583s
user0m0.560s
sys 0m1.057s
-
Signed-off-by: Eygene Ryabinkin [EMAIL PROTECTED]
---
Makefile |2 +-
audit/Makefile| 14 +++
audit/audit.h | 43 +
audit/main.c | 166 ++
audit/parse.c | 259 +
audit/pkg_audit.1 | 63 +
6 files changed, 546 insertions(+), 1 deletions(-)
create mode 100644 audit/Makefile
create mode 100644 audit/audit.h
create mode 100644 audit/main.c
create mode 100644 audit/parse.c
create mode 100644 audit/pkg_audit.1
diff --git a/Makefile b/Makefile
index fefbd08..abc1e65 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
.include bsd.own.mk
-SUBDIR= lib add create delete info updating version
+SUBDIR= lib add create delete info updating version audit
.include bsd.subdir.mk
diff --git a/audit/Makefile b/audit/Makefile
new file mode 100644
index 000..2ece5f8
--- /dev/null
+++ b/audit
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Sun, Oct 05, 2008 at 11:03:17PM +0400, Eygene Ryabinkin wrote:
I had also changed the output format for pkg_audit, so I am attaching
another version of the second patch for the pkg_install bundle.
One neat about new pkg_audit utility: if you already have the build
directory for pkg_install in the /usr/obj, you should create
subdirectory for the pkg_audit,
-
mkdir /usr/obj/usr/src/usr.sbin/pkg_install/audit
-
or completely remove /usr/obj/usr/src/usr.sbin/pkg_install
World build should do it automatically, at least it worked for me.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpWtGcmATrQb.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Miroslav, good day.
Mon, Oct 06, 2008 at 12:41:05AM +0200, Miroslav Lachman wrote:
I am busy these days, but it is nice to read about your progress. I hope
I will get some time to test all of these large patches in a few days
and I will report back my experiences!
Fine, thank you! I am re-CC'ing bug-followup@ to track this letter,
since it contains some useful information that should go into GNATS.
One note before tests... do -n flag always download new INDEX file, or
is it possible to use one already existing in /usr/ports?
Currently, it is downloads bzipped INDEX file to /var/db/portaudit every
time, but it uses mirror mode, so if remote file hadn't changed at all,
all network expences are just the HTTP's HEAD request and reply.
I can add another variable to the portaudit to force the usage of the
existing INDEX file, if it is needed. By the way, how are you keeping
your INDEX file up to date (your proposed usage of 'pkg_version -I'
implies that you're always rely on it)? I am just curious -- my INDEX
files are almost always stay unupdated, even if I am using portupgrade.
And there can be another way if one keeps ports tree updated: utility
can use 'make' to determine the version that is currently available on
the examined host.
But downloading the INDEX file from the central server seemed to be the
best way, since it almost always gives one the latest port versions, so
I had implemented this in a first place.
Don't know, however, how the badly the load to the central HTTP server
will be raised. I am using just two first fields from the INDEX file,
so I can use such a stripped file. For me, the reduction was about
6x: SIZE(INDEX-7.bz2) = 1126189, SIZE(INDEX-7.stripped.bz2) = 184345.
I am CC'ing the portmgr team. Guys, could you quickly glance over these
patches and determine if they are useful to the project in large? If
yes, then may be such a stripped INDEX can be created on the FreeBSD
servers (via cut -f1-2 -d'|' INDEX-N)?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgprRLFRNHCoS.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Roman, good day.
Sat, Sep 27, 2008 at 08:18:08PM +0400, Roman Kurakin wrote:
Have you also posted this to [EMAIL PROTECTED]
No, forgot to do it. CC'ing ports@
Thanks!
The original posting to hackers@ goes below. It will be double-posted
to the bug-followup@ -- sorry for this.
Eygene Ryabinkin wrote:
Good day.
A while ago I had created the new utility that serves as VuXML
filter for the installed packages:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126853
My primary intention was to speed up the process of auditing the
vulnerable ports: I needed to run portaudit checks with Nagios and to
avoid large timeouts.
The new utility is called pkg_audit and it serves as a simple text
filter: on input it takes the full VuXML feed and on output it puts
VuXML entries that matches ports that are installed in the system with
port version specification substituted with the actual port versions.
No harm is done to the actual poartudit -- if pkg_audit is missing, old
code path is activated.
If someone is interested and will be able to test -- I am all ears.
Additional clarifications inspired by the off-line talk with rik@:
I could take another route and add this functionality to the pkg_info.
I took another approach for the following reasons.
1. pkg_info's option list is already quite big -- around 32 options
and switches.
2. It is easier to test for the presence of the new tool (pkg_audit)
and use it, instead of checking the support for the new option in
pkg_info.
3. I see no options in pkg_info that can be naturally extended to
absorbe the new functionality. The closest is '-E', but pkg_audit
needs to read VuXML entries, choose ones that are present in the system
and output the found VuXML entries with version templates substituted
with the real entries, so pkg_audit is filter-like utility. In my
opinion, such extension of pkg_info's -E will be very unnatural.
4. I feel that it is Unix-way to do the things: create small utilities
that do their (small) job in a proper fashion. Moreover, since the
majority of a code sits in the pkg_install's library, there is a very
slight code duplication, if any.
Thanks for you time.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpxR54ZXBf54.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Miroslav, good day.
Sun, Sep 28, 2008 at 01:15:01PM +0200, Miroslav Lachman wrote:
Is there any possibility to cooperate portaudit / pkg_audit with
pkg_version to show vulnerable package with information if newer (not
vulnerable) package (or port) version is available for upgrade to?
If I read nightly security e-mail with for example 4 vulnerable
packages, then I need to log in to server and manualy try, if newer
(fixed) packages are available. It seems not so hard to check output of
`pkg_version -vIL =` and compare both versions (installed and available)
with portaudit in some shellscript, I didn't start to write it yet ;).
I think it won't be very hard: I'll try to see how to extend portaudit
with such functionality -- it would be very handy, in my opinion.
Hadn't you have a chance to test my patch?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpy7qxsMg204.pgp
Description: PGP signature
Re: DSO loading (dlopen) appearse to be broken somehow
Andrey, good day. Wed, Apr 04, 2007 at 05:35:29PM +0400, Andrey Chernov wrote: On Wed, Apr 04, 2007 at 09:09:44AM -0400, Alexander Kabaev wrote: 1) The symbols in question are all _defined_ inside main httpd program. objdump -T output goes here. Those symbols are in 'nm' table of httpd like this 0804a84a T ap_palloc but not found in its objdump -T output. Why and how it may happens? Try '-Wl,--export-dynamic' flag to the gcc (or just --export-dynamic to the ld), it may help you. -- Eygene ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X.org, dlopen and -current problem
After buildworld and buildkernel I have done a 'make delete-old-libs' and removed objformat. I think now we are on the right path ... I've managed to get xorg-server to run at 7-CURRENT. The attached file should be put into the files/ directory of the xorg-server port (the existing file should be overwritten). It works for me, so, please, test it. I've not been able to spot the deep reason, but the immediate reason for failures was that no external symbols from the libraries were exported in the 'Xorg' binary for the dlopen() function. The addition of --export-dynamic flag to the 'ld' program solved the problem. I will try to understand if objformat changes are related to this problem. Jiawei, thanks for the pointer. -- Eygene --- config/cf/FreeBSD.cf.orig Wed May 4 04:14:57 2005 +++ config/cf/FreeBSD.cfFri Feb 9 08:26:54 2007 @@ -78,6 +78,7 @@ #define HasIssetugid YES #define HasPollYES #endif +#define BuildHtmlManPages NO #if OSMajorVersion = 4 #define HasGetIfAddrs YES @@ -116,15 +117,14 @@ # endif # if (OSRelVersion 500043) # define NeedUIThrStubs YES -# endif -# if (OSRelVersion = 502102) -# define ThreadsLibraries -lpthread -# elif (OSRelVersion = 500016) -# define ThreadsLibraries -lc_r +# define BuildThreadStubLibrary YES +# define SharedX11Reqs$(LDPRELIB) $(XTHRSTUBLIB) +# define SharedXtReqs $(LDPRELIB) $(XONLYLIB) $(SMLIB) $(ICELIB) $(XTHRSTUBLIB) # else -# define ThreadsLibraries -pthread +# define BuildThreadStubLibrary NO # endif -# define SystemMTDefines -D_THREAD_SAFE +# define ThreadsLibraries FreeBSDPTHREAD_LIBS +# define SystemMTDefines FreeBSDPTHREAD_CFLAGS #endif /* This fixes linking C programs against libGLU on FreeBSD 3.x */ @@ -172,12 +172,14 @@ #endif #endif -#ifndef CcCmd -#define CcCmd cc -#endif -#ifndef CplusplusCmd -#define CplusplusCmd c++ +#if BuildThreadStubLibrary (!defined(UseInstalledX11) || !UseInstalledX11) +#define CcCmd $(CLIENTENVSETUP) FreeBSDCC +#define CplusplusCmd $(CLIENTENVSETUP) FreeBSDCXX +#else +#define CcCmd FreeBSDCC +#define CplusplusCmd FreeBSDCXX #endif + #define CppCmd /usr/bin/cpp #define PreProcessCmd CppCmd #define StandardCppOptions -traditional @@ -338,7 +340,7 @@ #ifndef LibraryRpathLoadFlags # if UseRpath # if UseElfFormat -# define LibraryRpathLoadFlags -rpath $(USRLIBDIRPATH) +# define LibraryRpathLoadFlags -Wl,-rpath $(USRLIBDIRPATH) # else # define LibraryRpathLoadFlags -R $(USRLIBDIRPATH) # endif @@ -446,7 +448,9 @@ #ifdef PpcArchitecture #define XF86INT10_BUILDX86INT10_STUB #endif - +#ifdef PpcArchitecture +#define XF86INT10_BUILDX86INT10_STUB +#endif #define StandardDefines-DCSRG_BASED #if OSMajorVersion 1 @@ -467,18 +471,8 @@ #define XawI18nDefines -DUSE_XWCHAR_STRING -DUSE_XMBTOWC #endif -/* The GCC strength-reduce bug is fixed for FreeBSD 2.1.5 and later */ -#ifndef DefaultGcc2i386Opt -#if OSMajorVersion 2 || (OSMajorVersion == 2 OSMinorVersion 1) || (OSMajorVersion == 2 OSMinorVersion == 1 OSTeenyVersion = 5) -#define DefaultGcc2i386Opt -O2 GccAliasingArgs -#endif -#endif - -#ifdef i386Architecture -# define OptimizedCDebugFlags DefaultGcc2i386Opt -#else -# define OptimizedCDebugFlags -O -#endif +#define DefaultGcc2i386Opt +#define OptimizedCDebugFlags FreeBSDCFLAGS #ifndef PreIncDir # define PreIncDir /usr/include @@ -575,6 +569,13 @@ */ #if (GccMajorVersion == 2 GccMinorVersion == 95) #define GccOptBug295 +#endif + +/* + * Add --export-dynamic flag for FreeBSD 7.x and later. + */ +#if OSMajorVersion = 7 +#define ExtraLoadOptions -Wl,--export-dynamic #endif #include bsdLib.rules ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X.org, dlopen and -current problem
Rainer, thank you for answering. No problems. First I should ask some simple questions: - I assume that xorg-server and xorg-libraries were recompiled for the version 6.9.0_6? - How you updated the xorg? Via portupgrade, by hands, some other way? yes, both libraries were recompiled with newest portupgrade, no error message was given. You meant 'both ports'. Fine. And the last simple question: what is the output from 'ldconfig -r| grep libXfont'? Installation should invoke ldconfig, but may be something went wrong. -- Eygene ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Modified patchfile for archivers/rpm4 to understand python 2.4
Good day!
I've modified files/patch-configure to take into account the existence
of python 2.4. Port correctly builds on the 6.1-STABLE and produces
no warning during deinstallation even if it was compiled with WITH_PYTHON
knob. Without the patch and with python-2.4 in the system port was not
recognizing such new version of python and did not build python
bindings.
--
Eygene
--- configure.orig Thu Feb 14 02:03:27 2002
+++ configure Tue Sep 12 10:54:53 2006
@@ -186,6 +186,8 @@
ac_help=$ac_help
--with-libiconv-prefix=DIR search for libiconv in DIR/include and DIR/lib
ac_help=$ac_help
+ --with-popt-prefix=DIR search for popt in DIR/include and DIR/lib
+ac_help=$ac_help
--disable-nls do not use Native Language Support
ac_help=$ac_help
--with-included-gettext use the GNU gettext library included here
@@ -7381,6 +7383,8 @@
# AC_DEFINE(HAVE_GZSEEK)
#fi
+WITH_POPT_INCLUDE=$ac_default_prefix/include
+WITH_POPT_LIB=-L$ac_default_prefix/lib -lpopt
@@ -8335,6 +8339,47 @@
DBLIBSRCS=$DBLIBSRCS db3.c; libdb3=-ldb
else
echo $ac_tno 16
+echo $ac_n checking for db_create in -ldb3... $ac_c 16
+echo configure:8188: checking for db_create in -ldb3 5
+ac_lib_var=`echo db3'_'db_create | sed 'y%./+-%__p_%'`
+if eval test \`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\ = set; then
+ echo $ac_n (cached) $ac_c 16
+else
+ ac_save_LIBS=$LIBS
+LIBS=-ldb3 $libthread $LIBS
+cat conftest.$ac_ext EOF
+#line 8196 configure
+#include confdefs.h
+/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+builtin and then its argument prototype would still apply. */
+char db_create();
+
+int main() {
+db_create()
+; return 0; }
+EOF
+if { (eval echo configure:8207: \$ac_link\) 15; (eval $ac_link) 25; }
test -s conftest${ac_exeext}; then
+ rm -rf conftest*
+ eval ac_cv_lib_$ac_lib_var=yes
+else
+ echo configure: failed program was: 5
+ cat conftest.$ac_ext 5
+ rm -rf conftest*
+ eval ac_cv_lib_$ac_lib_var=no
+fi
+rm -f conftest*
+LIBS=$ac_save_LIBS
+
+fi
+if eval test \`echo '$ac_cv_lib_'$ac_lib_var`\ = yes; then
+ echo $ac_tyes 16
+ DBLIBSRCS=$DBLIBSRCS db3.c; libdb3=-ldb3
+else
+ echo $ac_tno 16
+fi
+
+
fi
@@ -8659,6 +8704,100 @@
fi
+# Check whether --with-popt-prefix or --without-popt-prefix was given.
+if test ${with_popt_prefix+set} = set; then
+ withval=$with_popt_prefix
+
+for dir in `echo $withval | tr : ' '`; do
+ if test -d $dir/include; then
+CPPFLAGS=$CPPFLAGS -I$dir/include;
+WITH_POPT_INCLUDE=-I$dir/include;
+ fi
+ if test -d $dir/lib; then
+LDFLAGS=$LDFLAGS -L$dir/lib;
+WITH_POPT_LIB=-L$dir/lib -lpopt;
+ fi
+done
+fi
+
+echo $ac_n checking for popt.h... $ac_c 16
+echo configure:8724: checking for popt.h 5
+ac_lib_var=`echo popt'_'h | sed 'y%./+-%__p_%'`
+if eval test \`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\ = set; then
+ echo $ac_n (cached) $ac_c 16
+else
+ ac_save_CPPFLAGS=$CPPFLAGS
+CPPFLAGS=${WITH_POPT_INCLUDE} $CPPFLAGS
+cat conftest.$ac_ext EOF
+#line 8494 configure
+#include confdefs.h
+#include popt.h
+/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+builtin and then its argument prototype would still apply. */
+
+int main() {
+return 0; }
+EOF
+if { (eval echo configure:8505: \$ac_link\) 15; (eval $ac_link) 25; }
test -s conftest${ac_exeext}; then
+ rm -rf conftest*
+ eval ac_cv_lib_$ac_lib_var=yes
+else
+ echo configure: failed program was: 5
+ cat conftest.$ac_ext 5
+ rm -rf conftest*
+ eval ac_cv_lib_$ac_lib_var=no
+fi
+rm -f conftest*
+CPPFLAGS=$ac_save_CPPFLAGS
+
+fi
+if eval test \`echo '$ac_cv_lib_'$ac_lib_var`\ = yes; then
+ echo $ac_tyes 16
+else
+ echo $ac_tno 16
+ echo configure: error: sorry rpm requires popt.h 12; exit 1;
+fi
+
+echo $ac_n checking for poptGetOptArg in -lpopt... $ac_c 16
+echo configure:8724: checking for poptGetOptArg in -lpopt 5
+ac_lib_var=`echo popt'_'poptGetOptArg | sed 'y%./+-%__p_%'`
+if eval test \`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\ = set; then
+ echo $ac_n (cached) $ac_c 16
+else
+ ac_save_LIBS=$LIBS
+LIBS=${WITH_POPT_LIB} $LIBS
+cat conftest.$ac_ext EOF
+#line 8494 configure
+#include confdefs.h
+#include popt.h
+/* Override any gcc2 internal prototype to avoid an error. */
+/* We use char because int might match the return type of a gcc2
+builtin and then its argument prototype would still apply. */
+
+int main() {
+const char *foo = poptGetNextOpt(NULL);
+return 0; }
+EOF
+if { (eval echo configure:8505: \$ac_link\) 15; (eval $ac_link) 25; }
test -s conftest${ac_exeext}; then
+ rm -rf conftest*
+ eval ac_cv_lib_$ac_lib_var=yes
+else
+ echo configure: failed program was: 5
+ cat conftest.$ac_ext 5
+ rm -rf conftest*
+ eval ac_cv_lib_$ac_lib_var=no
+fi
+rm -f conftest*
+LIBS=$ac_save_LIBS
+
+fi
+if eval test \`echo '$ac_cv_lib_'$ac_lib_var`\
