Re: [CFT] Xorg 7.7 ready for testing!

2012-06-14 Thread Andreas Nilsson 
On Sun, Jun 10, 2012 at 1:17 PM, Andreas Nilsson  wrote:

>
>
> On Sun, Jun 10, 2012 at 11:13 AM, Ivan Klymenko  wrote:
>
>> В Sun, 10 Jun 2012 11:48:41 +0300
>> Alexander Yerenkow  пишет:
>>
>> > 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)

2012-06-14 Thread David Woodhouse 
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

2012-06-14 Thread Miroslav Lachman 

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 

  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

2012-06-14 Thread Baptiste Daroussin 
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

2012-06-14 Thread Ivan Klymenko 
В Thu, 14 Jun 2012 00:10:43 +0200
Baptiste Daroussin  пишет:

> 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

2012-06-14 Thread George Liaskos 
On Thu, Jun 14, 2012 at 1:10 AM, Baptiste Daroussin  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

2012-06-14 Thread Baptiste Daroussin 
On Thu, Jun 14, 2012 at 01:36:35PM +0300, George Liaskos wrote:
> On Thu, Jun 14, 2012 at 1:10 AM, Baptiste Daroussin  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

2012-06-14 Thread Ivan Klymenko 
В Thu, 14 Jun 2012 13:39:37 +0200
Baptiste Daroussin  пишет:

> On Thu, Jun 14, 2012 at 01:36:35PM +0300, George Liaskos wrote:
> > On Thu, Jun 14, 2012 at 1:10 AM, Baptiste Daroussin
> >  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

2012-06-14 Thread George Liaskos 
> 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

2012-06-14 Thread Jan Beich 
Andriy Gapon  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

2012-06-14 Thread Lowell Gilbert 
Lars Eighner  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't install irc/eggdrop

2012-06-14 Thread Beech Rintoul 
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)" 
> To: bug-follo...@freebsd.org
> Cc:  
> Subject: Re: ports/169054: Can'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 , but 
>  received no reply, has this port become unmaintained?
>  
>  --070204040909070603050005
>  Content-Type: text/html; charset=ISO-8859-1
>  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.
>  
>  
>   href="http://www.eggheads.org/news/2011/05/25/39";>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  href="mailto:be...@freebsd.org";>be...@freebsd.org,
>but received no reply, has this port become unmaintained?
>
>  
>  
>  --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

2012-06-14 Thread Kevin Oberman 
On Thu, Jun 14, 2012 at 6:22 AM, Lowell Gilbert
 wrote:
> Lars Eighner  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

2012-06-14 Thread Jason Helfman 
-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

mail/mailman install problem python 2.6 import urandom

2012-06-14 Thread Gene 
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  
from Mailman import Utils 
  File "/usr/local/mailman/Mailman/Utils.py", line 32, in  
import cgi 
  File "/usr/local/lib/python2.6/cgi.py", line 49, in  
import mimetools 
  File "/usr/local/lib/python2.6/mimetools.py", line 6, in  
import tempfile 
  File "/usr/local/lib/python2.6/tempfile.py", line 34, in  
from random import Random as _Random 
  File "/usr/local/lib/python2.6/random.py", line 47, in  
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

2012-06-14 Thread Doug Barton 
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

2012-06-14 Thread Doug Barton 
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"

Re: sanity-config issue

2012-06-14 Thread Andriy Gapon 
on 15/06/2012 07:55 Doug Barton said the following:
> 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.

You never explained why.  Perhaps, the time has come?
I personally do not see any problem with that setting.

-- 
Andriy Gapon


___
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"