Re: rxvt-unicode fails build 9 stable i386
On Thu, Jul 26, 2012 at 07:17:48PM -0700, Robert wrote: > > Greetings > > I have been unable to build rxvt-unicode since updating perl to 5.16. I > thought I saw an email that someone else had this problem but I cannot > find it. It happened to me on -current. There I worked around it by forcing clang as compiler for rxvt-unicode. This should do the trick: cd /usr/ports/x11/rxvt-unicode && make clean && make CC=clang CXX=clang++ CPP=clang-cpp install Not sure what the cause is. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question about new options framework (regression?)
Doug Barton wrote: > Traditionally the precedence has been: > > make.conf < OPTIONS < command line Are you sure? But how did the old framework find out if a WITH_* / WITHOUT_* variable came from make.conf or from the command line? For example, say the make environment contains WITH_FOO=YES, but the OPTIONS file contains WITHOUT_FOO=YES. If the above precedence is to be followed, then the framework needed to find out whether the WITH_FOO setting came from make.conf or from the command line. I don't think there's an easy way to do that. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question about new options framework (regression?)
On Thu, Jul 26, 2012 at 04:41:10PM +0200, Oliver Fromme wrote: > > Jase Thew wrote: > > On 25/07/2012 23:57, Baptiste Daroussin wrote: > > > because the priority goes to global to specific and the most specific is > the > > > options file. > > > > > > if most people want the options file to not have the final priority, why > not, > > > can others spread their opinion here? > > > > I can't see why it would be of benefit for saved options to override > > anything passed to make (either env or as an arg), as one of the reasons > > you're likely to be passing them is to override any saved settings in > > the first place. > > > > Please consider reverting back to the established and I daresay, > > expected behaviour. > > I agree with Jase. > > Actually I'm not sure if PORTS_DBDIR should override make.conf > or vice versa. I don't know which one should be regarded as > more specific. > > But anything specified on the commandline is definitely more > specific than PORTS_DBDIR and should override anything else. > > One way to do that would be to introduce another pair of > variables, e.g. OVERRIDE_SET and OVERRIDE_UNSET, so you could > type: make OVERRIDE_SET=STATIC > I think that is the more reasonnable, I'll add this when fully back. I was thinking of LATE_SET and LATE_UNSET but OVERRIDE_SET and OVERRIDE_UNSET sounds better to me. regards, Bapt pgpuNz8yPPm6M.pgp Description: PGP signature
Firefox 14.0.1_1
Hi! I build Firefox 14.0.1_1 on FreeBSD Release 9.0 with QT4 option and it works so bad on KDE 4.8.4. It is impossible to see what is in menus, you cannot choose any option from menu I will start rebuilding with GTK option. Mitja http://jpgmag.com/people/lumiwa ___ 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: Firefox 14.0.1_1
The same here on FreeBSD 8-3 STABLE and KDE4.8.4. with GTK everything works fine. Luca On 07/27/12 12:28, ajtiM wrote: Hi! I build Firefox 14.0.1_1 on FreeBSD Release 9.0 with QT4 option and it works so bad on KDE 4.8.4. It is impossible to see what is in menus, you cannot choose any option from menu I will start rebuilding with GTK option. Mitja http://jpgmag.com/people/lumiwa ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: what port installed /usr/local/lib/gtk-3.0/3.0.0/immodules?
Anton Shterenlikht wrote on 26.07.2012 15:48: I was checking my installation with sysutils/libchk. [...] But none of this files are claimed by any installed port, accorting to pkg: $ pkg which /usr/local/lib/gtk-3.0/3.0.0/immodules/im-multipress.so /usr/local/lib/gtk-3.0/3.0.0/immodules/im-multipress.so was not found in the database Does anybody know what port might've installed these? Thanks [rm@smeshariki3 ~]> pkg_info -W /usr/local/lib/gtk-3.0/3.0.0/immodules/im-multipress.so /usr/local/lib/gtk-3.0/3.0.0/immodules/im-multipress.so was installed by package gtk-3.0.12_2 -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question about new options framework (regression?)
Oliver Fromme wrote: > Doug Barton wrote: > > Traditionally the precedence has been: > > > > make.conf < OPTIONS < command line > > Are you sure? But how did the old framework find out if a > WITH_* / WITHOUT_* variable came from make.conf or from the > command line? Uhm, please ignore what I wrote. I forgot about "?=" syntax in make.conf ... In that case it works fine, of course. So, it really should be sufficient to move the compatibility section (the one that looks at WITH_* / WITHOUT_*) to the end of bsd.options.mk, after the section that loads the options file from $PORTS_DBDIR. Then the desired behaviour should be back. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question about new options framework (regression?)
On 2012-07-27 11:41, Baptiste Daroussin wrote: > On Thu, Jul 26, 2012 at 04:41:10PM +0200, Oliver Fromme wrote: >> >> Jase Thew wrote: >> > On 25/07/2012 23:57, Baptiste Daroussin wrote: >> > > because the priority goes to global to specific and the most specific >> is the >> > > options file. >> > > >> > > if most people want the options file to not have the final priority, >> why not, >> > > can others spread their opinion here? >> > >> > I can't see why it would be of benefit for saved options to override >> > anything passed to make (either env or as an arg), as one of the reasons >> > you're likely to be passing them is to override any saved settings in >> > the first place. >> > >> > Please consider reverting back to the established and I daresay, >> > expected behaviour. >> >> I agree with Jase. >> >> Actually I'm not sure if PORTS_DBDIR should override make.conf >> or vice versa. I don't know which one should be regarded as >> more specific. >> >> But anything specified on the commandline is definitely more >> specific than PORTS_DBDIR and should override anything else. >> >> One way to do that would be to introduce another pair of >> variables, e.g. OVERRIDE_SET and OVERRIDE_UNSET, so you could >> type: make OVERRIDE_SET=STATIC >> > > I think that is the more reasonnable, I'll add this when fully back. I was > thinking of LATE_SET and LATE_UNSET but OVERRIDE_SET and OVERRIDE_UNSET sounds > better to me. > Why reinvent the wheel ??? The vars -DWITH(OUT)_FOO is something already well known and documented, the wrapper is already in bsd.options.mk (last entry) but it broken at the moment. -- Regards, olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question about new options framework (regression?)
On Fri, Jul 27, 2012 at 02:25:35PM +0200, olli hauer wrote: > On 2012-07-27 11:41, Baptiste Daroussin wrote: > > On Thu, Jul 26, 2012 at 04:41:10PM +0200, Oliver Fromme wrote: > >> > >> Jase Thew wrote: > >> > On 25/07/2012 23:57, Baptiste Daroussin wrote: > >> > > because the priority goes to global to specific and the most specific > >> is the > >> > > options file. > >> > > > >> > > if most people want the options file to not have the final priority, > >> why not, > >> > > can others spread their opinion here? > >> > > >> > I can't see why it would be of benefit for saved options to override > >> > anything passed to make (either env or as an arg), as one of the reasons > >> > you're likely to be passing them is to override any saved settings in > >> > the first place. > >> > > >> > Please consider reverting back to the established and I daresay, > >> > expected behaviour. > >> > >> I agree with Jase. > >> > >> Actually I'm not sure if PORTS_DBDIR should override make.conf > >> or vice versa. I don't know which one should be regarded as > >> more specific. > >> > >> But anything specified on the commandline is definitely more > >> specific than PORTS_DBDIR and should override anything else. > >> > >> One way to do that would be to introduce another pair of > >> variables, e.g. OVERRIDE_SET and OVERRIDE_UNSET, so you could > >> type: make OVERRIDE_SET=STATIC > >> > > > > I think that is the more reasonnable, I'll add this when fully back. I was > > thinking of LATE_SET and LATE_UNSET but OVERRIDE_SET and OVERRIDE_UNSET > > sounds > > better to me. > > > > Why reinvent the wheel ??? > > The vars -DWITH(OUT)_FOO is something already well known and documented, the > wrapper is already in bsd.options.mk (last entry) but it broken at the moment. > Because WITH(OUT) is inconsistent and is dependant from how the maintainer is writting its ports: does he check for both WITH_ and !WITHOUT_ for example, does he check for only one of them? One of the reason of the new options framework is to get rid of WITH_ and WITHOUT_ because it is not consistent never work the same over the ports and that the user have to check the Makefile itself to determine if what is checked is WITH_ or WITHOUT_ regards, Bapt pgpt0May0TdoQ.pgp Description: PGP signature
Re: Question about new options framework (regression?)
On 27/07/2012 10:41, Baptiste Daroussin wrote: > On Thu, Jul 26, 2012 at 04:41:10PM +0200, Oliver Fromme wrote: >> >> Jase Thew wrote: >> > On 25/07/2012 23:57, Baptiste Daroussin wrote: >> > > because the priority goes to global to specific and the most specific >> is the >> > > options file. >> > > >> > > if most people want the options file to not have the final priority, >> why not, >> > > can others spread their opinion here? >> > >> > I can't see why it would be of benefit for saved options to override >> > anything passed to make (either env or as an arg), as one of the reasons >> > you're likely to be passing them is to override any saved settings in >> > the first place. >> > >> > Please consider reverting back to the established and I daresay, >> > expected behaviour. >> >> I agree with Jase. >> >> Actually I'm not sure if PORTS_DBDIR should override make.conf >> or vice versa. I don't know which one should be regarded as >> more specific. >> >> But anything specified on the commandline is definitely more >> specific than PORTS_DBDIR and should override anything else. >> >> One way to do that would be to introduce another pair of >> variables, e.g. OVERRIDE_SET and OVERRIDE_UNSET, so you could >> type: make OVERRIDE_SET=STATIC >> > > I think that is the more reasonnable, I'll add this when fully back. I was > thinking of LATE_SET and LATE_UNSET but OVERRIDE_SET and OVERRIDE_UNSET sounds > better to me. > What use-case are you thinking of that requires the ability for saved config to override manually specified config? If there isn't a compelling reason for this, then I'd personally much rather see the original behaviour restored rather than adding another two variables. Regards, Jase. -- Jase Thew j...@freebsd.org FreeBSD Ports Committer signature.asc Description: OpenPGP digital signature
Re: Question about new options framework (regression?)
On Fri, Jul 27, 2012 at 04:46:23PM +0100, Jase Thew wrote: > On 27/07/2012 10:41, Baptiste Daroussin wrote: > > On Thu, Jul 26, 2012 at 04:41:10PM +0200, Oliver Fromme wrote: > >> > >> Jase Thew wrote: > >> > On 25/07/2012 23:57, Baptiste Daroussin wrote: > >> > > because the priority goes to global to specific and the most specific > >> is the > >> > > options file. > >> > > > >> > > if most people want the options file to not have the final priority, > >> why not, > >> > > can others spread their opinion here? > >> > > >> > I can't see why it would be of benefit for saved options to override > >> > anything passed to make (either env or as an arg), as one of the reasons > >> > you're likely to be passing them is to override any saved settings in > >> > the first place. > >> > > >> > Please consider reverting back to the established and I daresay, > >> > expected behaviour. > >> > >> I agree with Jase. > >> > >> Actually I'm not sure if PORTS_DBDIR should override make.conf > >> or vice versa. I don't know which one should be regarded as > >> more specific. > >> > >> But anything specified on the commandline is definitely more > >> specific than PORTS_DBDIR and should override anything else. > >> > >> One way to do that would be to introduce another pair of > >> variables, e.g. OVERRIDE_SET and OVERRIDE_UNSET, so you could > >> type: make OVERRIDE_SET=STATIC > >> > > > > I think that is the more reasonnable, I'll add this when fully back. I was > > thinking of LATE_SET and LATE_UNSET but OVERRIDE_SET and OVERRIDE_UNSET > > sounds > > better to me. > > > > What use-case are you thinking of that requires the ability for saved > config to override manually specified config? If there isn't a > compelling reason for this, then I'd personally much rather see the > original behaviour restored rather than adding another two variables. > > Regards, > > Jase. > -- > Jase Thew > j...@freebsd.org > FreeBSD Ports Committer > > The use-case is the one which is the start of this thread. Olivier has a save configuration of zsh and want in one shot be able to activate the STATIC option which is not activate in his normal zsh. regards, Bapt pgpqVNbujCuef.pgp Description: PGP signature
mail/enigmail-thunderbird broken with the latest thunderbird update
First let me say a big thank you to the gecko@ team. It's obvious that the latest round of updates includes an enormous amount of work, and both the thunderbird build and the firefox PGO build went flawlessly. I've been using the new firefox and it is great so far. :) The problem comes in with the enigmail-thunderbird build. After re-building thunderbird and starting the enigmail build I get this: cd /usr/local/tmp/WRKDIRPREFIX/frontier/ports-svn/head/mail/enigmail-thunderbird/work/comm-release/mailnews/extensions/enigmail && /usr/bin/env SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local MOTIFLIB="-L/usr/local/lib -lXm -lXp" LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2 -pipe -fno-strict-aliasing" CPP="cpp" CPPFLAGS="" LDFLAGS="" CXX="c++" CXXFLAGS="-O2 -pipe -fno-strict-aliasing" MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -o root -g wheel -m 555" BSD_INSTALL_LIB="install -s -o root -g wheel -m 444" BSD_INSTALL_SCRIPT="install -o root -g wheel -m 555" BSD_INSTALL_DATA="install -o root -g wheel -m 444" BSD_INSTALL_MAN="install -o root -g wheel -m 444" gmake Makefile:45: ../../../config/autoconf.mk: No such file or directory /usr/local/tmp/WRKDIRPREFIX/frontier/ports-svn/head/mail/enigmail-thunderbird/work/comm-release/config/config.mk:57: ../../../config/autoconf.mk: No such file or directory gmake: *** No rule to make target `../../../config/autoconf.mk'. Stop. *** [do-build] Error code 2 I looked in that directory and the autoconf.mk.in file is there, but the .mk file has not been built. Given the complexity of the enigmail build process it isn't obvious to me what the solution is. Sorry to be the bearer of bad news, Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question about new options framework (regression?)
Jase Thew wrote: > On 27/07/2012 10:41, Baptiste Daroussin wrote: > > > > I think that is the more reasonnable, I'll add this when fully back. I was > > thinking of LATE_SET and LATE_UNSET but OVERRIDE_SET and OVERRIDE_UNSET > > sounds > > better to me. > > What use-case are you thinking of that requires the ability for saved > config to override manually specified config? If there isn't a > compelling reason for this, then I'd personally much rather see the > original behaviour restored rather than adding another two variables. Baptiste is right ... The original behaviour is flawed, because it depends on how the port's maintainer wrote the Makefile. For example, If you have WITH_FOO=YES in the options file, and the port's Makefile checks whether WITH_FOO is set or unset, then there is *no* way to override that, not even with the old options framework. In the case of zsh I was lucky, because the (old) Makefile checked if WITH_ZSH_STATIC is set, while the options file contained WITHOUT_ZSH_STATIC, so I could override that. If it was checking whether WITHOUT_ZSH_STATIC was unset, it wouldn't have worked. Also, if I wanted to do it the other way round, i.e. set WITH_ZSH_STATIC in the options file, there would be no way to unset that on the command line. So, Baptiste's approach to fix that alltogether is right, in my opinion. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question about new options framework (regression?)
The use-case is the one which is the start of this thread. Olivier has a save configuration of zsh and want in one shot be able to activate the STATIC option which is not activate in his normal zsh. Which requires a manually-specified (via command-line) configuration to override whatever happens to be saved (in /var/db/ports). Treat /etc/make.conf and /var/db/ports//options the same. Doesn't really matter -- though keeping things the way they were in terms of the order in which they're processed (particularly with the ?= constructs) is important. However, if I specify SOMEVAR=VALUE on the command line, either as an environmental variable set, or a make construct, I absolutely expect it to be honored. cf: cd /usr/src; make KERNCONF=WOOT buildkernel -aDe ___ 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"
Firefox 14 build broken due to wrong libpng
My build from ports of Firefox 14.0.1 dies in the configure script. It says that the system PNG library does not support APNGs. (I am on FreeBSD 8.3 stable.) Anyway, if I manually run config ./configure --without-system-png then configure succeeds, but then configure says that I am not building with a separate obj tree and gmake ends up failing later on. Obviously I need the full build scripts. Possible fix: add --without-system-png to the BSD overrides? Dan Allen ___ 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"
MATE 'base' desktop is ready for anyone to test it.
Hello all, The MATE base desktop (x11/mate-base) is ready to use and test. The MATE base is a very lite and lean desktop. The MATE base list can be viewed at http://wiki.mate-desktop.org/building . I will add more applications that are in the 'Extras' list that will be in the x11/mate (doesn't exist as now). To get it, you will need to grab marcusmerge script from http://www.marcuscom.com/downloads/marcusmerge then run 'sh marcusmerge -m ports-experimental'. To update it: - - sh marcusmerge -U - Update your ports tree by using csup or other method. -sh marcusmerge -u -m ports-experimental - To run MATE desktop: /etc/rc.conf: - dbus_enable="YES" hald_enable="YES" avahi_daemon_enable="YES" avahi_dnsconfd_enable="YES" - ~/.xinitrc: - exec ck-launch-session dbus-launch mate-session - If you want to use login manager. I only have tested it with x11/slim so far. I do not plan to test it with GDM, so feel free to test and fix on your own. To get x11/slim works.. /etc/rc.conf: - dbus_enable="YES" hald_enable="YES" avahi_daemon_enable="YES" avahi_dnsconfd_enable="YES" slim_enable="YES" - ~/.xinitrc: - exec mate-session - While I am here. I did some work on port LightDM to FreeBSD, but there is a problem with our x11/xorg-server (/usr/local/bin/X) is missing some function that LightDM needs like 'X -novtswitch' and probably other more. I have tried to add -novtswitch and it got me to the login screen, but it doesn't let me to log in with my password for some reasons. I will clean up the x11/lightdm and pass on to anyone that who want to finish it (got bored with it for me when I found x11/slim). Please continue to read to the bottom. Cheers, Mezz -- Forwarded message -- From: Jeremy Messenger Date: Fri, Jul 27, 2012 at 12:37 PM Subject: [marcuscom-devel] cvs commit: ports-experimental/x11/mate-base Makefile pkg-descr pkg-message pkg-plist To: marcuscom-de...@marcuscom.com mezz2012-07-27 17:37:20 UTC MarcusCom CVS repository Added files: x11/mate-baseMakefile pkg-descr pkg-message pkg-plist Log: This metaport installs only MATE base (lite, a lean desktop) with file manager without any of extra applications. If you want to have the most common user MATE applications, please install the x11/mate metaport. It was copied from the pkg-descr as we don't have the x11/mate yet, but we will. The version is 1.4. However, I have decided to add mate-base because it is stable compare to 1.2. The only error that I am getting is: dbus[1377]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.13" (uid=1001 pid=1602 comm="caja ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.2" (uid=0 pid=1520 comm="/usr/local/sbin/console-kit-daemon --no-daemon ") I don't know what it is, but it looks like it doesn't affect function to use MATE. I haven't test the mount/umount yet, so it probably affects on that part or not. Revision ChangesPath 1.1 +34 -0 ports-experimental/x11/mate-base/Makefile (new) 1.1 +21 -0 ports-experimental/x11/mate-base/pkg-descr (new) 1.1 +8 -0 ports-experimental/x11/mate-base/pkg-message (new) 1.1 +1 -0 ports-experimental/x11/mate-base/pkg-plist (new) ___ marcuscom-de...@marcuscom.com mailing list http://www.marcuscom.com/mailman/listinfo/marcuscom-devel To unsubscribe, send any mail to "marcuscom-devel-unsubscr...@marcuscom.com" -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Firefox 14 build broken due to wrong libpng
On Jul 27, 2012, at 12:04 PM, Dan Allen wrote: > My build from ports of Firefox 14.0.1 dies in the configure script. It says > that the system PNG library does not support APNGs. (I am on FreeBSD 8.3 > stable.) I am now running the upgrade from Firefox 13 to 14 on two RELENG_9 (9.1 PRERELEASE) systems. One failed in the same was the above, and one appears to be building okay. Hmm. Dan ___ 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"
p5-XML/LibXML - build failed
With a new install of 8.3-STABLE and a fresh ports tree p5-XML-LibXML failed to build with the following error: torrus-2.01_2 depends on package: rrdtool torrus-2.01_2 depends on package: p5-XML-LibXML>=0 - not found Verifying install for p5-XML-LibXML>=0 in /usr/ports/textproc/p5-XML-LibXML Building for p5-XML-LibXML-1.91,1 cc -c -I/usr/local/include/libxml2 -I/usr/local/include -02 -pipe -march=prescott -fno-strict-aliasing -02 -pipe -march=prescott -fno-strict-aliasing -DVERSION=\"1.97\" -DXS_VERSION=\"1.97\" -DPIC -fPIC "-I/usr/local/lib/perl5/5.16.0/mach/CORE -DHAVE_UTF8 -DHAVE_BLANK LibXML.c LibXML.c: In function 'XS_XML__LibXML__RelaxNG_DESTROY': LibXML.c:11460: error: 'xmlRelaxNGPtr' undeclared (first use in this function) LibXML.c:11460: error (Each undeclared identifier is reported only once for each function it appears in) LibXML.c:11460: error: expected ';' before 'self' LibXML.c:11463: error: 'self' undeclared (first use in this function) LibXML.c:11463: error: expected expression before 'unsigned' *** Error code 1 ___ 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"
pkg2ng error
Hi, Just installed a 9.0-R/i386 system, updated via freebsd-update, new ports via portsnap. Decided to try this pkgng stuff I hear all the good things about. I had three ports installed before converting: tmux, rsync, and libevent. # pkg2ng Creating backup pkg_info(1) database directory in /var/db/pkg.bak. Installing libevent-1.4.14b_2... done Installing pkg-1.0.r4... done Installing rsync-3.0.9... done pkg_info: can't find package 'libevent-1.4.14b_2' installed or in a file! My old package database is here. pkg: Skipping malformed dependency entry for libevent pkg: Skipping malformed dependency libevent Installing tmux-1.5... done Moved old package database to /var/db/pkg.bak. # I can assure you that libevent is actually installed. At least, tmux works. :-) Should I be concerned? ==ml -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery mwlu...@michaelwlucas.com, Twitter @mwlauthor ___ 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: MATE 'base' desktop is ready for anyone to test it.
On Fri, Jul 27, 2012 at 1:09 PM, Jeremy Messenger wrote: > Hello all, > > The MATE base desktop (x11/mate-base) is ready to use and test. The > MATE base is a very lite and lean desktop. A bit of FAQ: Q: There is problem with pkg-plist. A: Yes, I know about that. The reason why I leave complete @dirrm in the pkg-plist, so that way I can comparing what's the most common @dirrm for I can create matehier (like gnomehier). Q: When will MATE ports merge into FreeBSD ports tree. A: Even thought if I finished everything with MATE. It won't be merged into FreeBSD ports tree unless I get more people to help me with the MATE project. Right now, I am only a person that work on MATE. I prefer to be least three people. Q: If there is problem, where do I report to? Send a PR? A: Please no PR. I hate GNATS, but we should use it when MATE merges into FreeBSD ports tree though. For now, just send me an email or gn...@freebsd.org. Q: Does MATE conflicts with GNOME 2/3? A: No, it's complete parallel even in the ~/.* too. Q: Why you won't check on GDM? A: Because it's a GNOME applications and I do not want to install any extra dependency. :-) But if MATE folks fork the GDM and yes I will work on it. Q: Is it easy to use MATE with GDM? A: I think it should be easy as MATE does provide session files. I think GDM will pick up that session and add in the list for which desktop you want to log in. Q: Does the http://www.freebsd.org/gnome/docs/faq2.html works for MATE? A: Yes, most of them. Same goes for HAL: http://www.freebsd.org/gnome/docs/halfaq.html Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Firefox 14 build broken due to wrong libpng
On 07/27/12 20:41, Dan Allen wrote: On Jul 27, 2012, at 12:04 PM, Dan Allen wrote: My build from ports of Firefox 14.0.1 dies in the configure script. It says that the system PNG library does not support APNGs. (I am on FreeBSD 8.3 stable.) I am now running the upgrade from Firefox 13 to 14 on two RELENG_9 (9.1 PRERELEASE) systems. One failed in the same was the above, and one appears to be building okay. Hmm. Dan You have to rebuild graphics/png with support for APNG. HTH! -- Niclas Zeising ___ 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: Firefox 14 build broken due to wrong libpng
Dan Allen wrote: > My build from ports of Firefox 14.0.1 dies in the configure script. It > says that the system PNG library does not support APNGs. You need to rebuild graphics/png with the APNG option enabled. This is the default now, but it wasn't until a year ago. So if you have a system that has been upgraded for a long time, you probably installed png, hit return for the default options and have been stuck with APNG=off since then. You're not the first one to be bitten by this and you won't be the last one. -- Christian "naddy" Weisgerber na...@mips.inka.de ___ 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: Firefox 14 build broken due to wrong libpng
On 27 Jul 2012, at 1:48 PM, Niclas Zeising wrote: > You have to rebuild graphics/png with support for APNG. > HTH! Thanks! That was it. One of my 9.0 systems is new and that's why it worked there. The other two have been running for years and had the old settings. Thanks to Christian as well. Dan ___ 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: pkg2ng error
On 27/07/2012 20:43, Michael W. Lucas wrote: > Just installed a 9.0-R/i386 system, updated via freebsd-update, new > ports via portsnap. Decided to try this pkgng stuff I hear all the > good things about. > > I had three ports installed before converting: tmux, rsync, and > libevent. > > # pkg2ng > Creating backup pkg_info(1) database directory in /var/db/pkg.bak. > Installing libevent-1.4.14b_2... done > Installing pkg-1.0.r4... done > Installing rsync-3.0.9... done > pkg_info: can't find package 'libevent-1.4.14b_2' installed or in a file! > > My old package database is here. > pkg: Skipping malformed dependency entry for libevent > pkg: Skipping malformed dependency libevent > Installing tmux-1.5... done > Moved old package database to /var/db/pkg.bak. > # > > I can assure you that libevent is actually installed. At least, tmux > works. :-) > > Should I be concerned? Hmmm... What does 'pkg info' say? If it won't admit that a libevent package is installed, then what does 'pkg check -da' produce? For best results, make sure PACKAGESITE is set to http://pkgbeta.freebsd.org/freebsd-9-i386/latest/ in pkg.conf before trying that though. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: etoile-typewriter-0.4.1: no entry for /usr/ports/textproc/etoile-ogrekit make_index: etoile-typewriter-0.4.1: no entry for /usr/ports/textproc/etoile-ogrekit make_index: etoile-melodie-0.4.1_3: no entry for /usr/ports/x11-themes/etoile-iconkit make_index: etoile-melodie-0.4.1_3: no entry for /usr/ports/x11-themes/etoile-iconkit make_index: vindaloo-0.2_6: no entry for /usr/ports/x11-themes/etoile-iconkit make_index: vindaloo-0.2_6: no entry for /usr/ports/x11-themes/etoile-iconkit make_index: etoile-menuserver-0.4.1: no entry for /usr/ports/x11/etoile-xwindowserverkit make_index: etoile-menuserver-0.4.1: no entry for /usr/ports/x11/etoile-xwindowserverkit make_index: etoile-babbler-0.1.20061221_2: no entry for /usr/ports/x11/etoile-xwindowserverkit make_index: etoile-babbler-0.1.20061221_2: no entry for /usr/ports/x11/etoile-xwindowserverkit make_index: etoile-inspectorkit-0.2_1: no entry for /usr/ports/x11-themes/etoile-iconkit make_index: etoile-inspectorkit-0.2_1: no entry for /usr/ports/x11-themes/etoile-iconkit Committers on the hook: ak bapt delphij mi ohauer Most recent CVS update was: U devel/bugzilla/Makefile U devel/bugzilla/distinfo U devel/bugzilla3/Makefile U devel/bugzilla3/distinfo U devel/bugzilla42/Makefile U devel/bugzilla42/distinfo U german/Makefile U german/bugzilla/Makefile U german/bugzilla/files/patch-de__default__global__confirm-user-match.html.tmpl U german/bugzilla3/Makefile U german/bugzilla42/Makefile U german/bugzilla42/distinfo U german/bugzilla42/pkg-descr U german/bugzilla42/pkg-message U german/bugzilla42/pkg-plist U net/Makefile U net/libutp/Makefile U net/libutp/distinfo U net/libutp/pkg-descr U net/libutp/pkg-plist U net/libutp/files/BSDmakefile U net/libutp/files/patch-utypes U security/vuxml/vuln.xml U sysutils/Makefile U sysutils/fusefs-mhddfs/Makefile U textproc/Makefile U www/Makefile U x11/Makefile U x11-fm/Makefile U x11-themes/Makefile U x11-wm/Makefile ___ 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: rxvt-unicode fails build 9 stable i386
On Fri, 27 Jul 2012 11:10:23 +0200 Guido Falsi wrote: > On Thu, Jul 26, 2012 at 07:17:48PM -0700, Robert wrote: > > > > Greetings > > > > I have been unable to build rxvt-unicode since updating perl to > > 5.16. I thought I saw an email that someone else had this problem > > but I cannot find it. > > It happened to me on -current. There I worked around it by forcing > clang as compiler for rxvt-unicode. This should do the trick: > > cd /usr/ports/x11/rxvt-unicode && make clean && make CC=clang > CXX=clang++ CPP=clang-cpp install > > Not sure what the cause is. > Thanks for this information. This worked as you said. If I put this clang information into /etc/make.conf will I need to rebuild all of my installed ports? Robert ___ 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"
INDEX now builds successfully on 7.x
___ 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"
