Porters Handbook update
Beloved porters, following some discussions related to the rights and duties of ports maintainers it became obvious that our handbook was not specific enough on the matter. Hence an update was committed that aims at clarifying the notion of maintainership and all porters are invited to peruse the changes: http://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html And of course, a big thanks to all of you who dedicate their time to maintain our ports! Frederic, with portmgr-secretary hat on pgpP_OokZ4XxA.pgp Description: PGP signature
Re: Bug 191256 - [PATCH] security/libgcrypt: update to 1.6.1
Hi! Log see http://people.freebsd.org/~pi/misc/build-libgcrypt.txt Hmm. I'm a bit confused now. I checked the newly linked libgcrypt.so.20 (located in src/.libs) and it seems to have all of the missing symbols in its symbol table, but all are undefined. I ran nm -D on the file and: The symbols are defined in cast5-amd64.S, but this file is not added to libgcrypt.so. This needs to be fixed, then it probably works. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: Bug 191256 - [PATCH] security/libgcrypt: update to 1.6.1
Hi! Log see http://people.freebsd.org/~pi/misc/build-libgcrypt.txt Hmm. I'm a bit confused now. I checked the newly linked libgcrypt.so.20 (located in src/.libs) and it seems to have all of the missing symbols in its symbol table, but all are undefined. I ran nm -D on the file and: The symbols are defined in cast5-amd64.S, but this file is not added to libgcrypt.so. This needs to be fixed, then it probably works. Hm, it looks like most of the cipher/*-amd64.S files are not linked in. I prepared a bug report upstream: https://bugs.g10code.com/gnupg/issue1668 -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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
upgrade to security/libgcrypt, shared lib bump, what needs to be done ?
Hello, Tijl, Someone prepared a patch to bring security/libgcrypt from 1.5.3 to 1.6.1, see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191256 I prepared a diff which builds and tests, see http://people.freebsd.org/~pi/misc/libgcrypt.svndiff and http://people.freebsd.org/~pi/misc/libgcrypt-1.6.1.log for the build log. It causes a shared lib upgrade, what needs to be done to the dependencies (list below) ? I've read http://lists.freebsd.org/pipermail/freebsd-ports/2014-May/092082.html but I think I'm still missing some of the fine print 8-( It needs USES=libtool, but does it *need* libtool:oldver or libtool:keepla ? Do I need to bump PORTREVISION on the dependencies ? Thanks for any hints! security/vpnc net/libvncserver textproc/libxslt security/libgnome-keyring multimedia/libaacs net/remmina net/glib-networking devel/gvfs devel/libvirt security/xmlsec1 security/libotr3 multimedia/vlc textproc/p5-XML-LibXSLT net/wireshark editors/libreoffice security/gnupg devel/libsoup net-im/mcabber devel/libsoup-gnome ftp/filezilla sysutils/freeipmi -- p...@freebsd.org +49 171 3101372 6 years to go ! ___ 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: upgrade to security/libgcrypt, shared lib bump, what needs to be done ?
On Sun, 6 Jul 2014 13:16:43 +0200 Kurt Jaeger wrote:
Hello, Tijl,
Someone prepared a patch to bring security/libgcrypt from 1.5.3 to 1.6.1, see:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191256
I prepared a diff which builds and tests, see
http://people.freebsd.org/~pi/misc/libgcrypt.svndiff
and
http://people.freebsd.org/~pi/misc/libgcrypt-1.6.1.log
for the build log.
It causes a shared lib upgrade, what needs to be done to the dependencies
(list below) ?
I've read
http://lists.freebsd.org/pipermail/freebsd-ports/2014-May/092082.html
but I think I'm still missing some of the fine print 8-(
It needs USES=libtool, but does it *need* libtool:oldver or libtool:keepla ?
Do I need to bump PORTREVISION on the dependencies ?
Thanks for any hints!
security/vpnc
net/libvncserver
textproc/libxslt
security/libgnome-keyring
multimedia/libaacs
net/remmina
net/glib-networking
devel/gvfs
devel/libvirt
security/xmlsec1
security/libotr3
multimedia/vlc
textproc/p5-XML-LibXSLT
net/wireshark
editors/libreoffice
security/gnupg
devel/libsoup
net-im/mcabber
devel/libsoup-gnome
ftp/filezilla
sysutils/freeipmi
You can deal with the amd64 versus x86_64 problem by adding this to the
Makefile:
CONFIGURE_TARGET=${ARCH:S/amd64/x86_64/}-portbld-${OPSYS:tl}${OSREL}
:oldver is meant to keep the library version the same in case that's
more convenient. Because the update already modifies the library version
it makes no sense to use it. You can add USES=libtool:keepla to the
Makefile, rebuild the port and then check with make check-plist what
the effects on pkg-plist are. It looks like you'll have to add
lib/libgcrypt.so.20.0.1
Then you'll have to bump PORTREVISION on ports that depend on libgcrypt.
There are a lot more than the ones you listed. You could take the union
of these two lists:
cd /usr/ports
grep -Rl '{PORTSDIR}/security/libgcrypt' *
pkg rquery '%o %B' | grep libgcrypt.so | sort
To actually bump ports you can use one of the scripts in Tools/scripts
like bump-revision.sh.
___
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 with a broken PKGORIGIN: textproc/libxml2-reference
** The following ports have an incorrect PKGORIGIN ** PKGORIGIN connects packaged or installed ports to the directory they originated from. This is essential for tools like pkg_version or portupgrade to work correctly. Wrong PKGORIGINs are often caused by a wrong order of CATEGORIES after a repocopy. Please fix any errors as soon as possible. The ports tree was updated at Sun Jul 6 2014 12:40:25 UTC. - *textproc/libxml2-reference* po...@freebsd.org: /libxml2-reference ___ 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: COPYTREE_BIN/COPYTREE_SHARE does not work as expected
Dnia 2014-07-05, o godz. 12:04:57
Mikolaj Golub troc...@freebsd.org napisał(a):
Hi,
It looks like COPYTREE_BIN/COPYTREE_SHARE does not work as it is
documented in bsd.port.mk:
# Example use:
# cd ${WRKSRC}/doc ${COPYTREE_SHARE} . ${DOCSDIR}
! -name *.bak #
# Installs all directories and files from ${WRKSRC}/doc
# to ${DOCSDIR} except sed backup files.
If there is a *.bak file in . directory (e.g. test.bak), *.bak is
expanded to this name, the condition ! -name *.bak becomes ! -name
test.bak, and other *.bak files are ignored.
Worse, if there are several *.bak files, *.bak is expanded to the
list and COPYTREE_SHARE fails.
I made a mistake while documenting this macros, as '*' is a shell
wildcard it should be quoted. I believe the correct example should be:
cd ${WRKSRC}/doc ${COPYTREE_SHARE} . ${DOCSDIR} ! -name *.bak
--
pozdrawiam / with regards
Paweł Pękala
___
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: COPYTREE_BIN/COPYTREE_SHARE does not work as expected
Hi,
On Sun, 6 Jul 2014, Pawel Pekala wrote:
Dnia 2014-07-05, o godz. 12:04:57
Mikolaj Golub troc...@freebsd.org napisał(a):
Hi,
It looks like COPYTREE_BIN/COPYTREE_SHARE does not work as it is
documented in bsd.port.mk:
# Example use:
# cd ${WRKSRC}/doc ${COPYTREE_SHARE} . ${DOCSDIR}
! -name *.bak #
# Installs all directories and files from ${WRKSRC}/doc
# to ${DOCSDIR} except sed backup files.
If there is a *.bak file in . directory (e.g. test.bak), *.bak is
expanded to this name, the condition ! -name *.bak becomes ! -name
test.bak, and other *.bak files are ignored.
Worse, if there are several *.bak files, *.bak is expanded to the
list and COPYTREE_SHARE fails.
I made a mistake while documenting this macros, as '*' is a shell
wildcard it should be quoted. I believe the correct example should be:
cd ${WRKSRC}/doc ${COPYTREE_SHARE} . ${DOCSDIR} ! -name *.bak
It can't be done. sh -c will escape quotes.
I've simplified the test and modified it to show what's going on.
Your example doesn't escape the quotes, so quotes end and globbing
starts. The normal way to specify a glob to -name is '*.bak', so let's
see how that works out:
/bin/rm -rf /tmp/test_COPYTREE_SHARE
/bin/mkdir -p /tmp/test_COPYTREE_SHARE/src/1
/usr/bin/touch /tmp/test_COPYTREE_SHARE/src/1.bak
/usr/bin/touch /tmp/test_COPYTREE_SHARE/src/1/1.bak
/usr/bin/touch /tmp/test_COPYTREE_SHARE/src/1/2.bak
(cd /tmp/test_COPYTREE_SHARE/src /bin/sh -x -c '(/usr/bin/find -d $0
$2 | /usr/bin/cpio -dumpl $1 /dev/null 21) /usr/bin/find -d $0
$2 -type d -exec chmod 755 $1/{} \; /usr/bin/find -d $0 $2 -type f
-exec chmod 444 $1/{} \;' -- . /tmp/test_COPYTREE_SHARE/dst -not -name
'*.bak')
+ /usr/bin/find -d . -not -name \''*.bak'\'
+ /usr/bin/cpio -dumpl /tmp/test_COPYTREE_SHARE/dst
+ /usr/bin/find -d . -not -name \''*.bak'\' -type d -exec chmod 755
/tmp/test_COPYTREE_SHARE/dst/{} ';'
+ /usr/bin/find -d . -not -name \''*.bak'\' -type f -exec chmod 444
/tmp/test_COPYTREE_SHARE/dst/{} ';'
[ ! -f /tmp/test_COPYTREE_SHARE/dst/1/2.bak ]
*** [test1] Error code 1
Note how sh turns it into \''*.bak'\' effectively escaping the globbing
at find runtime. Similar if we swap quotes to '-not -name *.bak':
+ /usr/bin/find -d . -not -name '*.bak'
This has always been broken for globs as far as I know, which is why
cleaning up in post-patch is done.
I honestly think -fc is the best approach, since globbing the first path
is easily overcome and rare. Not having to run cleanup in post-patch has
advantages both at runtime and Makefile clutter.
Simplified test:
TESTDIR=/tmp/test_COPYTREE_SHARE
SH= /bin/sh -x
all: test1
test1:
${RM} -rf ${TESTDIR}
${MKDIR} ${TESTDIR}/src/1
${TOUCH} ${TESTDIR}/src/1.bak
${TOUCH} ${TESTDIR}/src/1/1.bak
${TOUCH} ${TESTDIR}/src/1/2.bak
(cd ${TESTDIR}/src ${COPYTREE_SHARE} . ${TESTDIR}/dst -not -name
'*.bak')
[ ! -f ${TESTDIR}/dst/1/2.bak ]
@${RM} -rf ${TESTDIR}
.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
These ports need commenter attention
These ports already have been staged and are very simple script only ports which are ready to be committed. 191660 qjail bug fix 191502 qchroot new port 190259 ppars updated 186269 can be closed ___ 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: COPYTREE_BIN/COPYTREE_SHARE does not work as expected
Hi Melvyn,
On 2014-07-06 16:34 +0200, Melvyn Sopacua mel...@magemana.nl wrote:
Hi,
On Sun, 6 Jul 2014, Pawel Pekala wrote:
Dnia 2014-07-05, o godz. 12:04:57
Mikolaj Golub troc...@freebsd.org napisał(a):
Hi,
It looks like COPYTREE_BIN/COPYTREE_SHARE does not work as it is
documented in bsd.port.mk:
# Example use:
# cd ${WRKSRC}/doc ${COPYTREE_SHARE} . ${DOCSDIR}
! -name *.bak #
# Installs all directories and files from
${WRKSRC}/doc # to ${DOCSDIR} except sed backup
files.
If there is a *.bak file in . directory (e.g. test.bak), *.bak
is expanded to this name, the condition ! -name *.bak becomes !
-name test.bak, and other *.bak files are ignored.
Worse, if there are several *.bak files, *.bak is expanded to
the list and COPYTREE_SHARE fails.
I made a mistake while documenting this macros, as '*' is a shell
wildcard it should be quoted. I believe the correct example should
be:
cd ${WRKSRC}/doc ${COPYTREE_SHARE} . ${DOCSDIR} ! -name *.bak
It can't be done. sh -c will escape quotes.
I've simplified the test and modified it to show what's going on.
Your example doesn't escape the quotes, so quotes end and globbing
starts. The normal way to specify a glob to -name is '*.bak', so let's
see how that works out:
/bin/rm -rf /tmp/test_COPYTREE_SHARE
/bin/mkdir -p /tmp/test_COPYTREE_SHARE/src/1
/usr/bin/touch /tmp/test_COPYTREE_SHARE/src/1.bak
/usr/bin/touch /tmp/test_COPYTREE_SHARE/src/1/1.bak
/usr/bin/touch /tmp/test_COPYTREE_SHARE/src/1/2.bak
(cd /tmp/test_COPYTREE_SHARE/src /bin/sh -x -c '(/usr/bin/find -d $0
$2 | /usr/bin/cpio -dumpl $1 /dev/null 21) /usr/bin/find -d $0
$2 -type d -exec chmod 755 $1/{} \; /usr/bin/find -d $0 $2 -type f
-exec chmod 444 $1/{} \;' -- . /tmp/test_COPYTREE_SHARE/dst -not -name
'*.bak')
+ /usr/bin/find -d . -not -name \''*.bak'\'
+ /usr/bin/cpio -dumpl /tmp/test_COPYTREE_SHARE/dst
+ /usr/bin/find -d . -not -name \''*.bak'\' -type d -exec chmod 755
/tmp/test_COPYTREE_SHARE/dst/{} ';'
+ /usr/bin/find -d . -not -name \''*.bak'\' -type f -exec chmod 444
/tmp/test_COPYTREE_SHARE/dst/{} ';'
[ ! -f /tmp/test_COPYTREE_SHARE/dst/1/2.bak ]
*** [test1] Error code 1
Note how sh turns it into \''*.bak'\' effectively escaping the globbing
at find runtime. Similar if we swap quotes to '-not -name *.bak':
+ /usr/bin/find -d . -not -name '*.bak'
This has always been broken for globs as far as I know, which is why
cleaning up in post-patch is done.
Little hackish, but this seems to work:
(cd ${TESTDIR}/src ${COPYTREE_SHARE} . ${TESTDIR}/dst -not -name *\.bak)
--
pozdrawiam / with regards
Paweł Pękala
___
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: Porters Handbook update
On Sun, Jul 6, 2014 at 12:59 AM, Frederic Culot cu...@freebsd.org wrote: Beloved porters, following some discussions related to the rights and duties of ports maintainers it became obvious that our handbook was not specific enough on the matter. Hence an update was committed that aims at clarifying the notion of maintainership and all porters are invited to peruse the changes: http://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html And of course, a big thanks to all of you who dedicate their time to maintain our ports! Frederic, with portmgr-secretary hat on excluding major public holidays to what segment of the public? I see maintainers from countries all over the world. I m sure that there are maintainers from followers of every significant religion and many others. I am unaware of any major public holidays that are celebrated in all of them. I don't know of any holiday celebrated in all nations and cultures. This look to be a rather useless clause in practice. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: COPYTREE_BIN/COPYTREE_SHARE does not work as expected
Hi Pawel,
On Sun, 6 Jul 2014, Pawel Pekala wrote:
Hi Melvyn,
On 2014-07-06 16:34 +0200, Melvyn Sopacua mel...@magemana.nl wrote:
+ /usr/bin/find -d . -not -name '*.bak'
This has always been broken for globs as far as I know, which is why
cleaning up in post-patch is done.
Little hackish, but this seems to work:
(cd ${TESTDIR}/src ${COPYTREE_SHARE} . ${TESTDIR}/dst -not -name *\.bak)
Wow, great find. Defenitely needs documentation :).
--
Melvyn
___
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: upgrade to security/libgcrypt, shared lib bump, what needs to be done ?
Hi!
It needs USES=libtool, but does it *need* libtool:oldver or libtool:keepla ?
Do I need to bump PORTREVISION on the dependencies ?
[...]
You can deal with the amd64 versus x86_64 problem by adding this to the
Makefile:
CONFIGURE_TARGET=${ARCH:S/amd64/x86_64/}-portbld-${OPSYS:tl}${OSREL}
Ok, changed it.
:oldver is meant to keep the library version the same in case that's
more convenient. Because the update already modifies the library version
it makes no sense to use it. You can add USES=libtool:keepla to the
Makefile, rebuild the port and then check with make check-plist what
the effects on pkg-plist are. It looks like you'll have to add
lib/libgcrypt.so.20.0.1
Done that.
Then you'll have to bump PORTREVISION on ports that depend on libgcrypt.
There are a lot more than the ones you listed. You could take the union
of these two lists:
cd /usr/ports
grep -Rl '{PORTSDIR}/security/libgcrypt' *
pkg rquery '%o %B' | grep libgcrypt.so | sort
To actually bump ports you can use one of the scripts in Tools/scripts
like bump-revision.sh.
I prepared a new diff, see
http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v2
Can you have a look at it, before I mess up the whole tree 8-} ?
Thanks!
--
p...@freebsd.org +49 171 3101372 6 years to go
!
___
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: Porters Handbook update
On Sun, 6 Jul 2014, Kevin Oberman wrote: On Sun, Jul 6, 2014 at 12:59 AM, Frederic Culot cu...@freebsd.org wrote: Beloved porters, following some discussions related to the rights and duties of ports maintainers it became obvious that our handbook was not specific enough on the matter. Hence an update was committed that aims at clarifying the notion of maintainership and all porters are invited to peruse the changes: http://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html And of course, a big thanks to all of you who dedicate their time to maintain our ports! Frederic, with portmgr-secretary hat on excluding major public holidays to what segment of the public? Easy fix: exluding local (to the maintainer) bank holidays. However, in practice, it's not enforced that strict. Some periods people work 90 hours a week, some periods they have their weekends and some periods they leave the house when they have them. But, I'm rather surprised that maintainers now get their responsibilities spelled out, while there's no section on committers, and quite a shortage of them. From my own experience, there have been people coaching me and I thank them for it, but on average I have to chase down the PR's to get them committed. This takes time out of the maintaining part, especially if you work on ports that require dependencies to be updated or entered into the tree before they can be updated or entered. And let me stress this, this by no means an attack on individual committers or committers as a group. It is an observation of resources in order to discuss possible solutions. By this post [1], Getting a commit bit does not obligate you to process PRs. Isn't it time to: - relax (and spell out) requirements for ports-comitters and / or: - add processing PR's to the responsibilities of ports-comitters I've skimmed what I considered relevant sections of the committers-guide and did not find much. If I missed it, feel free to point me to the section. [1] http://lists.freebsd.org/pipermail/freebsd-ports/2014-January/089221.html -- Melvyn ___ 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: upgrade to security/libgcrypt, shared lib bump, what needs to be done ?
On Sun, 6 Jul 2014 19:48:59 +0200 Kurt Jaeger wrote: I prepared a new diff, see http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v2 Can you have a look at it, before I mess up the whole tree 8-} ? net/samba4/Makefile: PORTREVISION messed up net/samba41/Makefile: PORTREVISION messed up security/libgcrypt/Makefile: Keep post-patch silent maybe? Looks good otherwise, so go ahead and commit ___ 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: upgrade to security/libgcrypt, shared lib bump, what needs to be done ?
On Sun, 6 Jul 2014 20:52:03 +0200 Tijl Coosemans wrote: On Sun, 6 Jul 2014 19:48:59 +0200 Kurt Jaeger wrote: I prepared a new diff, see http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v2 Can you have a look at it, before I mess up the whole tree 8-} ? net/samba4/Makefile: PORTREVISION messed up net/samba41/Makefile: PORTREVISION messed up security/libgcrypt/Makefile: Keep post-patch silent maybe? Looks good otherwise, so go ahead and commit There's no major incompatibility with the old version of libgcrypt right? Have you tried to compile some of the ports that depend on libgcrypt to see if nothing breaks? ___ 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: upgrade to security/libgcrypt, shared lib bump, what needs to be done ?
Hi! On Sun, 6 Jul 2014 20:52:03 +0200 Tijl Coosemans wrote: On Sun, 6 Jul 2014 19:48:59 +0200 Kurt Jaeger wrote: I prepared a new diff, see http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v2 Can you have a look at it, before I mess up the whole tree 8-} ? net/samba4/Makefile: PORTREVISION messed up net/samba41/Makefile: PORTREVISION messed up Ah, thanks, fixed. security/libgcrypt/Makefile: Keep post-patch silent maybe? If possible, I would like to keep those post-patch changes in the open. Looks good otherwise, so go ahead and commit There's no major incompatibility with the old version of libgcrypt right? In the 1.6.0 release notes at http://lists.gnupg.org/pipermail/gcrypt-devel/2013-December/002775.html there is a list of changed APIs. Some of them are removed. Which might cause issues. Have you tried to compile some of the ports that depend on libgcrypt to see if nothing breaks? No, due to number of ports involved (104), list at http://people.freebsd.org/~pi/misc/libgcrypt-related-ports For this we probably need some exp-run ? If one considers this a security-related change, and probably needs testing on functionality as well, I think that commit and fix those few that break looks like a possible short-cut 8-} -- p...@freebsd.org +49 171 3101372 6 years to go ! ___ 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: upgrade to security/libgcrypt, shared lib bump, what needs to be done ?
On Sun, 6 Jul 2014 21:27:20 +0200 Kurt Jaeger wrote: On Sun, 6 Jul 2014 20:52:03 +0200 Tijl Coosemans wrote: On Sun, 6 Jul 2014 19:48:59 +0200 Kurt Jaeger wrote: I prepared a new diff, see http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v2 Can you have a look at it, before I mess up the whole tree 8-} ? net/samba4/Makefile: PORTREVISION messed up net/samba41/Makefile: PORTREVISION messed up Ah, thanks, fixed. security/libgcrypt/Makefile: Keep post-patch silent maybe? If possible, I would like to keep those post-patch changes in the open. Looks good otherwise, so go ahead and commit There's no major incompatibility with the old version of libgcrypt right? In the 1.6.0 release notes at http://lists.gnupg.org/pipermail/gcrypt-devel/2013-December/002775.html there is a list of changed APIs. Some of them are removed. Which might cause issues. Have you tried to compile some of the ports that depend on libgcrypt to see if nothing breaks? No, due to number of ports involved (104), list at http://people.freebsd.org/~pi/misc/libgcrypt-related-ports For this we probably need some exp-run ? If one considers this a security-related change, and probably needs testing on functionality as well, I think that commit and fix those few that break looks like a possible short-cut 8-} It's safer to do an exp-run. You never know if some important port breaks. You can attach your patch to the bug and assign it to portmgr. Maybe also change the subject to include [exp-run]. ___ 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: upgrade to security/libgcrypt, shared lib bump, what needs to be done ?
Hi! Have you tried to compile some of the ports that depend on libgcrypt to see if nothing breaks? No, due to number of ports involved (104), list at http://people.freebsd.org/~pi/misc/libgcrypt-related-ports [...] For this we probably need some exp-run ? It's safer to do an exp-run. Then the PR is on it's way to portmgr for an exp-run now 8-} -- p...@freebsd.org +49 171 3101372 6 years to go ! ___ 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 that don't actually support Python 3.x
Hello, I'm coming accross a few ports that are in the tree as we speak, that do not actually install correctly with Python 3.x but aren't marked as 2.7 only. There seems to be 2 cases: 1. incompatibility in setup.py or related, thus failing in configure 2. incompatibility in the code itself, thus failing in byte_compile The ones in 2 fail with PYDISTUTILS_AUTOPLIST in install, because the files cannot be compiled and thus are missing when using the plist. I've got a few in PRs, few in the queue to become PR's, but perhaps a broader effort is needed? I'm willing to help, if an exp-run or something similar would generate a list. PS: A common error is: `except Exception, var:`. This can probably be fixed with a REINPLACE_CMD that can be standardized, but so far, bringing the port up-to-date with upstream fixes the problem (notable exception being www/py-beautifulsoup32). -- Melvyn ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports that don't actually support Python 3.x
Beautiful Soup 3.x is Python 2.x only. From the website: Beautiful Soup 3 works only under Python 2.x. http://www.crummy.com/software/BeautifulSoup/ On Sun, Jul 6, 2014 at 3:56 PM, Melvyn Sopacua mel...@magemana.nl wrote: Hello, I'm coming accross a few ports that are in the tree as we speak, that do not actually install correctly with Python 3.x but aren't marked as 2.7 only. There seems to be 2 cases: 1. incompatibility in setup.py or related, thus failing in configure 2. incompatibility in the code itself, thus failing in byte_compile The ones in 2 fail with PYDISTUTILS_AUTOPLIST in install, because the files cannot be compiled and thus are missing when using the plist. I've got a few in PRs, few in the queue to become PR's, but perhaps a broader effort is needed? I'm willing to help, if an exp-run or something similar would generate a list. PS: A common error is: `except Exception, var:`. This can probably be fixed with a REINPLACE_CMD that can be standardized, but so far, bringing the port up-to-date with upstream fixes the problem (notable exception being www/py-beautifulsoup32). -- Melvyn ___ 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 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports that don't actually support Python 3.x
On Sun, 6 Jul 2014, Robert Simmons wrote: Beautiful Soup 3.x is Python 2.x only. From the website: I know that. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191387#c3 The port doesn't: http://svn.freebsd.org/ports/head/www/py-beautifulsoup32/Makefile That was the point of the mail. -- Melvyn ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports that don't actually support Python 3.x
On 7/07/2014 7:52 AM, Melvyn Sopacua wrote: On Sun, 6 Jul 2014, Robert Simmons wrote: Beautiful Soup 3.x is Python 2.x only. From the website: I know that. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191387#c3 The port doesn't: http://svn.freebsd.org/ports/head/www/py-beautifulsoup32/Makefile That was the point of the mail. -- Melvyn ___ 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 Melvyn, Submit an issue with patch, I'll add maintainer_approval flag cc'ing maintainer if you cant, just let me know the issue ID :) These kinds of issues might also be worth granting blanket approval to fix -- Koobs ___ 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: Apache 2.4 must become default NOW
On 2014-07-05 19:09, Bjoern A. Zeeb wrote: Hi, given ports@ ist listed as maintainer, you get the email. The Subject says it. The world has moved on; in March I had a hard time arguing, in July I just cannot anymore. We must switch to 2.4; whatever breaks needs fixing, but somehow other distributions have managed and we did not and keep screwing our users missing a lot of security features. Please fix! — Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983 Hi Bjoern, nothing against this change, except your complain comes a little bit late. The portstree was already tagged for 9.3 some days ago so this change would be a possible issue for all users using the 9.3 packages. Before the default version can be changed a full expr. run by portmgr@ is required and all possible issues should be fixed. Unluckily we have a rolling ports tree (not like RHEL and others where such a change happens during new major releases) so there should be also a time frame to warn users about such a change. I remember endless discussions about the removal of apache13 after it was already deprecated nearly one year after upstream deprecation ... -- olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports that don't actually support Python 3.x
Hi Kubilay! On Mon, 7 Jul 2014, Kubilay Kocak wrote: On 7/07/2014 7:52 AM, Melvyn Sopacua wrote: Submit an issue with patch, I'll add maintainer_approval flag cc'ing maintainer if you cant, just let me know the issue ID :) Thought I submitted more already, but they're still in the queue and django-redis was comitted. Will submit tomorrow. We also gotta decide what you wanna do with www/py-django-mezzanine. I've created a www/py-django-mezzanine3 locally, as I wasn't sure if 1.x was kept in tree for existing projects that cannot migrate. Finally got it working (read: installing) fully (* marks py3.x fixes, - marks fixes bringing the ports to py3.x): % pkg install www/py-django-mezzanine3 Updating repository catalogue The following 31 packages will be installed: Installing gettext: 0.18.3.1_1 Installing sqlite3: 3.8.5_1 Installing libxml2: 2.9.1_1 Installing openssl: 1.0.1_13 Installing png: 1.5.18 Installing jpeg: 8_5 Installing python33: 3.3.5_1 Installing py33-setuptools33: 5.1_1 Installing py33-pycrypto: 2.6.1 Installing py33-slimit: 0.8.1 Installing py33-six: 1.5.2 Installing py33-django-appconf: 0.6_1 Installing py33-beautifulsoup: 4.3.2 - Installing py33-django-mezzanine3-grappelli: 0.3.11 - Installing py33-django-mezzanine3-filebrowser: 0.3.4 Installing py33-sqlite3: 3.3.5_4 Installing postgresql91-client: 9.1.13_1 Installing freetype2: 2.5.3_2 Installing py33-pytz: 2014.4,1 Installing py33-south: 1.0 Installing py33-requests: 2.3.0 * Installing py33-oauthlib: 0.6.3 - Installing py33-html5lib: 0.999_1 Installing py33-psycopg2: 2.5.3 * Installing py33-bleach: 1.4 Installing py33-pillow: 2.4.0 Installing py33-tzlocal: 1.1.1 * Installing py33-requests-oauthlib: 0.4.1 - Installing py33-django_compressor: 1.4 Installing py33-django: 1.6.5 - Installing py33-django-mezzanine3: 3.1.7 The installation will require 190 MB more space Let me know if you want a port www/py-mezzanine3 or upgrade existing. From the top of my head, at least www/py-flup is broken and one in the deps of virtualenvwrapper. -- Melvyn ___ 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: Apache 2.4 must become default NOW
On Mon, Jul 07, 2014 at 12:27:48AM +0200, olli hauer wrote: On 2014-07-05 19:09, Bjoern A. Zeeb wrote: Hi, given ports@ ist listed as maintainer, you get the email. The Subject says it. The world has moved on; in March I had a hard time arguing, in July I just cannot anymore. We must switch to 2.4; whatever breaks needs fixing, but somehow other distributions have managed and we did not and keep screwing our users missing a lot of security features. Please fix! — Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983 Hi Bjoern, nothing against this change, except your complain comes a little bit late. The portstree was already tagged for 9.3 some days ago so this change would be a possible issue for all users using the 9.3 packages. Before the default version can be changed a full expr. run by portmgr@ is required and all possible issues should be fixed. Unluckily we have a rolling ports tree (not like RHEL and others where such a change happens during new major releases) so there should be also a time frame to warn users about such a change. I remember endless discussions about the removal of apache13 after it was already deprecated nearly one year after upstream deprecation ... Just provide the patch for the change and warn the user about the change, now, just do not MFH it to the quarterly branch, so the user willing to keep apache22 for a while can live on the quarterly branch for the next 3 months :) I don't see the problem for the people using 9.3 packages, if they want stability they will stay on quarterly branch which still provides by default apache22 for 3 month. Hopefully when pkg 1.3 will land we will be able to add new feature to the ports tree aka build the apache module for all supported apache version leading to anyone using package being able to chose the apache version they what whatever the default is (but we are not there yet :)) regards, Bapt pgpS2f7aBgn2T.pgp Description: PGP signature
Re: Ports that don't actually support Python 3.x
On 7/07/2014 8:41 AM, Melvyn Sopacua wrote: Hi Kubilay! On Mon, 7 Jul 2014, Kubilay Kocak wrote: On 7/07/2014 7:52 AM, Melvyn Sopacua wrote: Submit an issue with patch, I'll add maintainer_approval flag cc'ing maintainer if you cant, just let me know the issue ID :) Thought I submitted more already, but they're still in the queue and django-redis was comitted. Will submit tomorrow. No such thing as too many issue reports, plus that way the maintainer will get to see it :) We also gotta decide what you wanna do with www/py-django-mezzanine. I'm happy to go for a straight upgrade rather than a version 2/3 split I've created a www/py-django-mezzanine3 locally, as I wasn't sure if 1.x was kept in tree for existing projects that cannot migrate. Finally got it working (read: installing) fully (* marks py3.x fixes, - marks fixes bringing the ports to py3.x): % pkg install www/py-django-mezzanine3 Updating repository catalogue The following 31 packages will be installed: Installing gettext: 0.18.3.1_1 Installing sqlite3: 3.8.5_1 Installing libxml2: 2.9.1_1 Installing openssl: 1.0.1_13 Installing png: 1.5.18 Installing jpeg: 8_5 Installing python33: 3.3.5_1 Installing py33-setuptools33: 5.1_1 Installing py33-pycrypto: 2.6.1 Installing py33-slimit: 0.8.1 Installing py33-six: 1.5.2 Installing py33-django-appconf: 0.6_1 Installing py33-beautifulsoup: 4.3.2 - Installing py33-django-mezzanine3-grappelli: 0.3.11 - Installing py33-django-mezzanine3-filebrowser: 0.3.4 Installing py33-sqlite3: 3.3.5_4 Installing postgresql91-client: 9.1.13_1 Installing freetype2: 2.5.3_2 Installing py33-pytz: 2014.4,1 Installing py33-south: 1.0 Installing py33-requests: 2.3.0 * Installing py33-oauthlib: 0.6.3 - Installing py33-html5lib: 0.999_1 Installing py33-psycopg2: 2.5.3 * Installing py33-bleach: 1.4 Installing py33-pillow: 2.4.0 Installing py33-tzlocal: 1.1.1 * Installing py33-requests-oauthlib: 0.4.1 - Installing py33-django_compressor: 1.4 Installing py33-django: 1.6.5 - Installing py33-django-mezzanine3: 3.1.7 The installation will require 190 MB more space Let me know if you want a port www/py-mezzanine3 or upgrade existing. From the top of my head, at least www/py-flup is broken and one in the deps of virtualenvwrapper. -- Melvyn If you're interested, feel free to create an Phabricator account (you can login via github twitter) so we can do the update together with review to save you time: https://phabric.freebsd.org/ Also, join us on freenode IRC (#freebsd-python) for real-time awesomeness -- Koobs ___ 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: Some suggestions about PKGNG documentation
On 07/05/14 03:18, Mike Brown wrote: Warren Block wrote: The documentation team has a standing offer to either assist with markup or accept content-only submissions and do the markup on them. That's good to know. I was under the impression it had to be submitted as DocBook XML. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsuXMbscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org OK. Its been 10 years since I lasted looked at the FBSD documents. Nowever, I know SGML, XML, and have written documents in them. 1. Point me to the source of one of the documents as a starting point. 2. Point me to the tools that I need to use to massage the document. (There used to be a Documenter's Handbook, is it still around?) I will take one of these documents as a starting point and then update it. HOWEVER... I am hoping that one of the document team will 'proof' this for format and content. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [Patch] Using MACHINE_ARCH identifiers in pkg
On 06/26/14 14:30, Baptiste Daroussin wrote: On Thu, Jun 19, 2014 at 10:22:30AM -0700, Nathan Whitehorn wrote: On 05/28/14 10:04, Baptiste Daroussin wrote: On Wed, May 28, 2014 at 09:54:03AM -0700, Nathan Whitehorn wrote: The following was in a deep and increasingly branched thread on the SVN list. I've forwarded the relevant part here. The discussion was on using MACHINE_ARCH codes for package architectures in pkg instead of the existing ones (which are equivalent) to make script-writing easier and improve consistency with the way the src and ports trees work. The patches below are designed to make transitioning the architecture identifiers as painless as possible. -Nathan I've written two patches today. The first (http://people.freebsd.org/~nwhitehorn/pkg_machinearch.diff) is to pkg itself and the second (http://people.freebsd.org/~nwhitehorn/pkg_bootstrap_machinearch.diff) is to the pkg bootstrapper in base. These switch pkg from using identifiers like freebsd:11:arm:32:eb:eabi:softfp to identifiers like FreeBSD:11:armeb, matching the canonical FreeBSD platform identifiers. The strings it uses can be predicted easily from scripts, as they are identical in all cases to the output of `uname -s`:`uname -r | cut -f 1 -d .`:`uname -p`. I tried to avoid changing much, so the patches are pretty short. Internally, the patch introduces a translation table to pkg that contains all extant FreeBSD and Dragonfly BSD architectures and moves between the ELF-based coding and MACHINE_ARCH values. This is kind of gross, but has the least possibility for regression, and can easily be changed behind the scenes later. Platform detection uses the same ELF-parsing code as before. The current/previous values are also kept so that the patched pkg can install a package marked either with an x86:64 or amd64-type architecture ID (symlinks will be needed for a little bit on the package server to allow both clients to work). Limited testing suggests it works well -- I can fetch and install packages fine. More testing would be great. One small issue is how to bootstrap the change for existing binary package users. The modified pkg can use packages with either architecture ID just fine, but the current one will barf on the FreeBSD:11:amd64 package containing its own update. There are a couple of options: manual instructions, marking that one package with the old-style architecture ID, etc. None should be more than slightly irritating, though. The least bumpy route, I think, is making directories with both the old and new names, but putting only one package in the old-named directory: a special intermediate version of pkg marked with the old architecture ID but able to install from the new one. Then you just have to deal with two rounds of updates without any other intervention, which is not so bad. -Nathan Thanks I'll be away for a couple of days, but I'll have a look and test your patch in all situation we need to support and come back to you if needed or directly commit; regards, Bapt Have you had a chance to look at this yet? I'm happy to help with any testing if you need. -Nathan I do like the appraoch but I haven't yet had time to study the side effect, it is already complicated to get pkg 1.3 out, I are quite close now so this will wait for 1.4, but I'll push it on top of my TODO list for 1.4. regards, Bapt Great, thanks! Any change of making some symlinks between the two schemes on pkg.freebsd.org in the meantime? That would make it easier to test the new code and should take only 30 seconds. -Nathan ___ 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
