Patches for Review (security/vpnc)
David, Could you take a look over the following attached patches and comments and make a consideration on these. Thanks. -- - (2^(N-1)) r2 | jh | 2012-06-14 01:14:16 -0400 (Thu, 14 Jun 2012) | 4 lines ASCII'fy the copyrights section. less(1) and other tools see it as binary. Index: vpnc-script === --- vpnc-script (revision 1) +++ vpnc-script (revision 2) @@ -1,8 +1,8 @@ #!/bin/sh # # Originally part of vpnc source code: -# © 2005-2012 Maurice Massar, Jörg Mayer, Antonio Borneo et al. -# © 2009-2012 David Woodhouse dw...@infradead.org +# (c) 2005-2012 Maurice Massar, Jörg Mayer, Antonio Borneo et al. +# (c) 2009-2012 David Woodhouse dw...@infradead.org # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by r3 | jh | 2012-06-14 01:25:31 -0400 (Thu, 14 Jun 2012) | 13 lines Adjust checking for if_tun to use kldstat(8) in place of /dev/tun /dev/tun is legacy usage and should be discouraged from further use. When sysctl net.link.tun.devfs_cloning=0 there is no /dev/tun device to probe. kldstat(8) and the current flags (-qm) for FreeBSD reach back to 7.X and possibly further, so invoke them. While here kldload if_tun.ko quietly (-q) See if_tun(4), kldstat(8), kldload(8) Index: vpnc-script === --- vpnc-script (revision 2) +++ vpnc-script (revision 3) @@ -593,12 +593,12 @@ fi fi elif [ $OS = FreeBSD ]; then - if [ ! -e /dev/tun ]; then - kldload if_tun + if ! kldstat -qm if_tun; then + kldload -q if_tun fi elif [ $OS = GNU/kFreeBSD ]; then - if [ ! -e /dev/tun ]; then - kldload if_tun + if ! kldstat -qm if_tun; then + kldload -q if_tun fi elif [ $OS = NetBSD ]; then : r4 | jh | 2012-06-14 01:42:30 -0400 (Thu, 14 Jun 2012) | 11 lines Interface creation and deletion should be handled directly by vpnc and return status should be handed back over to the script for negotiation. For now comment out the implicit tunnel deletion function until it can be reworked. Things to consider are possible legacy use cases net.link.tun.devfs_cloning but should not be depended on. Index: vpnc-script === --- vpnc-script (revision 3) +++ vpnc-script (revision 4) @@ -712,7 +712,7 @@ if [ -n $INTERNAL_IP4_DNS ]; then $RESTORERESOLVCONF fi - destroy_tun_device + #destroy_tun_device } Main pgp8weoFh0DnY.pgp Description: PGP signature
Proftpd mysql problem after upgrade ports
Hi, I have problem with this module. I upgraded ports and I have this
proftpd.conf
ServerName Servername
ServerType standalone
ServerIdent on Servers identifying string
DeferWelcomeon
DefaultServer on
UseIPv6 on
DefaultRoot ~
AllowOverwrite on
DisplayLogin.welcome# Textfile to display on login
DisplayConnect .connect# Textfile to display on
connection
UseReverseDNS off
IdentLookupsoff
Port21
Umask 022
MaxInstances15
MaxClientsPerHost 3 Only %m connections per host
allowed
MaxClients 10 Only %m total simultanious
logins allowed
MaxHostsPerUser 1
Usernobody
Group nobody
ScoreboardFile /var/log/scoreboard
# Some logging formats
LogFormat default %h %l %u %t \%r\ %s %b
LogFormat auth%v [%P] %h %t \%r\ %s
LogFormat write %h %l %u %t \%r\ %s %b
# Define log-files to use
#TransferLog/var/log/proftpd.xferlog
#ExtendedLog/var/log/proftpd.access_logWRITE,READ write
#ExtendedLog/var/log/proftpd.auth_log AUTH auth
#ExtendedLog/var/log/proftpd.paranoid_log ALL default
#SQLLogFile /var/log/proftpd.mysql
#QuotaLog /var/log/proftpd.quota
# Set up authentication via SQL
# ===
SQLEngine on
SQLAuthenticate on
AuthOrder mod_sql.c
SQLAuthTypesBackend
SQLConnectInfo proftpd_admin@localhost proftpd_admin pokus
SQLUserInfo usertable userid passwd uid gid homedir shell
SQLGroupInfogrouptable groupname gid members
SQLUserWhereClause disabled=0 and (NOW()=expiration or
expiration=-1 or expiration=0)
# Log the user logging in
SQLLog PASS counter
SQLNamedQuery counter UPDATE lastlogin=now(), count=count+1 WHERE userid='%u'
usertable
# logout log
SQLLog EXIT time_logout
SQLNamedQuery time_logout UPDATE lastlogout=now() WHERE userid='%u' usertable
# display last login time when PASS command is given
SQLNamedQuery login_time SELECT lastlogin from usertable where userid='%u'
SQLShowInfo PASS 230 Last login was: %{login_time}
# xfer Log in mysql
SQLLog RETR,STOR transfer1
SQLNamedQuery transfer1 INSERT '%u', '%f', '%b', '%h', '%a', '%m', '%T',
now(), 'c', NULL xfer_stat
SQLLOG ERR_RETR,ERR_STOR transfer2
SQLNamedQuery transfer2 INSERT '%u', '%f', '%b', '%h', '%a', '%m', '%T',
now(), 'i', NULL xfer_stat
# User quotas
# ===
#QuotaEngine on
#QuotaDirectoryTally on
#QuotaDisplayUnits Mb
#QuotaShowQuotas on
#SQLNamedQuery get-quota-limit SELECT name, quota_type, per_session,
limit_type, bytes_in_avail, bytes_out_avail, bytes_xfer_avail, files_in_avail,
files_out_avail, files_xfer_avail FROM ftpquotalimits WHERE name = '%{0}' AND
quota_type = '%{1}'
#SQLNamedQuery get-quota-tally SELECT name, quota_type, bytes_in_used,
bytes_out_used, bytes_xfer_used, files_in_used, files_out_used, files_xfer_used
FROM ftpquotatallies WHERE name = '%{0}' AND quota_type = '%{1}'
#SQLNamedQuery update-quota-tally UPDATE bytes_in_used = bytes_in_used + %{0},
bytes_out_used = bytes_out_used + %{1}, bytes_xfer_used = bytes_xfer_used +
%{2}, files_in_used = files_in_used + %{3}, files_out_used = files_out_used +
%{4}, files_xfer_used = files_xfer_used + %{5} WHERE name = '%{6}' AND
quota_type = '%{7}' ftpquotatallies
#SQLNamedQuery insert-quota-tally INSERT %{0}, %{1}, %{2}, %{3}, %{4}, %{5},
%{6}, %{7} ftpquotatallies
#QuotaLimitTable sql:/get-quota-limit
#QuotaTallyTable sql:/get-quota-tally/update-quota-tally/insert-quota-tally
AllowStoreRestart on
AllowRetrieveRestarton
RequireValidShell off
#PathDenyFilter \\.ftp)|\\.ht)[a-z]+$
DenyFilter \*.*/
Directory /ftp/*
AllowOverwrite off
HideNoAccessoff
Limit READ
AllowAll
/Limit
Limit WRITE
DenyGroup !admins
/Limit
/Directory
Directory /ftp/incoming/*
AllowOverwrite on
HideNoAccesson
Limit READ
DenyGroup !admins
/Limit
Limit STOR MKD
AllowAll
/Limit
/Directory
Before upgrade ports I had
proftpd-1.3.4a Highly configurable FTP daemon
proftpd-mod_sql_mysql-1.3.4a MySQL module for ProFTPD
and this config file
Re: [CFT] Xorg 7.7 ready for testing!
On Sun, Jun 10, 2012 at 1:17 PM, Andreas Nilsson andrn...@gmail.com wrote: On Sun, Jun 10, 2012 at 11:13 AM, Ivan Klymenko fi...@ukr.net wrote: В Sun, 10 Jun 2012 11:48:41 +0300 Alexander Yerenkow yeren...@gmail.com пишет: Is this fresh installation or you were upgrading? I'm preparing now live image with new xorg, and don't saw such errors. But I had yesterday's src/ports tree. Forgot to add - to svn r501 everything is fine build and working... I checked out the xorg repo yesterday and it built just fine ( on 9.0-RELEASE with drm-all.14.5-releng9.0.patch ). I actually did this in a clone of my root-dataset so I started with pkg_delete -a :) ) Just a thought: shouldn't the new intel driver be part of the OPTIONS of the new xorg-drivers? I'll write back with the results when I get back into the office. Regards So after upgrade to 9-stable xorg-7.7 starts just fine. Lets hope it keeps running. I would prefer to have xorg-7.7 becoming the default version of X, at least on 9 and above. And how does the nvidia binary blob work with xorg-7.7? Regards Andreas ___ 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: Patches for Review (security/vpnc)
These mostly look good; thanks. Please could I have each with a 'Signed-off-by:' tag? See the 'Submitting Patches' section of http://www.infradead.org/openconnect/contribute.html for more background on that (and exactly what you're agreeing to). On Thu, 2012-06-14 at 02:05 -0400, Jason Hellenthal wrote: r2 | jh | 2012-06-14 01:14:16 -0400 (Thu, 14 Jun 2012) | 4 lines ASCII'fy the copyrights section. less(1) and other tools see it as binary. I'd rather not do this; I'd rather you file bugs against the tools which see it as binary. We're over a decade into the 21st century now; ∄ excuse for still using EBCDIC, 7-bit ASCII or other legacy nonsense. Anyone who isn't operating a policy of everything on my system is UTF-8 as far as possible, converted from legacy crap on the way in and begrudgingly converted to legacy crap on the way out *only* if we really must is asking for trouble and mislabelled text. As long as this is only a cosmetic issue — and I think it is — I'd really prefer it to stay as it is. If it annoys someone with broken tools or who is living in the 20th century, then that's just fine by me ☺ Btw, I *would* accept patches to openconnect itself, to convert UTF-8 banners and prompts that we receive from the server into legacy crap for local display. You could still call that a cosmetic issue, I suppose, but it's an issue that actually affects the *user*, if they have a legacy local encoding and the server is giving non-ASCII in its prompts. r3 | jh | 2012-06-14 01:25:31 -0400 (Thu, 14 Jun 2012) | 13 lines Adjust checking for if_tun to use kldstat(8) in place of /dev/tun While here kldload if_tun.ko quietly (-q) Sounds good, and ISTR seeing a discussion in which it was confirmed that this worked when if_tun was built in to the kernel statically too? I'm going to defer entirely to you on the back to 7.x and possibly further bit, and assume that it's reasonable not to care if there are people with older systems on which this doesn't work? Changes here tend to get merged into upstream vpnc too, so if there's an ancient FreeBSD user who *does* happen to rebuild upstream vpnc for security fixes, perhaps it'll break for them? I'm fine with not caring about that if you (collectively, assuming my mail makes it to the ports@ list) are. r4 | jh | 2012-06-14 01:42:30 -0400 (Thu, 14 Jun 2012) | 11 lines Interface creation and deletion should be handled directly by vpnc and return status should be handed back over to the script for negotiation. Would be very nice if someone who knows the intimate details of FreeBSD tunnel devices could respond to my outstanding queries about this. If we can make the device go away automatically when its fd is closed, like we can on all other systems, that would be best. For now comment out the implicit tunnel deletion function until it can be reworked. I think we still need destroy_tun_device to run on NetBSD. Can you comment out just the FreeBSD part of the case statement in destroy_tun_device() instead? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: Proftpd mysql problem after upgrade ports
Radek Krejča wrote: Hi, I have problem with this module. I upgraded ports and I have this proftpd.conf You don't have a proper configuration. You need to put LoadModule directives in to proftpd.conf: # list of modules to load on startup LoadModule mod_sql.c LoadModule mod_sql_mysql.c It was mentioned in /usr/ports/UPDATING 20120126: AFFECTS: users of ftp/proftpd and ftp/proftpd-mysql AUTHOR: Martin Matuska m...@freebsd.org The proftpd port has been updated to 1.3.4 and changed to use dynamically loadable modules. Please add corresponding LoadModule directives to your configuration file, like in the following example: LoadModule mod_tls.c The modules mod_sql_mysql and mod_sql_postgres are now outside of the main proftpd port: databases/proftpd-mod_sql_mysql databases/proftpd-mod_sql_postgres The proftpd-mysql port has been removed, use the alternative port: databases/proftpd-mod_sql_mysql Before upgrade ports I had proftpd-1.3.4a Highly configurable FTP daemon proftpd-mod_sql_mysql-1.3.4a MySQL module for ProFTPD and this config file worked. After upgrade I have proftpd-1.3.4a_2Highly configurable FTP daemon proftpd-mod_sql_mysql-1.3.4a_2 MySQL module for ProFTPD and after starting I got this message: Fatal: unknown configuration directive 'SQLEngine' on line 43 of '/usr/local/etc/proftpd.conf' It looks like, that mod_sql isnt loaded, Compiled-in modules: mod_core.c mod_xfer.c mod_auth_unix.c mod_auth_file.c mod_auth.c mod_ls.c mod_log.c mod_site.c mod_delay.c mod_facts.c mod_dso.c mod_ident.c mod_auth_pam.c mod_ctrls.c mod_lang.c but I have compiled port proftpd with mod_sql (/var/db/ports/proftpd/options OPTIONS_FILE_SET+=SQL OPTIONS_FILE_SET+=SQL_PASSWD) Where could be a problem? I have fbsd 9.0 latest amd64 generic kernel. Thank you for any suggestion. Radek ___ 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: [CFT] UNIQUENAME patches
On Wed, Jun 13, 2012 at 04:21:16PM +0100, Matthew Seaman wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
* The way UNIQUENAME is defined means that it doesn't now change
depending on the version of python, ruby or apache installed on a
machine.
* UNIQUENAME will have changed for numerous ports -- consequently
port OPTIONFILEs may well have changed location. By default now,
each port should have an individual OPTIONFILE location. This
has removed a number of accidental cases of different (maybe
completely unrelated) ports sharing the same OPTIONSFILE.
* If you do want to share the same OPTIONSFILE between several
different ports, you can modify OPTIONSFILE directly or there is
now a new OPTIONS_DIR variable allowing a simple way for you to
override the location: OPTIONSFILE is redefined as:
OPTIONSFILE= ${PORT_DBDIR}/${OPTIONS_DIR}/options
with OPTIONS_DIR defaulting (as before) to UNIQUENAME unless
overriden. See databases/postgresql91-server for an example.
* Other things that may be affected: ports with USE_LDCONFIG or
USE_LDCONFIG32 can have ldconfig data written to a different
location. This shouldn't make any user-visible change.
Per-port options settings (OPTIONSng-style) in /etc/make.conf
may need to be modified.
Please test. Comments, corrections and bug reports will be most welcome.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
Thank you very much for the patch, it solves a problem that sticks for way too
long in the ports tree: the problem with options files.
It also solve another problem which is really important when dealing with binary
packages and will allow to simplify the life of pkgng development: we would for
real get a unique identifier for a package!!!, before for we were workarounding
the problem considering origin as our unique identifier which worked but no
that good, it was hard to track a package which was moved (no MOVED isn't an
ideal solution to track them in full binary world)
The other thing that it could solve for binary only world if that if people from
python ruby perl and others uses always the same uniquename for their default
version, then it will be easy to move from python26 as a default to python27 as
a default in full binary environment with no manual intervention from the user
and no complex hacks to figure it out in the package tool.
Last but no least once it is done the LATEST_LINK overwrite could die, and the
feature associated could just use LATEST_LINK.
Please do test this patch comment on it and improve it.
regards,
Bapt
pgpWyWRLAcZp0.pgp
Description: PGP signature
Re: pkg is segmentation fault with of the cross-compile port
В Thu, 14 Jun 2012 00:10:43 +0200
Baptiste Daroussin b...@freebsd.org пишет:
On Wed, Jun 13, 2012 at 10:17:45PM +0300, Ivan Klymenko wrote:
Hi all!
I building the packages of ports in the chroot system FreeBSD 9.0
i386 the parent system FreeBSD 9.0 amd64.
pkg is segmentation fault in port devel/libtool.
full trace obtained a pkg.core file is here
http://privatepaste.com/2c66b1204f
ports tree in a chroot - updated today
Thanks.
___
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
Wow strange I did a lot of tests in chroot for building ports (i386
chroot on amd64 host) and it always work like a charm.
The failure you have also seems to come from a -a argument of pkg
register which is unused and will disappear from next version of
pkgng.
Can you send the the manifest (should in the
${WORKDIR}/.metadir/+MANIFEST please?
regards,
Bapt
name: libtool
version: 2.4.2
origin: devel/libtool
comment: |
Generic shared library support script
maintainer: autoto...@freebsd.org
prefix: /usr/local
deps:.
categories: [devel,]
licenselogic: single
licenses: [GPLv2,]
users: []
groups: []
options: {}
+MANIFEST
Description: Binary data
___
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: pkg is segmentation fault with of the cross-compile port
On Thu, Jun 14, 2012 at 1:10 AM, Baptiste Daroussin b...@freebsd.org wrote:
On Wed, Jun 13, 2012 at 10:17:45PM +0300, Ivan Klymenko wrote:
Hi all!
I building the packages of ports in the chroot system FreeBSD 9.0 i386
the parent system FreeBSD 9.0 amd64.
pkg is segmentation fault in port devel/libtool.
full trace obtained a pkg.core file is here
http://privatepaste.com/2c66b1204f
ports tree in a chroot - updated today
Thanks.
___
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
Wow strange I did a lot of tests in chroot for building ports (i386 chroot on
amd64 host) and it always work like a charm.
The failure you have also seems to come from a -a argument of pkg register
which
is unused and will disappear from next version of pkgng.
Can you send the the manifest (should in the ${WORKDIR}/.metadir/+MANIFEST
please?
regards,
Bapt
I have reported the same a while ago, the backtrace seems identical.
https://groups.google.com/group/mailing.freebsd.ports/browse_thread/thread/191ec99e36fb2536/bd8719c3370e98e7?show_docid=bd8719c3370e98e7
Regards,
George
___
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: pkg is segmentation fault with of the cross-compile port
On Thu, Jun 14, 2012 at 01:36:35PM +0300, George Liaskos wrote:
On Thu, Jun 14, 2012 at 1:10 AM, Baptiste Daroussin b...@freebsd.org wrote:
On Wed, Jun 13, 2012 at 10:17:45PM +0300, Ivan Klymenko wrote:
Hi all!
I building the packages of ports in the chroot system FreeBSD 9.0 i386
the parent system FreeBSD 9.0 amd64.
pkg is segmentation fault in port devel/libtool.
full trace obtained a pkg.core file is here
http://privatepaste.com/2c66b1204f
ports tree in a chroot - updated today
Thanks.
___
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
Wow strange I did a lot of tests in chroot for building ports (i386 chroot
on
amd64 host) and it always work like a charm.
The failure you have also seems to come from a -a argument of pkg register
which
is unused and will disappear from next version of pkgng.
Can you send the the manifest (should in the ${WORKDIR}/.metadir/+MANIFEST
please?
regards,
Bapt
I have reported the same a while ago, the backtrace seems identical.
https://groups.google.com/group/mailing.freebsd.ports/browse_thread/thread/191ec99e36fb2536/bd8719c3370e98e7?show_docid=bd8719c3370e98e7
Regards,
George
___
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
Oh, I missed that one, in your case it is not running in a chroot, is it?
strange is that I'm able to build 9.0-RELEASE i386 packages on pointyhat...
regards,
Bapt
pgpokB8ERuVia.pgp
Description: PGP signature
Re: pkg is segmentation fault with of the cross-compile port
В Thu, 14 Jun 2012 13:39:37 +0200
Baptiste Daroussin b...@freebsd.org пишет:
On Thu, Jun 14, 2012 at 01:36:35PM +0300, George Liaskos wrote:
On Thu, Jun 14, 2012 at 1:10 AM, Baptiste Daroussin
b...@freebsd.org wrote:
On Wed, Jun 13, 2012 at 10:17:45PM +0300, Ivan Klymenko wrote:
Hi all!
I building the packages of ports in the chroot system FreeBSD
9.0 i386 the parent system FreeBSD 9.0 amd64.
pkg is segmentation fault in port devel/libtool.
full trace obtained a pkg.core file is here
http://privatepaste.com/2c66b1204f
ports tree in a chroot - updated today
Thanks.
___
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
Wow strange I did a lot of tests in chroot for building ports
(i386 chroot on amd64 host) and it always work like a charm.
The failure you have also seems to come from a -a argument of pkg
register which is unused and will disappear from next version of
pkgng.
Can you send the the manifest (should in the
${WORKDIR}/.metadir/+MANIFEST please?
regards,
Bapt
I have reported the same a while ago, the backtrace seems identical.
https://groups.google.com/group/mailing.freebsd.ports/browse_thread/thread/191ec99e36fb2536/bd8719c3370e98e7?show_docid=bd8719c3370e98e7
Regards,
George
___
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
Oh, I missed that one, in your case it is not running in a chroot, is
it? strange is that I'm able to build 9.0-RELEASE i386 packages on
pointyhat...
regards,
Bapt
I'm sorry, but I forgot to add that I did build ports with the option
WITH_PKGNG=yes in /etc/make.conf
___
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: pkg is segmentation fault with of the cross-compile port
Oh, I missed that one, in your case it is not running in a chroot, is it? It's not, it's a vm under vbox. ___ 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: sanity-config issue
Andriy Gapon a...@freebsd.org writes:
In some ports I am getting an error message about how make doesn't know how to
make sanity-config after exiting from config menu.
I see that there is
@${MAKE} sanity-config
line at the end of the config target script.
I use WRKDIRPREFIX=/usr/obj and I noticed that e.g. in the case of
mail/thunderbird port the make command was being run from
/usr/obj/usr/ports/mail/thunderbird.
My workaround was to prepend cd ${.CURDIR}; before the make command.
I see that this is a popular theme in bsd.port.mk, but I am not sure why it is
needed and if my workaround is actually correct.
I can confirm your workaround also works for broken fetch-url{,all}-list
target when MAKEOBJDIRPREFIX and WRKDIPREFIX share directory, e.g.
$ cd devel/gmake
$ env -i make fetch-urlall-list
http://ftp.gnu.org/gnu/make/make-3.82.tar.bz2
ftp://ftp.gnu.org/gnu/make/make-3.82.tar.bz2
http://www.gtlib.gatech.edu/pub/gnu/gnu/make/make-3.82.tar.bz2
http://mirrors.kernel.org/gnu/make/make-3.82.tar.bz2
ftp://ftp.kddlabs.co.jp/GNU/make/make-3.82.tar.bz2
ftp://ftp.dti.ad.jp/pub/GNU/make/make-3.82.tar.bz2
http://ring.nict.go.jp/archives/GNU/make/make-3.82.tar.bz2
ftp://ftp.mirrorservice.org/sites/ftp.gnu.org/gnu/make/make-3.82.tar.bz2
ftp://ftp.informatik.hu-berlin.de/pub/gnu/gnu/make/make-3.82.tar.bz2
ftp://ftp.informatik.rwth-aachen.de/pub/mirror/ftp.gnu.org/pub/gnu/make/make-3.82.tar.bz2
http://ftp.funet.fi/pub/gnu/prep/make/make-3.82.tar.bz2
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/make-3.82.tar.bz2
$ mkdir -p $(env -i WRKDIRPREFIX=/tmp make -V WRKDIR)
$ env -i MAKEOBJDIRPREFIX=/tmp make fetch-urlall-list
make: don't know how to make fetch-url-list-int. Stop
*** [fetch-urlall-list] Error code 2
Stop in /usr/ports/devel/gmake.
Hope that this is useful.
___
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: Xscreensaver conflicts
Lars Eighner portsu...@larseighner.com writes: xscreensaver-gnome-hacks will not install if xscreensaver is installed (write files to the same place) gnome requires xscreensaver-gnome-hacks kde4 requires xscreensaver It appears to me that if you force pkg_delete of xscreensaver and install xscreensaver-gnome-hacks first, you can reinstall xscreensaver without complaints. I grepped UPDATING for xscreensaver without any hits and do not find this documented. I suspect the conflicts line in the Makefile xscreensave-gnome-hacks is not accurate. The pkg-plist files have a number of common entries, so my suspicion would be the opposite; that xscreensaver ought to have a corresponding CONFLICTS line. Gnome can be configured (by an option) to use xscreensaver, if I'm reading the Makefile correctly. ___ 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/169054: Can#39;t install irc/eggdrop
On 6/14/2012 10:30 AM, James Wade (Phurix) wrote: The following reply was made to PR ports/169054; it has been noted by GNATS. From: James Wade (Phurix) james.w...@phurix.co.uk To: bug-follo...@freebsd.org Cc: Subject: Re: ports/169054: Can#39;t install irc/eggdrop Date: Thu, 14 Jun 2012 19:05:34 +0100 This is a multi-part message in MIME format. --070204040909070603050005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The bigger issue here is the SSL patch, it's unofficial. The advise from the vendor is that using SSL patches are a bad idea. http://www.eggheads.org/news/2011/05/25/39 Instead the port should switch to eggdrop1.8-snapshot (development but, supports SSL) or eggdrop1.6.20 (latest but, no SSL support). I tried to contact be...@freebsd.org mailto:be...@freebsd.org, but received no reply, has this port become unmaintained? --070204040909070603050005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit html head meta http-equiv=content-type content=text/html; charset=ISO-8859-1 /head body bgcolor=#FF text=#00 The bigger issue here is the SSL patch, it's unofficial. divbr /div divThe advise from the vendor is that using SSL patches are a bad idea./div divbr /div diva href=http://www.eggheads.org/news/2011/05/25/39;http://www.eggheads.org/news/2011/05/25/39/a /div divbr /div divInstead the port should switch to eggdrop1.8-snapshot (development but, supports SSL) ornbsp;eggdrop1.6.20 (latest but,nbsp;no SSL support)./div divbr /div divI tried to contact a href=mailto:be...@freebsd.org;be...@freebsd.org/a, but received no reply, has this port become unmaintained?/div /body /html --070204040909070603050005-- I have ported 1.8 to irc/eggdrop-devel. I will update the other to 1.6.21 and drop the rooty patch. Upstream has discontinued all support for the patch as it's very buggy. If you need ssl support try the -devel version. Comments are welcome. Beech -- --- Beech Rintoul - FreeBSD Developer - be...@freebsd.org /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://www.freebsd.org X - NO Word docs in e-mail | Latest Release: / \ - http://www.FreeBSD.org/releases/9.0R/announce.html --- ___ 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: Xscreensaver conflicts
On Thu, Jun 14, 2012 at 6:22 AM, Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org wrote: Lars Eighner portsu...@larseighner.com writes: xscreensaver-gnome-hacks will not install if xscreensaver is installed (write files to the same place) gnome requires xscreensaver-gnome-hacks kde4 requires xscreensaver It appears to me that if you force pkg_delete of xscreensaver and install xscreensaver-gnome-hacks first, you can reinstall xscreensaver without complaints. I grepped UPDATING for xscreensaver without any hits and do not find this documented. I suspect the conflicts line in the Makefile xscreensave-gnome-hacks is not accurate. The pkg-plist files have a number of common entries, so my suspicion would be the opposite; that xscreensaver ought to have a corresponding CONFLICTS line. Gnome can be configured (by an option) to use xscreensaver, if I'm reading the Makefile correctly. You are right. You may not install both xscreensaver and xscreensaver-gnome-hacks. By default, gnome uses xscreensaver-gnome which pulls in xscreensaver-gnome-hacks. xscreensaver and xscreensaver-gnome-hacks should both declare the other as CONFLICTs. They are slightly different flavors of the same thing. This really should have been sent to gnome@. The folks there would have probably confimed the situation immediately and, if they have a commit bit, might have fixed it. Please open a PR for this so it will be fixed. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@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: [CFT] UNIQUENAME patches
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Jun 14, 2012 at 10:14:52AM +0200, Baptiste Daroussin thus spake:
On Wed, Jun 13, 2012 at 04:21:16PM +0100, Matthew Seaman wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
* The way UNIQUENAME is defined means that it doesn't now change
depending on the version of python, ruby or apache installed on a
machine.
* UNIQUENAME will have changed for numerous ports -- consequently
port OPTIONFILEs may well have changed location. By default now,
each port should have an individual OPTIONFILE location. This
has removed a number of accidental cases of different (maybe
completely unrelated) ports sharing the same OPTIONSFILE.
* If you do want to share the same OPTIONSFILE between several
different ports, you can modify OPTIONSFILE directly or there is
now a new OPTIONS_DIR variable allowing a simple way for you to
override the location: OPTIONSFILE is redefined as:
OPTIONSFILE= ${PORT_DBDIR}/${OPTIONS_DIR}/options
with OPTIONS_DIR defaulting (as before) to UNIQUENAME unless
overriden. See databases/postgresql91-server for an example.
* Other things that may be affected: ports with USE_LDCONFIG or
USE_LDCONFIG32 can have ldconfig data written to a different
location. This shouldn't make any user-visible change.
Per-port options settings (OPTIONSng-style) in /etc/make.conf
may need to be modified.
Please test. Comments, corrections and bug reports will be most welcome.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
Thank you very much for the patch, it solves a problem that sticks for way too
long in the ports tree: the problem with options files.
It also solve another problem which is really important when dealing with
binary
packages and will allow to simplify the life of pkgng development: we would for
real get a unique identifier for a package!!!, before for we were workarounding
the problem considering origin as our unique identifier which worked but no
that good, it was hard to track a package which was moved (no MOVED isn't an
ideal solution to track them in full binary world)
The other thing that it could solve for binary only world if that if people
from
python ruby perl and others uses always the same uniquename for their default
version, then it will be easy to move from python26 as a default to python27 as
a default in full binary environment with no manual intervention from the user
and no complex hacks to figure it out in the package tool.
Last but no least once it is done the LATEST_LINK overwrite could die, and the
feature associated could just use LATEST_LINK.
Please do test this patch comment on it and improve it.
regards,
Bapt
Great patch. I've done some testing, but was aware of this issue, and even
have raised this with bapt during his implementation of optionsng to see if
he knew of this issue.
From what I can see, this also takes care of this PR, but also adds some
needed consistency that has long been removed.
And by looking up the pr, I see you already have found it :)
mail/mailman install problem python 2.6 import urandom
Hi All: Running 8.1 AMD64. I had python 2.6.8 installed. After upgrading several ports, which installed python 2.7.3_2, scripts requiring 2.6 fail due to an inability to import urandom from os. Now I'm not a python person by any means, but I was wondering where its trying to find urandom. Could it be looking for 'dev/urandom'? Or perhaps urandom from ports/math/mpc? In a few scripts I've changed 2.6 to 2.7 and they seem to work. Did installing 2.7 alongside 2.6 break something? Specifically, right now I'm trying to install mail/mailman port which looks for python 2.6. It terminates with the following: Compiling /usr/local/mailman/Mailman/versions.py ... Traceback (most recent call last): File bin/update, line 50, in module from Mailman import Utils File /usr/local/mailman/Mailman/Utils.py, line 32, in module import cgi File /usr/local/lib/python2.6/cgi.py, line 49, in module import mimetools File /usr/local/lib/python2.6/mimetools.py, line 6, in module import tempfile File /usr/local/lib/python2.6/tempfile.py, line 34, in module from random import Random as _Random File /usr/local/lib/python2.6/random.py, line 47, in module from os import urandom as _urandom ImportError: cannot import name urandom = I've googled and searched archives and all I can find is ubuntu problems related to a virtual machine. Does anyone know what's going on? Thanks, Gene -- ___ 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: sanity-config issue
On 06/14/2012 05:48, Jan Beich wrote: I use WRKDIRPREFIX=/usr/obj As I've mentioned to you a non-zero number of times, this is a bad idea. The fact that it either works and/or can be made to work sometimes, notwithstanding. -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sanity-config issue
On 06/14/2012 21:55, Doug Barton wrote: On 06/14/2012 05:48, Jan Beich wrote: I use WRKDIRPREFIX=/usr/obj As I've mentioned to you ... where you == Andriy. a non-zero number of times, this is a bad idea. The fact that it either works and/or can be made to work sometimes, notwithstanding. -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
