Re: Should a package restart on upgrade itself
On Wed, Jun 27, 2018, at 8:56 AM, Mathieu Arnold wrote: > On Wed, Jun 27, 2018 at 08:10:00AM -0500, Matthew D. Fuller wrote: > > On Wed, Jun 27, 2018 at 11:58:17AM +0200 I heard the voice of > > Mathieu Arnold, and lo! it spake thus: > > > > > > Please point out to ports doing this so that they can be fixed. > > > > On the "irritates me from time to time" list, > > > > https://svnweb.freebsd.org/ports/head/mail/spamassassin/pkg-plist?revision=425590&view=markup#l1 > > Found a bunch of those, fixed them in r473439. > > -- > Mathieu Arnold > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) So the consensus is to change open-vm-tools so it doesn't autorestart? -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Should a package restart on upgrade itself
On Tue, Jun 26, 2018, at 6:27 AM, Miroslav Lachman wrote: > Miroslav Lachman wrote on 2017/06/27 19:32: > > Matthias Fechner wrote on 2017/06/27 18:29: > >> Dear all, > >> > >> it is always a pain if pkg upgrade a lot of packages to restart all > >> services to make sure update/security fixes are applied to all running > >> services. > >> > >> Is there an option in pkg that it restart services automatically or is > >> it OK if I would add a post-install script to the packages (I maintain) > >> that will include a "service foo restart"? > >> > >> What is best practice here? > > > > Please don't do this. > > Some ports did this in the past and this was really a pain during larger > > upgrades. It sometimes leave services stopped (hi MySQL). > > > > The same bad practice is disabling / enabling Apache modules on upgrade. > > > > pkg upgrade should just do it's work - upgrade packages on disk. But > > manipulating config files and restart of services is up to me - the > > Administrator (or my tools). > > > > It would be nice to have some kind of "hooks" in pkg, which can be used > > to notify deployment tools that some services should be (re)started, or > > do restart in some simpler environment if user allows this (setup hooks > > for service restart). > > But is must not be done automatically for individual ports / packages > > even if maintainer thinks it is Good Idea (tm) > > Again and again and again... > > Can we have some written (or do we have?) policy to not > stop/start/restart services from some @preunexec / @postexec targets? > I really don't like that some packages are still shutting down or trying > to restart in the middle of the pkg upgrade process. > > One example from today upgrade: > > [87/96] Extracting open-vm-tools-nox11-10.2.5,2: .. done > Stopping vmware_guestd. > Waiting for PIDS: 516. > Loading vmmemctl kernel module: already loaded. > vmware_guestd not running? (check /var/run/vmware_guestd.pid). > Starting vmware_guestd. > > Can committers take care of this bad behaviour and not commit things > like this? > https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?revision=457485&view=markup > > @preunexec %%PREFIX%%/bin/vmware-rpctool 'tools.set.version 0' ; service > vmware-guestd stop 2>/dev/null || /usr/bin/true > @postexec service vmware-kmod restart && service vmware-guestd restart > || /usr/bin/true > > Kind regards > Miroslav Lachman > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" Here's the diff for the commit you referenced: https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?r1=457023&r2=457485&pathrev=457485 Which part are you objecting to? I don't really have any objections to changing open-vm-tools. I'll note that I inherited it in it's current state with regards to defaults and restarting, an it's probably worth fining out why it does those things before blatantly changing things. It's possible that open-vm-tools is a poor example of what you are talking about based on it providing services for the OS for running on VMWare versus running some application service or daemon , but I will have to think about this before taking a strongly held opinion. -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: net/viamillipede seeks commiter
On Tue, Mar 6, 2018, at 10:19 AM, Mathieu Arnold wrote: > On Tue, Mar 06, 2018 at 07:34:39AM -0500, Ash Gokhale wrote: > > gcc. Would you all try it again please? > > https://github.com/agokhale/freebsd-port-net-viamillipede/commits/master > > > > Add to the top block DISTVERSIONPREFIX=v and change the version to 0.7. > > Remove MASTER_SITES. > > Remove GH_TAGNAME= v0.7 > > BINS seems to not be used, remove it. > > pkg-descr needs a big cleanup. > > -- > Mathieu Arnold > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) It looks like all the changes suggested have been done, both poudriere and portlint are happy. If there are no objections I'll commit this tonight. -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: net/viamillipede seeks commiter
On Sun, Mar 4, 2018, at 10:58 AM, Josh Paetzel wrote:
>
>
> On Sat, Mar 3, 2018, at 12:51 PM, Kurt Jaeger wrote:
> > Hi!
> >
> > > Nope -this is a new tool; the other stuff was fpga porting for
> > > cad/icestorm.
> >
> > I have something buildable, but it fails on FreeBSD 10:
> >
> > ===> Building for viamillipede-1.0
> > make[1]: "/usr/share/mk/bsd.own.mk" line 505: MK_DEBUG_FILES can't be
> > set by a user.
> >
> > --
> > p...@opsec.eu+49 171 3101372 2 years to
> > go !
>
> I get a different failure on 10.4 using poudriere:
>
> --- rx.o ---
> rx.c:182:14: error: expected ')'
> (void *(* _Nonnull)(void *))&rxworker,
> ^
> rx.c:182:11: note: to match this '('
> (void *(* _Nonnull)(void *))&rxworker,
>^
> 1 error generated.
> --- tx.o ---
> tx.c:317:14: error: expected ')'
> (void *(* _Nonnull)(void *))&txworker_sm,
> ^
> tx.c:317:11: note: to match this '('
> (void *(* _Nonnull)(void *))&txworker_sm,
>^
> 1 error generated.
> *** [tx.o] Error code 1
>
> I have a small Makefile patch I'll send as a pull request to satisfy portlint.
>
> --
>
> Thanks,
>
> Josh Paetzel
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Promised pull request sent.
Still doesn't compile on 10.4. I'm assuming gcc is at fault.
https://github.com/agokhale/freebsd-port-net-viamillipede/pull/1
--
Thanks,
Josh Paetzel
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: net/viamillipede seeks commiter
On Sat, Mar 3, 2018, at 12:51 PM, Kurt Jaeger wrote:
> Hi!
>
> > Nope -this is a new tool; the other stuff was fpga porting for cad/icestorm.
>
> I have something buildable, but it fails on FreeBSD 10:
>
> ===> Building for viamillipede-1.0
> make[1]: "/usr/share/mk/bsd.own.mk" line 505: MK_DEBUG_FILES can't be
> set by a user.
>
> --
> p...@opsec.eu+49 171 3101372 2 years to
> go !
I get a different failure on 10.4 using poudriere:
--- rx.o ---
rx.c:182:14: error: expected ')'
(void *(* _Nonnull)(void *))&rxworker,
^
rx.c:182:11: note: to match this '('
(void *(* _Nonnull)(void *))&rxworker,
^
1 error generated.
--- tx.o ---
tx.c:317:14: error: expected ')'
(void *(* _Nonnull)(void *))&txworker_sm,
^
tx.c:317:11: note: to match this '('
(void *(* _Nonnull)(void *))&txworker_sm,
^
1 error generated.
*** [tx.o] Error code 1
I have a small Makefile patch I'll send as a pull request to satisfy portlint.
--
Thanks,
Josh Paetzel
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: net/viamillipede seeks commiter
> On Mar 3, 2018, at 9:02 AM, Ash Gokhale wrote: > > Thanks for eyes on this. I want a minimal makefile; cc -lpthread *.c would > probably build it. I'm not sure what the right direction is but I'll spin up > poudrire and look up the USES=uidfix . > >> On Sat, Mar 3, 2018 at 3:06 AM, Kurt Jaeger wrote: >> Hi! >> >> > > > > install: >> > > > > /wrkdirs/usr/ports/net/viamillipede/work/stage/usr/local/bin/viamillipede: >> > > > > chown/chgrp: Operation not permitted >> [...] >> > We have USES=uidfix for this. >> >> Thanks, works. >> >> -- >> p...@opsec.eu+49 171 3101372 2 years to >> go ! > Didn’t I run this through poudriere already? Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Call for testing VMware open-vm-tools update
VMware has been contributing to making FreeBSD a first class citizen for their open source vmware tools. As a continuing part of this contribution there's a new version of open-vm-tools in the works. The INO64 work in FreeBSD HEAD broke building open-vm-tools for HEAD/i386, and there was a kernel panic that affected HEAD/amd64. That has been addressed and vmware has started QA for the tools for FreeBSD 11.1-R and 10.3-R amd64 and i386. I've given this update a fair amount of testing and it gets a "works on my machine" certification from me. The new version is available as a port at https://people.freebsd.org/~jpaetzel/open-vm-tools.tar.gz . Feel free to give it a spin and please report any issues by filing a bug at https://bugs.freebsd.org/ If you tag the bug you create as ports emulators/open-vm-tools it will get auto-assigned to me. -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: net/samba41 port compiles nmbd as a shared object, not executable
On 05/10/2014 05:47, Timur I. Bakeyev wrote: > > Ok, nice to know this. As I understand, iXsystems now fully moved to > Samba 4.1? > Yes. > I those thinking, guys, that you may wanted to create at the top of > FreeNAS Samba4 appliance, similar to the one, provided by SerNet, only > FreeBSD based. So, it can act as a Windows AD replacement in certain > environments. In general, we have everything in ports to make the one. > That's been available since FreeNAS 9.2.1.1 :) > With best regards, > Timur Bakeyev. -- Thanks, Josh Paetzel Director of IT, iXsystems Servers For Open Source http://www.ixsystems.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: Superfluous dependencies
On Thursday, March 10, 2011 03:28:40 am Hans Ottevanger wrote: > On Tue, Mar 8, 2011 at 3:51 PM, Michael Scheidell > > wrote: > > On 3/8/11 4:42 AM, Hans Ottevanger wrote: > >> One of them that I already hunted down is bison-2.4.3,1 that gets > >> dragged in via gobject-introspection-0.9.12_1 when installing > >> xorg-7,5.1 (even as a package). This is caused by bison specified as a > >> dependency of type "both" in the port Makefile of > >> gobject-introspection where it should be specified as "build". I don't > >> think that Bison is used on run-time here and most likely not even on > >> build- time. > > FWIW, I was just investigating why bison made it into a embedded device I'm working on, and if you look at the sources for gobject-introspection, there is actually a code path where bison is used at run time. While it seems unlikely it would be used, it is technically a runtime depend. -- Thanks, Josh Paetzel signature.asc Description: This is a digitally signed message part.
Re: xorg-server 1.7.7
On Monday, November 15, 2010 04:51:36 am Tijl Coosemans wrote: > On Sunday 14 November 2010 23:02:42 Josh Paetzel wrote: > > Area51 is quite cloneable it terms of infrastructure and what not. We > > could very easily provide an SVN repo for experimental xoeg work. > > It would be better if there was a repo for ports development on the > FreeBSD servers. There are several projects now that could use this > that I think this is warranted. It would increase their visibility and > lower the barrier to entry to attract contributors and testers. > > It doesn't have to be anything complicated. An SVN repo that tracks CVS > and on which ports committers can create project branches would be > enough. While conceptually that sounds very simple, an SVN repo that tracks a CVS repo is very complicated. One of the most complicated parts of the FreeBSD src repo being in SVN is the SVN -> CVS exporter. The main issue is there are operations that don't map 1:1 across both repos that have to be dealt with by hand. I wasn't proposing that, I think area51 is just a place to check in experimental ports. The merge back to FreeBSD has to be done by hand. The main difference to me is by running it on a PC-BSD infrastructure box I can just set it up today and have it running and usable in a few hours. Punting it back to the FreeBSD projectby the time it's all sorted and up and running it will be spring of 2011. :) -- Thanks, Josh Paetzel Director of IT, iXsystems Servers For Open Source http://www.ixsystems.com signature.asc Description: This is a digitally signed message part.
Re: xorg-server 1.7.7
Area51 is quite cloneable it terms of infrastructure and what not. We could very easily provide an SVN repo for experimental xoeg work. Thanks, Josh Paetzel On Nov 14, 2010, at 3:00 PM, Kris Moore wrote: > > > > > On Sun 14/11/10 3:44 PM , Anonymous wrote: > >> Kris Moore writes: >>> On Sun, Nov 14, 2010 at 12:24:44PM -0700, Warren Block wrote: >>>> On Sun, 14 Nov 2010, Andriy Gapon wrote: >>>> >>>>> on 14/11/2010 18:18 Warren Block said the following: >>>>>> On Sat, 13 Nov 2010, Andriy Gapon wrote: >>>>>> >>>>>>> I agree, but I am not sure how in the ports land we do an >> application testing in >>>>>>> general. That is, I am sure there will be a lot of testers if >> the port update >>>>>>> is actually committed :-) but I am not sure how to test it in >> advance (given all >>>>>>> the possible hardware and software configurations). >>>>>> >>>>>> Why not just create a new xorg-server177 or xorg-server-devel >> port as has been >>>>>> done with other ports? >>>>> >>>>> Would it be really worth it? >>>>> 1.7.7 is just couple of minor releases ahead of what we have now >> and the latest >>>>> _release_ is 1.9.2. >>>>> So, xorg-server-devel for 1.9.2 - that would make sense for my >> taste. >>>>> xorg-server-devel for 1.7.7 - just an overcautiousness and, IMO, >> a waste of >>>>> resources. >>>> >>>> It would depend on how compatible the newer server is with the >> existing >>>> xorg ports. But sure, go with the newest one that still works. >>>> >>>> If these ports are too shaky for normal users, they wouldn't even >> have >>>> to go in the tree. Put them on a web page somewhere. But this >> would >>>> ast least allow a wider range of testing. >>> >>> Does the xorg porting team have a repo somewhere for port work, ala >> area51 >>> for KDE4? If not, would setting one up be of interest to people >> here? That >>> probably be a service we could easily provide, since we are >> particularly >>> attached to having a working Xorg ;) >> It has one >> http://wiki.freebsd.org/ModularXorg/7.5 >> Not sure about previous major updates. With history scattered across >> several development repos[*] it can be quite hard to track. >> [*] no one uses branches in ports tree (shuns CVS?) >> >> > > Are those SVN services still in use? Looking at the http links on that page I > assumed it was old and no longer usable. > > -- > Kris Moore > PC-BSD / iXsystems > > Message sent via Atmail Open - http://atmail.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"
isc-dhcp updates and call for testing
I have patches that update the isc-dhcp30 and isc-dhcp-31 ports. isc-dhcp30 incorporates patches from Ubuntu to address a security advisory released against it. Since it is no longer maintained upstream nothing official will be released. If you wish to follow a maintained version, I have patches that update isc-dhcp31 to the latest version that addresses the security issues that were recently discovered. These patches could use testing beyond what I can mock up locally. If you try them out I could use feedback, whether good or bad. The patches to isc-dhcp30 will probably be committed tomorrow. I'd like to wait a bit to get feedback on the isc-dhcp31 patches, also the rcNG script will probably be updated a bit from what is in the patches to provide stylistic, but not functional improvements. isc-dhcp30* http://www.freebsd.org/cgi/query-pr.cgi?pr=136891 isc-dhcp31* http://www.freebsd.org/cgi/query-pr.cgi?pr=136890 I am planning on getting a 4.0.x and 4.1.x port going soon as well, hopefully by this weekend. Thanks, Josh Paetzel ___ 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/110728 - patch for mail/py-spambayes
On Apr 19, 2009, at 5:58 AM, Torfinn Ingolfsen wrote: Hello, ports/110728[1] contains a one-line patch that fixes py-spambayes (so that it loads the config file from a defined location, instead of some random directory). The patch was submitted on August 27th, 2007. Yes, the PR is still open. This is a patch which improves the port - IMHO, it should be closed before this ports freeze is over. Could someone look at it? References: 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=110728&cat= -- Regards, Torfinn Ingolfsen I responded to the pr with a patch that fixes the issue, I'll commit it tomorrow. Thanks, Josh Paetzel ___ 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: FreeBSD Port: libyaml-0.1.1
On Feb 9, 2009, at 7:32 AM, Akira Kitada wrote: Could you please update linyaml to 0.1.2? Thanks, Working on it this morning. Due to the shared library bump it touches the consumers as well. Thanks, Josh Paetzel ___ 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: python25-2.5.4_1 build failure
On Feb 26, 2009, at 11:32 PM, andrew clarke wrote: Hi, python25-2.5.4_1 is failing to build on 6.4-REL-p1, and waits for input on stdin: There was a small problem with the patch, it was fixed a few hours ago. Update your ports tree, or manually apply the changes from: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python25/files/patch-Python_thread__pthread.h Thanks, Josh Paetzel ___ 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: problem with postgresql-plpython
József Kurucz wrote: > Hi, > > I try to install the postgresql-plpython from ports ( i use FreeBSD 7 > stable;amd64) but i get the following error message: > > > > configure: error: threaded Python not supported on this platform > ===> Script "configure" failed unexpectedly. > Please report the problem to [EMAIL PROTECTED] [maintainer] and attach the > "/usr/ports/databases/postgresql-plpython/work/postgresql-8.3.3/config.log" > including the output of the failure of your make command. Also, it might be > a good idea to provide an overview of all packages installed on your system > (e.g. an `ls /var/db/pkg`). > *** Error code 1 > > Stop in /usr/ports/databases/postgresql-plpython. > > > > My installed packages: > > > [EMAIL PROTECTED] /usr/ports/databases]# ls /var/db/pkg/ > apache-2.2.9_5 gmake-3.81_3 > openldap-client-2.4.11 py25-psycopg-1.1.21_1 > autoconf-2.62 help2man-1.36.4_2 > p5-BSD-Resource-1.2901 py25-psycopg2-2.0.7_1 > autoconf-wrapper-20071109 libiconv-1.11_1 > p5-gettext-1.05_2 py25-pysqlite-2.3.5 > automake-1.9.6_3libmemcache-1.4.0.rc2 > pcre-7.7_1 py25-setuptools-0.6c8 > automake-wrapper-20071109 libtool-1.5.26 > perl-5.8.8_1python-2.5,2 > bash-3.2.39_1 libxml2-2.6.32 > pkg-config-0.23_1 python25-2.5.2_3 > db41-4.1.25_4 lighttpd-1.4.19_2 > portaudit-0.5.12screen-4.0.3_5 > expat-2.0.1 lua-5.1.3_3 > postgresql-client-8.3.3 sqlite3-3.5.6 > fam-2.6.10_3m4-1.4.11,1 > postgresql-server-8.3.3 tcl-8.4.19,1 > gdbm-1.8.3_3mod_perl2-2.0.4,3 > py25-cheetah-2.0.1 > gettext-0.17_1 mysql-client-5.0.67 > py25-mx-base-2.0.6 > [EMAIL PROTECTED] /usr/ports/databases]# > > > > I attached the config.log! > > > > Best Regards > > Josef Like the config.log says, a threaded python isn't supported on FreeBSD. The fix is to deinstall python, run make config in it's ports directory again, deselect the threaded option, run make clean and reinstall it. Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: Adobe Reader 8 + SCIM/UIM (was Adobe Reader and SCIM)
On Tuesday 08 January 2008 02:02:34 am Aryeh M. Friedman wrote: > >>> did: > >>> > >>> grep ^acroread /usr/ports/INDEX-6 > >> > >> It was not in the ports collection or the index thus the > >> question. > > > > it is (As you obviously can see) > > Ok super genius show it to me: > > [EMAIL PROTECTED]:dev/thistest/ui/cmdline% grep ^acroread > /usr/ports/INDEX-8 > acroread7-7.0.9_2,1|/usr/ports/print/acroread7|/usr/X11R6|Adobe Reader > for view, print, and search PDF documents > (ENU)|/usr/ports/print/acroread7/pkg-descr|[EMAIL PROTECTED]|print > linux||acroreadwrapper-0.0.20060221_3 linux-atk-1.9.1 > linux-cairo-1.0.2 linux-expat-1.95.8 linux-fontconfig-2.2.3_7 > linux-glib2-2.6.6 linux-gtk2-2.6.10 linux-jpeg-6b.34 > linux-pango-1.10.2 linux-png-1.2.8_2 linux-tiff-3.7.1 > linux-xorg-libs-6.8.2_5 > linux_base-fc-4_10|http://www.adobe.com/products/acrobat/readermain.html||| > acroreadwrapper-0.0.20060221_3|/usr/ports/print/acroreadwrapper|/usr/local| >Wrapper script for Adobe > Reader|/usr/ports/print/acroreadwrapper/pkg-descr|[EMAIL PROTECTED]|print >|| [EMAIL PROTECTED]:dev/thistest/ui/cmdline% grep ^acroread8 > /usr/ports/INDEX-8 > [EMAIL PROTECTED]:dev/thistest/ui/cmdline% > > btw INDEX-8 is current as of a few hours ago. uhmmm, your index may be current with your out of date ports tree... Fri Jan 4 20:22:54 2008 UTC (3 days, 11 hours ago) by hrs Add Adobe Reader 8.1.1 and localized versions (total 15 languages). Changes from 7.x include: .. In all honesty I find it amusing you're attempting to improve a system you obviously don't understand -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: Opinion on cross-port OPTIONS CONFLICTS
On Saturday 22 December 2007 03:32:56 pm Edwin Groothuis wrote: > On Sat, Dec 22, 2007 at 11:50:53AM -0600, Josh Paetzel wrote: > > On Friday 21 December 2007 10:33:44 pm Edwin Groothuis wrote: > > > On Fri, Dec 21, 2007 at 09:05:18PM -0600, Josh Paetzel wrote: > > > > > > It also doesn't work if someone runs make rmconfig, or make > > > > > > config again and changes things after the port is installed. > > > > > > > > > > > > It probably doesn't work if a package was used to install either. > > > > > > > > > > Create a slave port audio/arts-withoutnas and let it depends on > > > > > that one. > > > > > > > > I don't think that's a scalable solution. It would create an > > > > explosion of ports in the already taxed tree, as well as confusion as > > > > to which port to install among the users. > > > > > > And what is your solution for this problem? > > > > My initial solution as I posted is to register the OPTIONs used to build > > a port in /var/db/pkg > > And how is that going to resolve the issue earlier suggestions > suffered from with regarding to ports which are not installed yet > but which will be installed as a dependency of this port? > > Edwin Well, my idea was you'd be able to CONFLICT based on OPTIONs set in another port, so at least you could die with a helpful error message if they weren't set properly. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: Opinion on cross-port OPTIONS CONFLICTS
On Friday 21 December 2007 10:33:44 pm Edwin Groothuis wrote: > On Fri, Dec 21, 2007 at 09:05:18PM -0600, Josh Paetzel wrote: > > > > It also doesn't work if someone runs make rmconfig, or make config > > > > again and changes things after the port is installed. > > > > > > > > It probably doesn't work if a package was used to install either. > > > > > > Create a slave port audio/arts-withoutnas and let it depends on > > > that one. > > > > I don't think that's a scalable solution. It would create an explosion > > of ports in the already taxed tree, as well as confusion as to which port > > to install among the users. > > And what is your solution for this problem? > > Edwin My initial solution as I posted is to register the OPTIONs used to build a port in /var/db/pkg -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: Opinion on cross-port OPTIONS CONFLICTS
On Friday 21 December 2007 07:50:59 pm Edwin Groothuis wrote:
> On Fri, Dec 21, 2007 at 04:13:46PM -0600, Josh Paetzel wrote:
> > On Friday 21 December 2007 03:43:19 pm Edwin Groothuis wrote:
> > > On Fri, Dec 21, 2007 at 03:24:20PM -0600, Josh Paetzel wrote:
> > > > I've recently run across some brokeness in ports that would be
> > > > relatively trivial to deal with if one port had a way to know about
> > > > the OPTIONS another port was compiled with.
> > >
> > > I have been working on it a not-so-long-time-ago and found that
> > > this could be the best way:
> > >
> > > [/var/db/ports/arts] [EMAIL PROTECTED]>cat options
> > > # This file is auto-generated by 'make config'.
> > > # No user-servicable parts inside!
> > > # Options for arts-1.5.1_1,1
> > > _OPTIONS_READ=arts-1.5.1_1,1
> > > WITHOUT_ESD=true
> > > WITHOUT_NAS=true
> > >
> > > [/var/db/ports/arts] [EMAIL PROTECTED]>eval `cat options | grep -v "^\#"
> > > | sed
> > > -e 's/^/arts_/'`
> > >
> > > [/var/db/ports/arts] [EMAIL PROTECTED]>echo $arts_WITHOUT_NAS
> > > true
> > >
> > >
> > > I hadn't put it in a PR yet because it has some synchronity issues:
> > >
> > > - It only works for ports already installed.
> > > - It doesn't work for ports which are being installed by this port.
> > > - No idea how to do this for packages build on ye olde cluster.
> > >
> > > But the idea is there:
> > >
> > > OPTIONS_DEPENDS= arts
> > > .include
> > > .if !defined arts_WITH_NAS
> > > BROKEN= Please build audio/arts first before building
> > > this port.
> > > .fi
> > > .if ${arts_WITH_NAS} = "true"
> > > BROKEN= This port can't work with audio/arts enabled
> > > with NAS
> > > support .fi
> > >
> > > Edwin
> >
> > It also doesn't work if someone runs make rmconfig, or make config again
> > and changes things after the port is installed.
> >
> > It probably doesn't work if a package was used to install either.
>
> Create a slave port audio/arts-withoutnas and let it depends on
> that one.
>
> Edwin
I don't think that's a scalable solution. It would create an explosion of
ports in the already taxed tree, as well as confusion as to which port to
install among the users.
--
Thanks,
Josh Paetzel
PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
signature.asc
Description: This is a digitally signed message part.
Re: Opinion on cross-port OPTIONS CONFLICTS
On Friday 21 December 2007 03:43:19 pm Edwin Groothuis wrote:
> On Fri, Dec 21, 2007 at 03:24:20PM -0600, Josh Paetzel wrote:
> > I've recently run across some brokeness in ports that would be relatively
> > trivial to deal with if one port had a way to know about the OPTIONS
> > another port was compiled with.
>
> I have been working on it a not-so-long-time-ago and found that
> this could be the best way:
>
> [/var/db/ports/arts] [EMAIL PROTECTED]>cat options
> # This file is auto-generated by 'make config'.
> # No user-servicable parts inside!
> # Options for arts-1.5.1_1,1
> _OPTIONS_READ=arts-1.5.1_1,1
> WITHOUT_ESD=true
> WITHOUT_NAS=true
>
> [/var/db/ports/arts] [EMAIL PROTECTED]>eval `cat options | grep -v "^\#" |
> sed -e
> 's/^/arts_/'`
>
> [/var/db/ports/arts] [EMAIL PROTECTED]>echo $arts_WITHOUT_NAS
> true
>
>
> I hadn't put it in a PR yet because it has some synchronity issues:
>
> - It only works for ports already installed.
> - It doesn't work for ports which are being installed by this port.
> - No idea how to do this for packages build on ye olde cluster.
>
> But the idea is there:
>
> OPTIONS_DEPENDS= arts
> .include
> .if !defined arts_WITH_NAS
> BROKEN= Please build audio/arts first before building this port.
> .fi
> .if ${arts_WITH_NAS} = "true"
> BROKEN= This port can't work with audio/arts enabled with NAS
> support
> .fi
>
> Edwin
It also doesn't work if someone runs make rmconfig, or make config again and
changes things after the port is installed.
It probably doesn't work if a package was used to install either.
--
Thanks,
Josh Paetzel
PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
signature.asc
Description: This is a digitally signed message part.
Opinion on cross-port OPTIONS CONFLICTS
I've recently run across some brokeness in ports that would be relatively trivial to deal with if one port had a way to know about the OPTIONS another port was compiled with. My initial thought was to register the state of OPTIONS in to /var/db/pkg. This solves all of the problems that I know of (not that I know all of them, but it fixes what I've found that's broken) but also involves quite a bit of work to the pkg_* tools. It was suggested to me that one could set up something such that CONFLICT_FILE=blah which would cover the case of an OPTION in another port causing it to install files that it wouldn't otherwise. This is far far easier to impliment, but does not solve all of the problems I've found. Another suggestion was to list the state of OPTIONS in the package name. I haven't really chewed on this one much. Here are two examples of situations where things are broken and it's tough to fix under the existing infrastructure: 1) random-example-app has ruby support but breaks with a threaded ruby installation. (CONFLICT_FILE wouldn't help here) 2) subversion and apache22 can overwrite each other's apr if you don't tell them about each other. Here's an example of how to duplicate this: install subversion without -DWITH_APACHE2_APR so it installs it's own apr. install apache22 and don't select use apr from ports from the menu. deinstall subversion. It will complain that md5s are wrong on apr because apache installed it's own there. Obviously this is doing it wrong, but in my opinion ports shouldn't be able to overwrite each other. Anyways, suggestions/feedback welcome. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: duration of the ports freeze
On Saturday 01 December 2007 04:49:23 pm Aryeh M. Friedman wrote: > Peter Jeremy wrote: > > On Sat, Dec 01, 2007 at 04:10:14PM -0500, Aryeh M. Friedman wrote: > >> This is due to thinking of the port system as one would of as say > >> make(1) namely a multistage transaction vs. one big atomic > >> transaction. Doing first makes each port responible for most it's > >> knowledge and thus open to inconsistencies and the other makes so the > >> port is nothing but a node in a graph with the edges holding most of > >> the knowledge instead of the nodes. > > > > You continue to complain that the current dependency system is broken > > but you have yet to provide an alternative. > > Right off the top my head a simple DFS or topo sort with approriate > knowledge in the edges would suffice. > > >> If there was a universal way of handling stuff as recommended in > >> Miller97 and most decent algorithm books. > > > > You also regularly references to Aegis - again with no explanation as > > to what problem Aegis would solve and how it would solve it. I recall > > hearing Peter Miller present his paper at AUUG'97 and I know I was > > interested enough at the time to install and experiment with Aegis but > > (for reasons I don't recall any longer), I have since reverted to make. > > First of all he was refering to cook not aegis (aegis is his > alternative to CVS). I stopped using also because the scripting > language is really badlly layed out semantically (basically he tried > to get a functional language into the syntax of an imparative one). > Other then that it is actual quite good. The altenrative is unlike > make which does basically this: > > select some target > check all dependancies on the target recursivally using this algorithm > if all depends are uptodate bring the target up to date > > This has the weaknesses offered in the paper and other large recursive > single node graph processors... yes they can solve a maze but only by > trial and error instead of attempting essentially an all paths > solution before selecting the optimal one (namely a well made cook > project guarantees the spanning tree in all cases where make almost > guarantees a non-span tree for any non-trivial source tree)... a > careful read of Rivest-Korman-et. al. chapter on graphs will show the > same conculsion... for a quick and dirty guide on cook read the > tutorial I wrote on the cook site (Peter's main site not the aegis one) I remember once upon a time reading some advice being handed out to potential contributors to a large project. It was something along the lines of: "You may have heard of good ideas, been taught them in comp-sci class by a research professor, or read about them in a book, but if you don't have practical working knowledge of a working implimentation of them please don't bother trying to wedge them in to our project " The ports tree was never intended to scale to 18,000 apps in it, but the reality of the situation is that it hasand so has the infrastructure to support it. Does it have some weaknesses and deficiencies? Absolutely. Does it have some amazing strengths? Absolutely. I've been using FreeBSD since 1995 on my desktop, and since 1996 on servers. Maybe my practices with ports are influenced by the deficiencies in the tools or maybe they just make sense, but I don't really use the ports tree for anything but make package and make package-recursive anymore. I don't 'upgrade' in the traditional way anymore either. Services run in jails, jail images are created with a list of apps, installed from prebuilt packages built on a build host. When it comes time to 'upgrade' I unpack the new jail with the new batch of packages and cut over the firewall rules directing traffic in to the jail. (jails run on loopback IPs) I've never found a need for portupgrade and friends, in my opinion those tools are a siren song for getting in to an unsupported combination. The typical usage goes... 1) start with a port tree from date A 2) install a ton of ports 3) cvsup/csup/portsnap your ports tree 4) install more ports and/or run portupgrade on parts of your installed ports. At least with packages it complains if you have a dependancy installed that doesn't match what the package was built with. Using ports improperly as described above leaves you with apps build against dependancies they shouldn't be. eg: today's foomatic built against who knows what version of libfoomatic. If you wanted to do something practical, work on improving dependancy and conflict handling in the current ports tree. Asserting that you are going to rewrite the entire package manageme
Re: ruby18, -pthreads, deep recursion
On Thursday 01 November 2007 04:04:35 pm lemon wrote: > Hi, > > I've been struggling with FreeBSD's ruby18 port and threads. I realise > there's previous discussion[0] about this and I feel I'm blundering > somewhat, but here goes. > > On both 7.x and 6.x boxes I've built ruby18 with the pthreads knob > deliberately turned off (the default). The resultant ruby has problems > with deep recursion, shown by this script[1] but less pathologically in > production in a busy RoR site too. > > $ ruby -e 'def d(x); p x; d x+1; end; d 0' > > This bombs with SIGILL[2]. > > I note that, as per the conversations linked above, this build uses the > GCC option -pthread and links against libthr[3]. > > If I build the port without -pthread (and related config.h #define), > install the library alongside the from-port one, and employ the > resultant binary with some libmap.conf guidance I get a ruby which > behaves far nicer[4]. I can recurse way deeper and receive a graceful > SystemStackError exception when things hit the wall[5]. > > What's the score here? Clearly there's motive for building like it does, > but the hacked ruby works better for me in everyday life. Any ideas? > > I hope this is on-topic for freebsd-ports. I mailed the maintainer first > but got no response. > > Regards, l. > > [0] > http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019352.html > http://lists.freebsd.org/pipermail/freebsd-ports/2006-March/030691.html > > [1] Google found me this, I forget where! > > [2] $ ruby -e 'def d(x); p x; d x+1; end; d 0' | head > 0 > 1 > 2 > ... > 2138 > 2139 > Illegal instruction: 4 > > [3] $ ldd `which ruby` > /usr/local/bin/ruby: > libruby18.so.18 => /usr/local/lib/libruby18.so.18 (0x2807d000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x28154000) > libm.so.5 => /lib/libm.so.5 (0x2816d000) > libthr.so.3 => /lib/libthr.so.3 (0x28182000) > libc.so.7 => /lib/libc.so.7 (0x28195000) > > [4] $ ldd ~/tmp/ruby18 > /home/lemon/tmp/ruby18: > libruby18.so.18 => /usr/local/lib/libruby18-nothread.so.18 > (0x2807d000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x28154000) > libm.so.5 => /lib/libm.so.5 (0x2816d000) > libc.so.7 => /lib/libc.so.7 (0x28182000) > > [5] $ ~/tmp/ruby18 -e 'def d(x); p x; d x+1; end; d 0' > 0 > 1 > 2 > ... > 67705 > 67706 > -e:1:in `inspect': stack level too deep (SystemStackError) > from -e:1:in `p' > from -e:1:in `d' > from -e:1:in `d' > from -e:1 If it's any consolation, I've emailed the ruby maintainer a few times about why disabling threads in the port's menu doesn't *really* disable threads and have never gotten a reply. In my case though the damage from the 'sort of threaded' ruby that the port builds with the threads option turned off is far more insiduous. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: local ports
Vulpes Velox wrote: > I was just wondering what any one else thought of the idea of adding > a local directory to the ports tree and to the .cvsignore. This would > be a directory for users to put local custom ports. There's nothing to stop you from creating /usr/ports/local right now and just using it. You don't need a .cvsignore if you are using cvsup/csup, they ignore files that aren't in the cvs repo anyways. Of course if you are using portsnap that might be a different story, not sure how it handles updates... -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portsnap and local patches
On Wednesday 14 March 2007 02:12, Scot Hetzel wrote: > On 3/14/07, Nate Eldredge <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > portsnap is a very nice way to keep your ports tree in sync, but > > it has the disadvantage that it keeps your ports tree in sync :) > > If you make local changes (e.g. adding a patch) they get > > clobbered. Does anyone know of a convenient way to keep ports up > > to date while preserving local patches? > > One way to keep your local changes is to use cvs to checkout and > update the ports tree, you then make your modifications to the > port. > > You will need to fix any conflicts manually between an updated port > and your changes. > > Scot csup/cvsup has the nice feature of not touching files that shouldn't be there, so my solution to that problem is to create a new directory for my local changes, which csup/cvsup will nicely ignore. -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD lang/ruby18 pthread question
I originally sent this email to the ruby maintainer but haven't gotten a response so maybe someone else can enlighten me as to what is going on here. If I install lang/ruby18 with the pthread option turned off (which is the default) I get: # ruby -rrbconfig -e 'puts Config::CONFIG["LIBS"]' -lcrypt -lm -rpath=/usr/lib:/usr/local/lib -pthread If I turn pthreads on I get: # ruby -rrbconfig -e 'puts Config::CONFIG["LIBS"]' -pthread -lcrypt -lm -rpath=/usr/lib:/usr/local/lib -pthread Either way it looks like I get pthread support, unless I am interpreting the output wrong. Any thoughts on this? -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Submitting a new port with dependancies not in the ports tree
I'm in the process of writing a port and it has a dependancy that's not in the ports tree, so I'm porting that as well. My question is what's the procedure in such a case? Should I submit them both as part of the same pr? Obviously the one can't be committed without the other. -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: ScummVM not up to date
On Friday 24 November 2006 15:10, [EMAIL PROTECTED] wrote: > HI > > The ScummVM port is not more Up to date > > it is version 0.8.2_1 but there is already 0.9.1 at > http://scummvm.sourceforge.net/# > > greetz Did you email the maintainer about it? -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devel/boost-python != gtar
On Friday 24 November 2006 12:09, Atom Smasher wrote: > this causes devel/boost-python to fail: > > # ls -lh =gtar =bsdtar =tar > -r-xr-xr-x 1 root wheel47K May 6 2006 /usr/bin/bsdtar > lrwxr-xr-x 1 root wheel19B Nov 24 12:52 /usr/bin/tar -> > /usr/local/bin/gtar -r-xr-xr-x 1 root wheel 201K Nov 13 20:09 > /usr/local/bin/gtar > > > fix: link "bsdtar" to "tar". > > > * boost-python-1.33.1_2 > * bsdtar 1.02.023, libarchive 1.02.026 > * tar (GNU tar) 1.15.1 > * FreeBSD 6.1-RELEASE Real fix...don't mess with the link from bsdtar to tar in the first place. :) -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1-R-p10 and PHP 5.2.0 dumps core with session support enabled (repost with better subject)
On Thursday 16 November 2006 15:09, Josh Paetzel wrote: > Freshly installed FreeBSD 6.1-R-p10 box > > Fresh ports tree from today. php 5.2.0 installed from ports with > the following extensions: > > php5-5.2.0 PHP Scripting Language (Apache Module and CLI) > php5-ctype-5.2.0The ctype shared extension for php > php5-dom-5.2.0 The dom shared extension for php > php5-extensions-1.0 A "meta-port" to install PHP extensions > php5-iconv-5.2.0The iconv shared extension for php > php5-imap-5.2.0 The imap shared extension for php > php5-mcrypt-5.2.0 The mcrypt shared extension for php > php5-mhash-5.2.0The mhash shared extension for php > php5-mysqli-5.2.0 The mysqli shared extension for php > php5-pcre-5.2.0 The pcre shared extension for php > php5-posix-5.2.0The posix shared extension for php > php5-pspell-5.2.0 The pspell shared extension for php > php5-session-5.2.0 The session shared extension for php > php5-simplexml-5.2.0 The simplexml shared extension for php > php5-sysvmsg-5.2.0 The sysvmsg shared extension for php > php5-sysvsem-5.2.0 The sysvsem shared extension for php > php5-sysvshm-5.2.0 The sysvshm shared extension for php > php5-tokenizer-5.2.0 The tokenizer shared extension for php > php5-zlib-5.2.0 The zlib shared extension for php > > Following options used during the PHP install: > > Build CLI > Build CGI > Bulld Apache module > Enable debug > Enable IPv6 support > Enable fastcgi support > Enable path-info-check support > > # php -v > PHP 5.2.0 (cli) (built: Nov 16 2006 14:47:28) (DEBUG) > Copyright (c) 1997-2006 The PHP Group > Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies > Segmentation fault (core dumped) > > backtrace from gdb: > > -- #0 0x in ?? () > #1 0x28a89ea8 in __do_global_dtors_aux () >from /usr/local/lib/php/20060613-debug/session.so > #2 0x28a90e40 in _fini () > from /usr/local/lib/php/20060613-debug/session.so > #3 0x2827d018 in tls_dtv_generation () from /libexec/ld-elf.so.1 > #4 0x2827e3d8 in ?? () from /libexec/ld-elf.so.1 > #5 0xbfbfe9d8 in ?? () > #6 0x2826508e in elf_hash () from /libexec/ld-elf.so.1 > #7 0x28267970 in dlclose () from /libexec/ld-elf.so.1 > #8 0x0817bb04 in module_destructor (module=0x830b380) > at /usr/ports/lang/php5/work/php-5.2.0/Zend/zend_API.c:1915 > #9 0x081801c2 in zend_hash_apply_deleter (ht=0x82797c0, > p=0x83137c0) at > /usr/ports/lang/php5/work/php-5.2.0/Zend/zend_hash.c:606 #10 > 0x0818031b in zend_hash_graceful_reverse_destroy (ht=0x82797c0) at > /usr/ports/lang/php5/work/php-5.2.0/Zend/zend_hash.c:641 #11 > 0x0817596f in zend_shutdown () > at /usr/ports/lang/php5/work/php-5.2.0/Zend/zend.c:714 > #12 0x0812fa15 in php_module_shutdown () > at /usr/ports/lang/php5/work/php-5.2.0/main/main.c:1650 > #13 0x081db225 in main (argc=2, argv=0xbfbfec78) > at /usr/ports/lang/php5/work/php-5.2.0/sapi/cli/php_cli.c:1273 > > Unloading the session module 'fixes' the problem. Unfortunately > session support is mission-critical. > > As a further datapoint, php works fine from apache. > > Need help determining where to go from here to resolve this issue. > > Thanks, > > Josh Paetzel > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 6.1-R-p10 and PHP 5.2.0
Freshly installed FreeBSD 6.1-R-p10 box Fresh ports tree from today. php 5.2.0 installed from ports with the following extensions: php5-5.2.0 PHP Scripting Language (Apache Module and CLI) php5-ctype-5.2.0The ctype shared extension for php php5-dom-5.2.0 The dom shared extension for php php5-extensions-1.0 A "meta-port" to install PHP extensions php5-iconv-5.2.0The iconv shared extension for php php5-imap-5.2.0 The imap shared extension for php php5-mcrypt-5.2.0 The mcrypt shared extension for php php5-mhash-5.2.0The mhash shared extension for php php5-mysqli-5.2.0 The mysqli shared extension for php php5-pcre-5.2.0 The pcre shared extension for php php5-posix-5.2.0The posix shared extension for php php5-pspell-5.2.0 The pspell shared extension for php php5-session-5.2.0 The session shared extension for php php5-simplexml-5.2.0 The simplexml shared extension for php php5-sysvmsg-5.2.0 The sysvmsg shared extension for php php5-sysvsem-5.2.0 The sysvsem shared extension for php php5-sysvshm-5.2.0 The sysvshm shared extension for php php5-tokenizer-5.2.0 The tokenizer shared extension for php php5-zlib-5.2.0 The zlib shared extension for php Following options used during the PHP install: Build CLI Build CGI Bulld Apache module Enable debug Enable IPv6 support Enable fastcgi support Enable path-info-check support # php -v PHP 5.2.0 (cli) (built: Nov 16 2006 14:47:28) (DEBUG) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies Segmentation fault (core dumped) backtrace from gdb: -- #0 0x in ?? () #1 0x28a89ea8 in __do_global_dtors_aux () from /usr/local/lib/php/20060613-debug/session.so #2 0x28a90e40 in _fini () from /usr/local/lib/php/20060613-debug/session.so #3 0x2827d018 in tls_dtv_generation () from /libexec/ld-elf.so.1 #4 0x2827e3d8 in ?? () from /libexec/ld-elf.so.1 #5 0xbfbfe9d8 in ?? () #6 0x2826508e in elf_hash () from /libexec/ld-elf.so.1 #7 0x28267970 in dlclose () from /libexec/ld-elf.so.1 #8 0x0817bb04 in module_destructor (module=0x830b380) at /usr/ports/lang/php5/work/php-5.2.0/Zend/zend_API.c:1915 #9 0x081801c2 in zend_hash_apply_deleter (ht=0x82797c0, p=0x83137c0) at /usr/ports/lang/php5/work/php-5.2.0/Zend/zend_hash.c:606 #10 0x0818031b in zend_hash_graceful_reverse_destroy (ht=0x82797c0) at /usr/ports/lang/php5/work/php-5.2.0/Zend/zend_hash.c:641 #11 0x0817596f in zend_shutdown () at /usr/ports/lang/php5/work/php-5.2.0/Zend/zend.c:714 #12 0x0812fa15 in php_module_shutdown () at /usr/ports/lang/php5/work/php-5.2.0/main/main.c:1650 #13 0x081db225 in main (argc=2, argv=0xbfbfec78) at /usr/ports/lang/php5/work/php-5.2.0/sapi/cli/php_cli.c:1273 Unloading the session module 'fixes' the problem. Unfortunately session support is mission-critical. As a further datapoint, php works fine from apache. Need help determining where to go from here to resolve this issue. Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bugathon, yeah it's time again
On Friday 27 October 2006 12:13, Florent Thoumie wrote: > Ok, heads up folks. > > Ports have been frozen for some weeks now, and it's only a matter > of time before ice starts melting. So we're planning to hold the > next bugathon next week end (well, in one week). Same server, same > channel (#freebsd-bugbusters @ EFNET), you have one week to grab a > list of PR and start working on them. > > WWW: http://wikitest.freebsd.org/Bugathons/November2006 > > Note: Since I still don't receive much feedback from > src-committers, I expect it to be mainly ports-related. Obviously I > may be wrong and there will probably a few src-committers coming, > this channel is still a good place to discuss bugs. I submitted a flurry of PR's right before the freeze (about 20 of them) Most of them deal with updating the download sites/fixing fetch problems, a few of them are version bumps. Do I need to show up in IRC to get these looked at? -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DISTNAME question
I need to set a DISTNAME to get a file from some sort of automatic cvs thing. No matter what I try a .tar.gz is prepended to it. IEI need to get ruby-cvs.tar.gz?only_with_tag=ruby-cvs-0_2&view=tar but I can't seem to stop the port from looking for: ruby-cvs.tar.gz?only_with_tag=ruby-cvs-0_2&view=tar.tar.gz Can anyone help me with the Makefile magic needed here? -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfetchable distfiles reminder
On Saturday 07 October 2006 05:02, Bill Fenner wrote: > Dear porters, > > This is just a reminder to please periodically check the list of > unfetchable distfiles at > http://people.freebsd.org/~fenner/portsurvey/ . In particular, the > list of ports with no MAINTAINER with distfile problems, which > currently has 206 bad ports, is > > http://people.freebsd.org/~fenner/portsurvey/[EMAIL PROTECTED] > > Since no one is responsible for these ports, the problem won't get > fixed unless someone on this list takes the initiative. > > In addition, the list of all ports with any unfetchable distfile > is > > http://people.freebsd.org/~fenner/portsurvey/bad.html > > if you don't mind coordinating your fixes with the port MAINTAINER. > > Thanks for your help! > > Bill "distfiles" Fenner > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" Fun stuff to track down. :) I didn't know anything about your site but it seems to me that it would be a fairly easy thing for a 'junior-hacker' looking to contribute to work on. Maybe it should be linked on the how-to-contribute page? Anyways, I've started taking a look at some of these. So far I've discovered that in some cases the mastersites no longer exist and there is either no email address for the port's author or the email address doesn't work. If this is the case should the ports be recommended for delettion or should the mastersite be changed to ftp.freebsd.org? This also raises the question of how long freebsd.org will retain the distfiles it hasindefintely? -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: webmin-1.300_1
On Friday 06 October 2006 19:46, Michael Wilson wrote: > The makefile for the latest webmin port points to > www.webmin.com/updates for additional wbm downloads. However, the > file is actually located at download.webmin.com/updates > > The webmin.com server is configured for a 302 redirect, but fetch > does not obey 302's, so doing a "make" of webmin from the latest > port fails when attempting to download additional wbm archives. > > Changing www.webmin.com in the Makefile to download.webmin.com > fixes this problem. Probably complete overkill but since the ports freeze is only days away I submitted this as a pr and cc'd the maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=104094 -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
