Re: value of maintaining emacs-mode packages in ports
On So, 2014-11-23 at 07:32 -0500, Daniel Feenberg wrote: On Sun, 23 Nov 2014, Christopher J. Ruwe wrote: In that light and as the ports maintainer of math/ess, the Emacs speaks statistics R-mode of emacs, I am asking myself specifically whether I add any real benefit in maintaining math/ess. More generally, I am interested in community answers as to whether it is really useful to maintain Emacs-extension-packages in ports. As a non-Emacs user, can I raise some questions that should be asked every time a service/feature is withdrawn? If you stop maintaining math/ess, does it go away, or merely stop improving? I think eventually math/ess would be retired on go away. Emacs package installation is available since Emacs 24 and I believe emacs23 is retired as of 19th November this year. Does the Emacs package system support the same versions of Emacs that you support in math/ess? I have the impression they are more up to date. Latest MELPA package is from the 14th (http://melpa.org/#/ess). If a user upgrades FreeBSD will he lose what he has unless he converts to the new Emacs package system? Emacs packages are more like plugins (cf. firefox). Upgrades of FreeBSD do not touch these. On upgrades of Emacs, users might need to recompile, if the chose to run compiled Emacs Lisp modules. Is the Emacs package system something that requires an installation of its own? A clear no. ESS is just an interface to the R language/interpreter (math/R). It can run without R installed, although it is not very useful in my opinion the same way that having a languange-mode for an arbitrary languae is not really useful without the corresponding language compiler/interpreter around. But people do strange things .. May I suggest that if you let it go away, you place a README file where Emacs-extension-packages was that points users to the replacement, with instructions for how to get there? Not everyone using Emacs on FreeBSD follows the mailing lists for FreeBSD, (or Emacs). I do not now procedures for deprecated ports. I see emacs modes alike to plugins in firefox, which are not packaged as well, so I see the idea of potentially retiring math/ess in the wider setting of giving up more or less all emacs extensions. Anyhow, thanks for your thoughts. Cheers, -- Christopher ___ 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: value of maintaining emacs-mode packages in ports
On Mo, 2014-11-24 at 00:48 +0100, Roland Smith wrote: On Sun, Nov 23, 2014 at 12:32:14AM +0100, Christopher J. Ruwe wrote: I am well aware that very probably I might be starting a rant thread, however, I am genuinely interested in opinions from the community. Since version 24, Emacs, the very good operating system missing only a decent editor, has developed a package manager for Emacs extensions. Some good repos exist, packages are usually installed to ~/.emacs.d and I have come to really enjoy that way of installing packages. In that light and as the ports maintainer of math/ess, the Emacs speaks statistics R-mode of emacs, I am asking myself specifically whether I add any real benefit in maintaining math/ess. More generally, I am interested in community answers as to whether it is really useful to maintain Emacs-extension-packages in ports. Thanks for your thoughts, cheers, It might help to see this question in a broader context. There are several communities that have there own repositories/package managers these days, e.g: * TeX * Perl * Python * Ruby * Node * Emacs Yet the maintainers of the ports system go through the effort of maintaining ports for a lot of these packages, even though it might strictly speaking be considered a duplication of effort. There are at least two big reasons that I can think of; 1) FreeBSD specific patches are necessary to build a package. (I.e. every port that has a files subdirectory.) The ports tree is arguably the right place for that. The best case would be that such changes are merged upstream, but that doesn't always happen. 2) A foreign package might depend on a FreeBSD port or the other way around. How could this be handled properly if not in the ports tree? So by its very nature, if you want to reap the benefits of the ports infrastructure for your package, you have to *use* said infrastructure. Packages that *can* install in a user's $HOME directory and have no non-obvious dependencies are the exception to this rule, I think. No one will expect e.g. a vim bundle to do anything useful when vim is not installed! But such packages are obviously only available to the user that has installed them. So for a multi-user installation a port would still make more sense. Roland I think of Emacs modes differently than of Perl/Python/Ruby/Nodejs ... programs. The latter do not extend the languages, but use the language to provide independent utility to some user. Emacs modes, alike to the vim bundles you mentioned, extend Emacs (up to the ultimate goal that the user is for the whole duration of the session not forced to leave Emacs ;-) ). I cannot think of any Emacs mode being required by something non-Emacs. I have mentioned in a different answer that I see them alike to Firefox plugins. The only patches I noted so far to Emacs ports concern the placement of files, although I may well be wrong here. I have problems imaging a multi-user installation with multiple instances of Emacs mode packages installed. My elders have told tales of lore of mighty heroes connecting to machines using tools of magic called terminals, so they all could toil on the same computer. Jokes aside, I can only think of thin client settings where one would want to avoid multiple packages of the same program installed. Isn't everybody using independent so called personal computers now? Without any irony, that's a real question: I thought thin client computing has more or less died, am I wrong here? Anyhow, thanks for your thoughts on that matter -- Christopher signature.asc Description: This is a digitally signed message part
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ graphics/gscan2pdf | 1.2.6 | 1.2.7 +-+ graphics/nip2 | 7.40.4 | 7.42.0 +-+ net-mgmt/cacti | 0.8.8b | 0.8.8c +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt 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
Caveat: Firefox and Thunderbird not working with latest GTK
Hello. The box is a 9.3/i386 and I'm using portupgrade to compile ports from source; the desktop environment is XFCE. Yesterday evening I updated some unrelated ports and some dependencies of Firefox and Thunderbird were updated: after that, those two applications were not running properly. The main window would come up, but never be updated anymore; if I typed on the keyboard I could perceive something happening under the hood (other windows popping up, network packets flowing), but I would see nothing on the screen (the main window would stay exactly as it was when it opened). I removed all extensions, but to no avail. I tried portupgrade -Rf thunderbird firefox and let the box compile all night, but again, no luck. So I downgraded all the ports that had been updated and FF and TB started working again. Then I began updating them one at a time and found the culprit to be gtk: when upgrading from 2.24.22_4 to 2.24.25 I get the behaviour described above; after downgrading, both programs work again. I did the same test on another box (10.0/amd64) and got the same results. Right now I'm running the old version of GTK and I'm fine. I'm unsure whether to file a bug report, tough, since I have no further info to include; OTOH, maybe I'm doing something wrong... I'm willing to do any testing if someone can suggest what to try and where to look. bye Thanks av. ___ 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: value of maintaining emacs-mode packages in ports
On Sun, Nov 23, 2014 at 12:12:06AM -0800, Perry Hutchison wrote: Christopher J. Ruwe c...@cruwe.de wrote: ... Emacs, the very good operating system missing only a decent editor ... Perhaps someone should port vi to it? That actually already happened quite a while ago. Just add (require 'viper) to your .emacs file. ___ 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: value of maintaining emacs-mode packages in ports
[trimmed to a single mailing list] Christopher J. Ruwe c...@cruwe.de writes: Since version 24, Emacs, the very good operating system missing only a decent editor, has developed a package manager for Emacs extensions. Some good repos exist, packages are usually installed to ~/.emacs.d and I have come to really enjoy that way of installing packages. The two methods are equivalent on a single-user machine. If we had a canned method to install Emacs packages to the site-local lisp directories without using the ports system, that would make the ports less relevant on multi-user systems as well. There are also differences in convenience based on which repositories provide which packages. My first reaction is that removing the ports would only be advisable for packages available from the official Gnu repository (elpa.gnu.org), and not for others. So: I don't think the ports are without value, but we could move that way for many of them if we wanted. Once the number of users of earlier versions of emacs is sufficiently small, that is. ___ 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
pysolfc broken?
[root@myhost ~]# pkg install pysolfc Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The following 3 packages will be affected (of 0 checked): New packages to be INSTALLED: pysolfc: 2.0_6 py27-tkinter: 2.7.8_5 py27-pillow: 2.6.0 The process will require 17 MB more space. Proceed with this action? [y/N]: y [1/3] Installing py27-tkinter-2.7.8_5 [2/3] Installing py27-pillow-2.6.0 [3/3] Installing pysolfc-2.0_6 [root@myhost ~]# pysolfc Traceback (most recent call last): File /usr/local/bin/pysolfc, line 32, in module sys.exit(main(sys.argv)) File /usr/local/lib/python2.7/site-packages/pysollib/main.py, line 359, in main r = pysol_init(app, args) File /usr/local/lib/python2.7/site-packages/pysollib/main.py, line 196, in pysol_init app.loadImages1() File /usr/local/lib/python2.7/site-packages/pysollib/app.py, line 712, in loadImages1 im = loadImage(fn) File /usr/local/lib/python2.7/site-packages/pysollib/tile/tkutil.py, line 276, in makeImage im = PIL_Image(file) File /usr/local/lib/python2.7/site-packages/pysollib/tile/tkutil.py, line 254, in __init__ ImageTk.PhotoImage.__init__(self, image) File /usr/local/lib/python2.7/site-packages/PIL/ImageTk.py, line 115, in __init__ self.paste(image) File /usr/local/lib/python2.7/site-packages/PIL/ImageTk.py, line 180, in paste from PIL import _imagingtk ImportError: cannot import name _imagingtk This happens on 9.3- and 10.[01]-RELEASE on amd64 ___ 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: pysolfc broken?
Hans de Hartog hansdehar...@gmail.com: [root@myhost ~]# pkg install pysolfc Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The following 3 packages will be affected (of 0 checked): New packages to be INSTALLED: pysolfc: 2.0_6 py27-tkinter: 2.7.8_5 py27-pillow: 2.6.0 [pysolfc/pillow complaining about missing TK support] py-pillow was updated a few days ago (version 2.6.0_1) to include the TKINTER option as default[1]. If you are retrieving your packages via an official repository, it should update itself soon. If you are building packages on your own, you may want to update the ports tree and rebuild py-pillow. [1] https://svnweb.freebsd.org/ports?view=revisionrevision=372903 Cheers Marcus ___ 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
mail/thunderbird: ENIGMAIL LIGHTNING are now off by default
I've just upgraded my packages to the latest available from the FreeBSD official repository and thunderbird does not have Enigmail and Lightning. Hmm. Looks like www/firefox/Makefile.options overrides OPTIONS_DEFAULT from mail/thunderbird/Makefile -- 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
Re: [SOLVED] multimedia/x264 build failure, linker error
It appears I may have missed an announcement somewhere. pkg delete x264 lists the installed dependances make deinstall in multimedia/x264 make install in mulimedia/libx264 make deinstall reinstall clean in the dependant ports, eg mencoder, mplayer, ffmpeg, gstreamer-plugins-x264 So, is multimedia/x264 deprecated now in favour of multimedia/libx264? There's nothing in /usr/ports/UPDATING On Saturday 22 November 2014 21:18:50 Dave wrote: Sorry, forgot to mention, did a portsnap fetch update first and uname -a gives Box 1 FreeBSD amd.asgard.uk 9.3-RELEASE-p5 FreeBSD 9.3-RELEASE-p5 #0: Mon Nov 3 22:38:58 UTC 2014 root@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Box 2 FreeBSD webmaker.asgard.uk 9.3-RELEASE-p5 FreeBSD 9.3-RELEASE-p5 #0: Mon Nov 3 22:02:57 UTC 2014 root@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 On Saturday 22 November 2014 20:42:55 Dave wrote: portupgrade -c x264 [Reading data from pkg(8) ... - 1031 packages found - done] [Gathering depends for multimedia/x264 . done] --- Upgrading 'x264-0.136.2358_4' to 'x264-0.142.2455' (multimedia/x264) --- Building '/usr/ports/multimedia/x264' === Cleaning for x264-0.142.2455 === License GPLv2 accepted by the user === Found saved configuration for x264-0.142.2455 === x264-0.142.2455 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by x264-0.142.2455 for building === Extracting for x264-0.142.2455 = SHA256 Checksum OK for x264/x264-snapshot-20140827-2245-stable.tar.bz2. === Patching for x264-0.142.2455 === Applying FreeBSD patches for x264-0.142.2455 === x264-0.142.2455 depends on package: yasm=0.6.0 - found === x264-0.142.2455 depends on file: /usr/local/bin/bash - found === x264-0.142.2455 depends on executable: gmake - found === x264-0.142.2455 depends on executable: pkgconf - found === x264-0.142.2455 depends on shared library: libx264.so - found (/usr/local/lib/libx264.so.136) === x264-0.142.2455 depends on shared library: libgpac.so - found (/usr/local/lib/libgpac.so.2.0.0) === Configuring for x264-0.142.2455 platform: X86_64 system:FREEBSD cli: yes libx264: system shared:no static:no asm: yes interlaced:yes avs: no lavf: no ffms: no mp4: gpac gpl: yes thread:posix opencl:no filters: crop select_every debug: no gprof: no strip: no PIC: no bit depth: 8 chroma format: all You can run 'make' or 'make fprofiled' now. === Building for x264-0.142.2455 dependency file generation... cc -Wshadow -O3 -ffast-math -m64 -O2 -pipe -fstack-protector -fno-strict- aliasing -Wall -I. -I. -I/usr/local/include -std=gnu99 -mpreferred-stack- boundary=5 -fomit-frame-pointer -fno-tree-vectorize -c -o x264.o x264.c cc -Wshadow -O3 -ffast-math -m64 -O2 -pipe -fstack-protector -fno-strict- aliasing -Wall -I. -I. -I/usr/local/include -std=gnu99 -mpreferred-stack- boundary=5 -fomit-frame-pointer -fno-tree-vectorize -c -o input/input.o input/input.c cc -Wshadow -O3 -ffast-math -m64 -O2 -pipe -fstack-protector -fno-strict- aliasing -Wall -I. -I. -I/usr/local/include -std=gnu99 -mpreferred-stack- boundary=5 -fomit-frame-pointer -fno-tree-vectorize -c -o input/timecode.o input/timecode.c cc -Wshadow -O3 -ffast-math -m64 -O2 -pipe -fstack-protector -fno-strict- aliasing -Wall -I. -I. -I/usr/local/include -std=gnu99 -mpreferred-stack- boundary=5 -fomit-frame-pointer -fno-tree-vectorize -c -o input/raw.o input/raw.c cc -Wshadow -O3 -ffast-math -m64 -O2 -pipe -fstack-protector -fno-strict- aliasing -Wall -I. -I. -I/usr/local/include -std=gnu99 -mpreferred-stack- boundary=5 -fomit-frame-pointer -fno-tree-vectorize -c -o input/y4m.o input/y4m.c cc -Wshadow -O3 -ffast-math -m64 -O2 -pipe -fstack-protector -fno-strict- aliasing -Wall -I. -I. -I/usr/local/include -std=gnu99 -mpreferred-stack- boundary=5 -fomit-frame-pointer -fno-tree-vectorize -c -o output/raw.o output/raw.c cc -Wshadow -O3 -ffast-math -m64 -O2 -pipe -fstack-protector -fno-strict- aliasing -Wall -I. -I. -I/usr/local/include -std=gnu99 -mpreferred-stack- boundary=5 -fomit-frame-pointer -fno-tree-vectorize -c -o output/matroska.o output/matroska.c cc -Wshadow -O3 -ffast-math -m64 -O2 -pipe -fstack-protector -fno-strict- aliasing -Wall -I. -I. -I/usr/local/include -std=gnu99 -mpreferred-stack- boundary=5 -fomit-frame-pointer -fno-tree-vectorize -c -o output/matroska_ebml.o output/matroska_ebml.c cc -Wshadow -O3 -ffast-math -m64 -O2 -pipe -fstack-protector -fno-strict- aliasing -Wall -I. -I. -I/usr/local/include -std=gnu99 -mpreferred-stack- boundary=5 -fomit-frame-pointer -fno-tree-vectorize
Re: Caveat: Firefox and Thunderbird not working with latest GTK
On Monday 24 November 2014 11:40:56 Andrea Venturoli wrote: Hello. The box is a 9.3/i386 and I'm using portupgrade to compile ports from source; the desktop environment is XFCE. Yesterday evening I updated some unrelated ports and some dependencies of Firefox and Thunderbird were updated: after that, those two applications were not running properly. The main window would come up, but never be updated anymore; if I typed on the keyboard I could perceive something happening under the hood (other windows popping up, network packets flowing), but I would see nothing on the screen (the main window would stay exactly as it was when it opened). I removed all extensions, but to no avail. I tried portupgrade -Rf thunderbird firefox and let the box compile all night, but again, no luck. So I downgraded all the ports that had been updated and FF and TB started working again. Then I began updating them one at a time and found the culprit to be gtk: when upgrading from 2.24.22_4 to 2.24.25 I get the behaviour described above; after downgrading, both programs work again. I did the same test on another box (10.0/amd64) and got the same results. I found the same here with regard to news/pan. FreeBSD 9.3, AMD64 here. The stalled GUI update symptom occurs after using the search feature. The mouse pointer changes from text selection on moving across the search text box to the paintbrush clear button and clicking that button brings the GUI updates back to life. I'll try the gtk downgrade and report back. Right now I'm running the old version of GTK and I'm fine. I'm unsure whether to file a bug report, tough, since I have no further info to include; OTOH, maybe I'm doing something wrong... I'm willing to do any testing if someone can suggest what to try and where to look. bye Thanks av. ___ 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
xsltproc segfaults
Hi all, I've been having a few xsltproc segfaults in some ports (devel/dbus, devel/dconf) that begin to be a bother... I'm not sure about what could be wrong, I am running 10.1 and trimmed down my CFLAGS with no avail.. For example, in devel/dconf: Makefile:941: recipe for target 'dconf-service.1' failed gmake: *** [dconf-service.1] Segmentation fault (core dumped) # gdb xsltproc xsltproc.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Core was generated by `xsltproc'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libxslt.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxslt.so.2 Reading symbols from /usr/local/lib/libexslt.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexslt.so.8 Reading symbols from /usr/local/lib/libgcrypt.so.20...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgcrypt.so.20 Reading symbols from /usr/local/lib/libgpg-error.so.0...done. Loaded symbols for /usr/local/lib/libgpg-error.so.0 Reading symbols from /usr/local/lib/libxml2.so.2...done. Loaded symbols for /usr/local/lib/libxml2.so.2 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libintl.so.9...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/lib/liblzma.so.5...done. Loaded symbols for /usr/lib/liblzma.so.5 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800a6d16c in exsltDateXpathCtxtRegister () from /usr/local/lib/libexslt.so.8 (gdb) bt #0 0x000800a6d16c in exsltDateXpathCtxtRegister () from /usr/local/lib/libexslt.so.8 #1 0x0100 in ?? () #2 0x08003e00 in ?? () #3 0x01002c80f604 in ?? () #4 0x in ?? () Worse, I've been building my port tree with -g, and strangely, I don't get any debuging information... Activationg memory debug option in libxslt port do not give more than that, too. Does anybody had experience with such problems and found the source? Thanks -- Matthieu Volat ma...@alkumuna.eu pgp8iYKtC7Qiz.pgp Description: OpenPGP digital signature
Re: xsltproc segfaults
On Mon, Nov 24, 2014 at 06:24:18PM +0100, Matthieu Volat wrote: Hi all, I've been having a few xsltproc segfaults in some ports (devel/dbus, devel/dconf) that begin to be a bother... I'm not sure about what could be wrong, I am running 10.1 and trimmed down my CFLAGS with no avail.. For example, in devel/dconf: Makefile:941: recipe for target 'dconf-service.1' failed gmake: *** [dconf-service.1] Segmentation fault (core dumped) # gdb xsltproc xsltproc.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Core was generated by `xsltproc'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libxslt.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxslt.so.2 Reading symbols from /usr/local/lib/libexslt.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexslt.so.8 Reading symbols from /usr/local/lib/libgcrypt.so.20...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgcrypt.so.20 Reading symbols from /usr/local/lib/libgpg-error.so.0...done. Loaded symbols for /usr/local/lib/libgpg-error.so.0 Reading symbols from /usr/local/lib/libxml2.so.2...done. Loaded symbols for /usr/local/lib/libxml2.so.2 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libintl.so.9...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/lib/liblzma.so.5...done. Loaded symbols for /usr/lib/liblzma.so.5 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800a6d16c in exsltDateXpathCtxtRegister () from /usr/local/lib/libexslt.so.8 (gdb) bt #0 0x000800a6d16c in exsltDateXpathCtxtRegister () from /usr/local/lib/libexslt.so.8 #1 0x0100 in ?? () #2 0x08003e00 in ?? () #3 0x01002c80f604 in ?? () #4 0x in ?? () Worse, I've been building my port tree with -g, and strangely, I don't get any debuging information... Activationg memory debug option in libxslt port do not give more than that, too. Because that is not how one with suppose to build with debug :) make WITH_DEBUG=yes Bapt pgp2ldYGCoQqr.pgp Description: PGP signature
Re: ftp/curl broken (patch-lib-asyn-thread.c fails)
On Tue, Nov 25, 2014 at 2:49 AM, Nick Rogers ncrog...@gmail.com wrote: It appears that the ftp/curl port was broken with the very-recent commit update to 7.39.0. I happened to do a svn up and rebuild in the last 30 minutes after the change. Looks like the following patch is no longer necessary as its in the latest version? https://github.com/bagder/curl/commit/d9762a7cdb35e70f8cb0bf1c2f8019e8391616e1 === Patching for curl-7.39.0 === Applying FreeBSD patches for curl-7.39.0 Ignoring previously applied (or reversed) patch. 1 out of 1 hunks ignored--saving rejects to lib/asyn-thread.c.rej = Patch patch-lib-asyn-thread.c failed to apply cleanly. = Patch(es) patch-configure applied cleanly. *** Error code 1 Stop. make: stopped in /usr/ports/ftp/curl -Nick Hi, It should be fixed now. I forgot to add this file to the script. Regards, sunpoet ___ 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: Caveat: Firefox and Thunderbird not working with latest GTK
On 24-11-2014 18:08, Dave wrote: On Monday 24 November 2014 11:40:56 Andrea Venturoli wrote: Hello. The box is a 9.3/i386 and I'm using portupgrade to compile ports from source; the desktop environment is XFCE. Yesterday evening I updated some unrelated ports and some dependencies of Firefox and Thunderbird were updated: after that, those two applications were not running properly. The main window would come up, but never be updated anymore; if I typed on the keyboard I could perceive something happening under the hood (other windows popping up, network packets flowing), but I would see nothing on the screen (the main window would stay exactly as it was when it opened). I removed all extensions, but to no avail. I tried portupgrade -Rf thunderbird firefox and let the box compile all night, but again, no luck. So I downgraded all the ports that had been updated and FF and TB started working again. Then I began updating them one at a time and found the culprit to be gtk: when upgrading from 2.24.22_4 to 2.24.25 I get the behaviour described above; after downgrading, both programs work again. I did the same test on another box (10.0/amd64) and got the same results. I found the same here with regard to news/pan. FreeBSD 9.3, AMD64 here. The stalled GUI update symptom occurs after using the search feature. The mouse pointer changes from text selection on moving across the search text box to the paintbrush clear button and clicking that button brings the GUI updates back to life. I'll try the gtk downgrade and report back. Or update the gtk20 port to 2.24.25_1. This should fix the UI update issues in firefox. -Koop ___ 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
ftp/curl broken (patch-lib-asyn-thread.c fails)
It appears that the ftp/curl port was broken with the very-recent commit update to 7.39.0. I happened to do a svn up and rebuild in the last 30 minutes after the change. Looks like the following patch is no longer necessary as its in the latest version? https://github.com/bagder/curl/commit/d9762a7cdb35e70f8cb0bf1c2f8019e8391616e1 === Patching for curl-7.39.0 === Applying FreeBSD patches for curl-7.39.0 Ignoring previously applied (or reversed) patch. 1 out of 1 hunks ignored--saving rejects to lib/asyn-thread.c.rej = Patch patch-lib-asyn-thread.c failed to apply cleanly. = Patch(es) patch-configure applied cleanly. *** Error code 1 Stop. make: stopped in /usr/ports/ftp/curl -Nick ___ 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
GNOME3 and nvidia-driver
Hi, The latest GNOME3 update doesn't appear to live well with nvidia-driver. I'm attempting to build gnome3, but it's failing during the configure of graphics/cogl (required by graphics/cogl, required by graphics/clutter, required by accessibility/caribou): ... checking for GLIB - version = 2.32.0... yes (version 2.42.0) checking EGL/egl.h usability... no checking EGL/egl.h presence... no checking for EGL/egl.h... no configure: error: Unable to locate required EGL headers === Script configure failed unexpectedly. ... Hmm. Okay, a quick search reveals graphics/libEGL has the headers. # cd /usr/ports/graphics/libEGL make install clean ... === Checking if libEGL already installed === Registering installation for libEGL-10.3.3 pkg-static: libEGL-10.3.3 conflicts with nvidia-driver-340.46 (installs files into the same place). Problematic file: /usr/local/lib/libEGL.so *** Error code 70 Stop. make: stopped in /usr/ports/graphics/libEGL What should I do? Cheers -- Jonathan Chen j...@chen.org.nz ___ 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: GNOME3 and nvidia-driver
On Mon, Nov 24, 2014 at 12:10 PM, Jonathan Chen j...@chen.org.nz wrote: Hi, The latest GNOME3 update doesn't appear to live well with nvidia-driver. I'm attempting to build gnome3, but it's failing during the configure of graphics/cogl (required by graphics/cogl, required by graphics/clutter, required by accessibility/caribou): ... checking for GLIB - version = 2.32.0... yes (version 2.42.0) checking EGL/egl.h usability... no checking EGL/egl.h presence... no checking for EGL/egl.h... no configure: error: Unable to locate required EGL headers === Script configure failed unexpectedly. ... Hmm. Okay, a quick search reveals graphics/libEGL has the headers. # cd /usr/ports/graphics/libEGL make install clean ... === Checking if libEGL already installed === Registering installation for libEGL-10.3.3 pkg-static: libEGL-10.3.3 conflicts with nvidia-driver-340.46 (installs files into the same place). Problematic file: /usr/local/lib/libEGL.so *** Error code 70 Stop. make: stopped in /usr/ports/graphics/libEGL What should I do? Cheers -- Jonathan Chen j...@chen.org.nz Switch to Mate? ;-) I'll be doing this shortly, so it's not entirely facetious. After some time with Gnome3 on Linux, I switched to Mate and have been very happy with it. (Mate is a fork of Gnome2.) Cinnamon is another option. It is GTK3 based, but retains the customisability of Gnome2. I have only very limited experience with it. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ftp/curl broken (patch-lib-asyn-thread.c fails)
On Mon, Nov 24, 2014 at 10:57 AM, Sunpoet Po-Chuan Hsieh sunp...@freebsd.org wrote: On Tue, Nov 25, 2014 at 2:49 AM, Nick Rogers ncrog...@gmail.com wrote: It appears that the ftp/curl port was broken with the very-recent commit update to 7.39.0. I happened to do a svn up and rebuild in the last 30 minutes after the change. Looks like the following patch is no longer necessary as its in the latest version? https://github.com/bagder/curl/commit/d9762a7cdb35e70f8cb0bf1c2f8019e8391616e1 === Patching for curl-7.39.0 === Applying FreeBSD patches for curl-7.39.0 Ignoring previously applied (or reversed) patch. 1 out of 1 hunks ignored--saving rejects to lib/asyn-thread.c.rej = Patch patch-lib-asyn-thread.c failed to apply cleanly. = Patch(es) patch-configure applied cleanly. *** Error code 1 Stop. make: stopped in /usr/ports/ftp/curl -Nick Hi, It should be fixed now. I forgot to add this file to the script. Thanks! I've done that before... It builds correctly now. Regards, sunpoet ___ 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: GNOME3 and nvidia-driver
Hi Jonathan, Am 24.11.2014 um 21:10 schrieb Jonathan Chen: Hi, The latest GNOME3 update doesn't appear to live well with nvidia-driver. I'm attempting to build gnome3, but it's failing during the configure of graphics/cogl (required by graphics/cogl, required by graphics/clutter, required by accessibility/caribou): ... checking for GLIB - version = 2.32.0... yes (version 2.42.0) checking EGL/egl.h usability... no checking EGL/egl.h presence... no checking for EGL/egl.h... no configure: error: Unable to locate required EGL headers === Script configure failed unexpectedly. ... Hmm. Okay, a quick search reveals graphics/libEGL has the headers. # cd /usr/ports/graphics/libEGL make install clean ... === Checking if libEGL already installed === Registering installation for libEGL-10.3.3 pkg-static: libEGL-10.3.3 conflicts with nvidia-driver-340.46 (installs files into the same place). Problematic file: /usr/local/lib/libEGL.so *** Error code 70 Stop. make: stopped in /usr/ports/graphics/libEGL What should I do? For me, the following works as a workaround: 1. Switch back to a console (without using X11) 2. pkg delete -f nvidia-driver-340.46 3. portmaster -a portmaster x11/gnome3 4. pkg delete -f libEGL-10.3.3 5. cd /usr/ports/x11/nvidia-driver make install [ kldload nvidia] After that, you should be able to start X11 again and work as usual. It seems to be no problem without having libEGL installed, because there is a libEGL version from nvidia-driver installed. Of course, it would be better, if someone could solve the conflict of the two ports ;) HTH, Rainer Hurling Cheers -- Jonathan Chen j...@chen.org.nz ___ 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: GNOME3 and nvidia-driver
On Mon, 24 Nov 2014 22:31:41 +0100, Rainer Hurling stated: Hi Jonathan, Am 24.11.2014 um 21:10 schrieb Jonathan Chen: Hi, The latest GNOME3 update doesn't appear to live well with nvidia-driver. I'm attempting to build gnome3, but it's failing during the configure of graphics/cogl (required by graphics/cogl, required by graphics/clutter, required by accessibility/caribou): ... checking for GLIB - version = 2.32.0... yes (version 2.42.0) checking EGL/egl.h usability... no checking EGL/egl.h presence... no checking for EGL/egl.h... no configure: error: Unable to locate required EGL headers === Script configure failed unexpectedly. ... Hmm. Okay, a quick search reveals graphics/libEGL has the headers. # cd /usr/ports/graphics/libEGL make install clean ... === Checking if libEGL already installed === Registering installation for libEGL-10.3.3 pkg-static: libEGL-10.3.3 conflicts with nvidia-driver-340.46 (installs files into the same place). Problematic file: /usr/local/lib/libEGL.so *** Error code 70 Stop. make: stopped in /usr/ports/graphics/libEGL What should I do? For me, the following works as a workaround: 1. Switch back to a console (without using X11) 2. pkg delete -f nvidia-driver-340.46 3. portmaster -a portmaster x11/gnome3 4. pkg delete -f libEGL-10.3.3 5. cd /usr/ports/x11/nvidia-driver make install [ kldload nvidia] After that, you should be able to start X11 again and work as usual. It seems to be no problem without having libEGL installed, because there is a libEGL version from nvidia-driver installed. Of course, it would be better, if someone could solve the conflict of the two ports ;) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194924 -- Jerry pgp4sqK9gOoh7.pgp Description: OpenPGP digital signature
Re: Caveat: Firefox and Thunderbird not working with latest GTK
On Monday 24 November 2014 20:01:25 Koop Mast wrote: On 24-11-2014 18:08, Dave wrote: On Monday 24 November 2014 11:40:56 Andrea Venturoli wrote: Hello. The box is a 9.3/i386 and I'm using portupgrade to compile ports from source; the desktop environment is XFCE. Yesterday evening I updated some unrelated ports and some dependencies of Firefox and Thunderbird were updated: after that, those two applications were not running properly. The main window would come up, but never be updated anymore; if I typed on the keyboard I could perceive something happening under the hood (other windows popping up, network packets flowing), but I would see nothing on the screen (the main window would stay exactly as it was when it opened). I removed all extensions, but to no avail. I tried portupgrade -Rf thunderbird firefox and let the box compile all night, but again, no luck. So I downgraded all the ports that had been updated and FF and TB started working again. Then I began updating them one at a time and found the culprit to be gtk: when upgrading from 2.24.22_4 to 2.24.25 I get the behaviour described above; after downgrading, both programs work again. I did the same test on another box (10.0/amd64) and got the same results. I found the same here with regard to news/pan. FreeBSD 9.3, AMD64 here. The stalled GUI update symptom occurs after using the search feature. The mouse pointer changes from text selection on moving across the search text box to the paintbrush clear button and clicking that button brings the GUI updates back to life. I'll try the gtk downgrade and report back. Or update the gtk20 port to 2.24.25_1. This should fix the UI update issues in firefox. Yes, I saw that update and tried it. It fixed the Pan symptoms too. -Koop ___ 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: GNOME3 and nvidia-driver
On 25 November 2014 at 09:53, Kevin Oberman rkober...@gmail.com wrote: Switch to Mate? ;-) I'll be doing this shortly, so it's not entirely facetious. After some time with Gnome3 on Linux, I switched to Mate and have been very happy with it. (Mate is a fork of Gnome2.) Cinnamon is another option. It is GTK3 based, but retains the customisability of Gnome2. I have only very limited experience with it. Thanks for the suggestions, everyone. I've decided to try out Mate after seeing the _huge_ pile of ports that Gnome3 brings in. The best thing is that Mate works out of the box, and I've got it running now. Cheers. -- Jonathan Chen j...@chen.org.nz ___ 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: [SOLVED] multimedia/x264 build failure, linker error
Le 24/11/2014 à 17:02:35+, Dave a écrit Hi, Sorry but I got the same issue. But I'm not sure I understand your answer. pkg delete x264 lists the installed dependances So you deinstall all package depends on x264-0.136.2358_4 ? make deinstall in multimedia/x264 why you need that ? If you use pkg delete x264-0.136.2358_4 make install in mulimedia/libx264 make deinstall reinstall clean in the dependant ports, eg mencoder, mplayer, ffmpeg, gstreamer-plugins-x264 and those ports don't take automatically the « new » multimedia/libx264 ? Thanks. Regards. JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: lun 24 nov 2014 23:31:40 CET ___ 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: [SOLVED] multimedia/x264 build failure, linker error
On Mon, Nov 24, 2014 at 2:33 PM, Albert Shih albert.s...@obspm.fr wrote: Le 24/11/2014 à 17:02:35+, Dave a écrit Hi, Sorry but I got the same issue. But I'm not sure I understand your answer. pkg delete x264 lists the installed dependances So you deinstall all package depends on x264-0.136.2358_4 ? Better to do: pkg delete -f x264-0.136.2358_4 portmaster multimedia/libx264 multimedia/x264 This assumes that you use portmaster. You can use portupgrade or the basic 'make' commands. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
