Re: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
On Saturday, 23 November 2013 03:00:54 Gerald Pfeifer wrote: On Sat, 23 Nov 2013, Baptiste Daroussin wrote: This should be a definitive fix: http://people.freebsd.org/~bapt/fix-info-subdir.diff Btw that have shown a bug in pkg 1.2.0 rc1 and prior (not in 1.1.x) I have fix in master and will be in 1.2.0 rc2 Can you test? Yes. I just tested this, and in my environment it seems to work (passing the tests described in the Handbook). ports/184178 when you commit this. :) Thank you both for addressing this so quickly :-D signature.asc Description: This is a digitally signed message part.
opvp support in ghostscript
What do I need to do, to get ghostscript's opvp support to work? GS works fine displaying to the screen, but when I specify -sDEVICE=opvp I get Unable to open the initial device, quitting. If I also specify -dINITDEBUG=1 to turn on debug output during gs_init.ps, I get a lot of messages showing progress through the initialization process -- none of which seem to have anything to do with device choice, nor to be much different from what INITDEBUG produces when displaying to the screen -- until END FONTS 219 2605656 1227805 1417680 125870 true 1166 4 0 Unrecoverable error: unknownerror in setdevice Operand stack: --nostringval-- which is not a whole lot more informative than the original message. (When displaying to the screen, which works, the next line after END FONTS ... is END DEVICE ...) Is there any way to turn on debug or tracing, or otherwise get more detail, re what is going on in setdevice and exactly what failed? This is with the 8.3-RELEASE package of Ghostscript 9.05. ___ 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
[QAT] r334709: 4x leftovers
- Update to 0.10.3 stable release - Build ID: 20131124081411-18325 Job owner: flu...@freebsd.org Buildtime: 47 minutes Enddate: Sun, 24 Nov 2013 09:01:06 GMT Revision: r334709 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334709 - Port:multimedia/gstreamer-qt4 0.10.3 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~flu...@freebsd.org/20131124081411-18325-230868/gstreamer-qt4-0.10.3.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~flu...@freebsd.org/20131124081411-18325-230869/gstreamer-qt4-0.10.3.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~flu...@freebsd.org/20131124081411-18325-230870/gstreamer-qt4-0.10.3.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~flu...@freebsd.org/20131124081411-18325-230871/gstreamer-qt4-0.10.3.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131124081411-18325 redports https://qat.redports.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
[QAT] r334705: 4x leftovers, 4x success
- Update devel/ruby-gems to 1.8.28 - Document security issues with 1.8.26 and 1.8.27 (CVE-2013-4287 and CVE-2013-4363) Security: 742eb9e4-e3cb-4f5a-b94e-0e9a39420600 Security: 54237182-9635-4a8b-92d7-33bfaeed84cd - Build ID: 20131124053802-11796 Job owner: swi...@freebsd.org Buildtime: 4 hours Enddate: Sun, 24 Nov 2013 09:33:27 GMT Revision: r334705 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334705 - Port:devel/ruby-gems 1.8.28 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131124053802-11796-230848/ruby19-gems-1.8.28.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131124053802-11796-230849/ruby19-gems-1.8.28.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131124053802-11796-230850/ruby19-gems-1.8.28.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~swi...@freebsd.org/20131124053802-11796-230851/ruby19-gems-1.8.28.log - Port:security/vuxml 1.1_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131124053802-11796-230852/vuxml-1.1_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131124053802-11796-230853/vuxml-1.1_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131124053802-11796-230854/vuxml-1.1_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~swi...@freebsd.org/20131124053802-11796-230855/vuxml-1.1_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131124053802-11796 redports https://qat.redports.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
ports/172547: bsd.destdir.mk fails when DESTDIR is set
Hi, Is there any change someone could look at ports/172547? Without overriding REALPATH I’m unable to install ports into an alternative root path. http://www.freebsd.org/cgi/query-pr.cgi?pr=172547 thanks Rob ___ 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 clamav
On Sun, 24 Nov 2013, Dewayne Geraghty wrote: Thanks to Gerald for addressing this issue per http://svnweb.freebsd.org/ports/head/Mk/bsd.gcc.mk?sortby=dateview=log clamav now builds. Thanks for the confirmation. And sorry for the temporary breakage. Gerald ___ 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: portmaster refuses to use pkgng with local packages
Am 27.10.2013 um 21:11 schrieb Matthew Seaman matt...@freebsd.org: On 27/10/2013 18:53, Axel Rau wrote: I looked at poudriere earlier, but did not recognize that it plays with pkg nicely and also did not like to set up a web server to just serve local jails. I will give it a try. You don't need to set up a webserver, necessarily. If you're using poudriere to build packages on the same machine where you want to install them, then you can just use a file:// URL in your pkg.conf and pkg will dtrt. If you want to maintain a bunch of machines on a network, then using a webserver to distribute the packages is probably easiest overall, but you could NFS mount the repo and use a file:// URL again, or you could use ssh:// to pull the packages down. While trying ports-mgmt/poudriere in my ezjail/portmaster environment, I learned: poudriere can't run at secure level 1, because it loads linux.ko and uses chflags. Regarding moving to pkgng, what are the replacements to portaudit / jailaudit? Thanks, Axel --- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius ___ 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: portmaster refuses to use pkgng with local packages
On 2013-11-24 12:43, Axel Rau wrote: Am 27.10.2013 um 21:11 schrieb Matthew Seaman matt...@freebsd.org: On 27/10/2013 18:53, Axel Rau wrote: I looked at poudriere earlier, but did not recognize that it plays with pkg nicely and also did not like to set up a web server to just serve local jails. I will give it a try. You don't need to set up a webserver, necessarily. If you're using poudriere to build packages on the same machine where you want to install them, then you can just use a file:// URL in your pkg.conf and pkg will dtrt. If you want to maintain a bunch of machines on a network, then using a webserver to distribute the packages is probably easiest overall, but you could NFS mount the repo and use a file:// URL again, or you could use ssh:// to pull the packages down. While trying ports-mgmt/poudriere in my ezjail/portmaster environment, I learned: poudriere can't run at secure level 1, because it loads linux.ko and uses chflags. Regarding moving to pkgng, what are the replacements to portaudit / jailaudit? Have you tried the following setting in etc/poudriere.conf # Disable linux support NOLINUX=yes ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] New mplayer and mencoder snapshot
Dear all, a new tarball is available: https://bsdistfiles.googlecode.com/files/m20131124.tar.bz2 It contains mostly fixes for staging and dependencies. I tested a variety of options on 9/stable on amd64 and i386 and on 8/stable i386, so there is a good chance it 'just works' on your box. Please let me know if there are any show stoppers, I would like to get the port into the ports tree soon. Best regards Riggs ___ 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
void* reference in $WORK/SUBDIRECTORY/HEADER_FILE.H
I've researched that this is a problem which occurs when using CLang to build. Is there a known solution for this? Thanks for reading this. === Building for traverso-0.49.2 -- Traverso 0.49.2 will be built to install into /usr/local getconf: no such configuration parameter `LFS_CFLAGS' -- Check if the system is big endian -- Searching 16 bit integer -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of unsigned short -- Check size of unsigned short - done -- Using unsigned short -- Check if the system is big endian - little endian -- Program pkg-config found (/usr/local/bin/pkg-config) -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found -- Found Qt4: /usr/local/bin/qmake-qt4 (found suitable version 4.8.5, minimum required is 4.3.1) -- checking for module 'redland=1.0.2' -- found redland, version 1.0.16 -- REDLAND Library Found OK -- Looking for wavpack/wavpack.h -- Looking for wavpack/wavpack.h - found -- checking for module 'wavpack=4.40.0' -- found wavpack, version 4.60.1 -- WavPack Library Found OK -- Looking for vorbis/vorbisfile.h -- Looking for vorbis/vorbisfile.h - found -- checking for module 'vorbis=1.1.2' -- found vorbis, version 1.3.3 -- Ogg Vorbis Library Found OK -- Looking for FLAC/export.h -- Looking for FLAC/export.h - found -- FLAC Library Found OK -- Looking for mad.h -- Looking for mad.h - found -- Looking for fftw3.h -- Looking for fftw3.h - found -- checking for module 'fftw3=3.0.0' -- found fftw3, version 3.3.3 -- FFTW3 Library Found OK -- Looking for sys/vfs.h -- Looking for sys/vfs.h - not found -- Looking for sys/stat.h -- Looking for sys/stat.h - found -- Looking for posix_memalign -- Looking for posix_memalign - found -- Looking for mlock -- Looking for mlock - found -- Looking for alsa/asoundlib.h -- Looking for alsa/asoundlib.h - found -- checking for module 'alsa=1.0.0' -- found alsa, version 1.0.27.2 -- ALSA Library Found OK -- Looking for jack/jack.h -- Looking for jack/jack.h - found -- checking for module 'jack=0.100' -- found jack, version 0.121.3 -- Jack Library Found OK cat: /proc/cpuinfo: No such file or directory Build options: Building in mode: RELEASE ALSA support: TRUE Jack support: TRUE PortAudio support : FALSE CoreAudio support : FALSE SLV2 support: TRUE (Using internal library) MP3 read support: TRUE MP3 writing support : FALSE -- Configuring done -- Generating done -- Build files have been written to: /usr/home/raspycat/traverso/work/traverso-0.49.2 [ 1%] Building CXX object src/engine/CMakeFiles/traversoaudiobackend.dir/AudioDevice.o In file included from /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDevice.cpp:27: /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AlsaDriver.h:62:6: warning: 'AlsaDriver::setup' hides overloaded virtual function [-Woverloaded-virtual] int setup(bool capture=true, bool playback=true, const QString pcmName=hw:0, const QString dither=None); ^ /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/Driver.h:49:14: note: hidden overloaded virtual function 'Driver::setup' declared here: different number of parameters (3 vs 4) virtual int setup(bool capture=true, bool playback=true, const QString cardDevice=none); ^ In file included from /usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDevice.cpp:52: /usr/home/raspycat/traverso/work/traverso-0.49.2/src/common/Tsar.h:66:9: error: field has incomplete type 'void *[]' void* _a[]; ^ 1 warning and 1 error generated. *** Error code 1 Stop. make[4]: stopped in /usr/home/raspycat/traverso/work/traverso-0.49.2 *** Error code 1 Stop. make[3]: stopped in /usr/home/raspycat/traverso/work/traverso-0.49.2 *** Error code 1 Stop. make[2]: stopped in /usr/home/raspycat/traverso/work/traverso-0.49.2 *** Error code 1 Stop. make[1]: stopped in /usr/home/raspycat/traverso *** Error code 1 Stop. make: stopped in /usr/home/raspycat/traverso ___ 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: Few missing packages from the new PKG repositories
On Sat, Nov 23, 2013 at 11:34 PM, Mathieu Arnold m...@mat.cc wrote: +--On 23 novembre 2013 16:27:12 +0200 Kimmo Paasiala kpaas...@icloud.com wrote: | Were these left out by accident or why aren’t they included? | | - x11/gnome2, x11/gnome2-lite is in the repo. | | - editors/vim, editors/vim-lite is in the repo as well. The packages are built from the ports tree as it is at 1 UTC every Wednesday, so, if something is broken at that time, like openjpeg was (my fault) many dependencies are not included. You'll have to wait for next week. -- Mathieu Arnold Right, I guessed it was something like that - thanks. -- Daniel Nebdal ___ 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
[QAT] r334788: 1x depend (depend_package in databases/rrdtool), 3x leftovers
SLURM is an open-source resource manager designed for *nix clusters of all sizes. It provides three key functions. First it allocates exclusive and/or non-exclusive access to resources (computer nodes) to users for some duration of time so they can perform work. Second, it provides a framework for starting, executing, and monitoring work (typically a parallel job) on a set of allocated nodes. Finally, it arbitrates contention for resources by managing a queue of pending work. WWW: https://computing.llnl.gov/linux/slurm/ PR: ports/184215 Submitted by: Jason Bacon jwba...@tds.net - Build ID: 20131124202400-59265 Job owner: b...@freebsd.org Buildtime: 9 minutes Enddate: Sun, 24 Nov 2013 20:33:12 GMT Revision: r334788 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334788 - Port:sysutils/slurm-hpc 2.6.4 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20131124202400-59265-231224/slurm-2.6.4.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20131124202400-59265-231225/slurm-2.6.4.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND (DEPEND_PACKAGE IN DATABASES/RRDTOOL) Log: https://qat.redports.org//~b...@freebsd.org/20131124202400-59265-231226/rrdtool-1.4.7_2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20131124202400-59265-231227/slurm-2.6.4.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131124202400-59265 redports https://qat.redports.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
After updating ports, flash plugins for Firefox Opera have gone AWOL
Having gotten past all the difficulties that related to Perl, I have finally managed to update essentially all of my installed ports. (I still have a small problem with the update for ffmpeg(2), but I'll take that up later on.) Unfortunately, after updating all my ports I find that I now have a problem with the flash plugins for both Firefox and Opera... and I could use some help solving these two problems. After updating all my ports I have, among many many other things, all of the following currently installed: firefox-25.0_1,1 opera-12.16 linux-f10-flashplugin-11.2r202.327_1 nspluginwrapper-1.4.4_2 opera-linuxplugins-12.16 (Note: I use both Firefox and Opera, at different times for different purposes.) After updating my ports, I dutifully followed the instructions here for updating the flash support in Firefox (as I have done, many times before): https://www.freebsd.org/doc/handbook/desktop-browsers.html Specifically (and only) I executed this step: nspluginwrapper -v -a -u This produced the following output: Auto-update plugins from /usr/local/lib/browser_plugins Looking for plugins in /usr/local/lib/browser_plugins Auto-update plugins from /usr/local/lib/browser_plugins/linux-f10-flashplugin Looking for plugins in /usr/local/lib/browser_plugins/linux-f10-flashplugin Auto-update plugins from /home/rfg/.mozilla/plugins Looking for plugins in /home/rfg/.mozilla/plugins Then I quit and restarted Firefox. Unfortunately, after these steps entering about:plugins in the Firefox location bar now shows that I have -no- plugins installed. Additionally, upon visiting (in Firefox) a web page that I believe contains flash material, I am getting a notification that I need to install the flash plugin. So, my questions: 1) What did I do wrong? 2) How can I correct the situation and get flash working with Firefox again? Separately and additionally, Opera also now does not seem to believe that it has any flash pulgin installed either. Of course, I would like to correct this problem also. ___ 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: Upgrading Perl... Somebody just shoot me and put me out of my misery!
In message 845a2e7e540e58efd7f05...@atuin.in.mat.cc, Mathieu Arnold m...@freebsd.org wrote: rfg wrote: | Why would _anything_ that is in any way dependent upon the Perl | interpreter need to be rebuilt? In this switch to threads=on, has the | language itself changed? And if not, shouldn't the change to | multi-threading capability within the interpreter be utterly transparent | to (and a non-event for) any and all pre-existing Perl code? | | Obviously, there's something that I'm missing, but I have no idea what it | might be. Because, hum, quite a few things change when you enable threads, some headers bits change, some calls that are noop without become real call with, things like that. Now, it obviously is a non issue with ports that only use perl to run scripts, or p5- ports that are only scripts, but for ports that have XS files that get compiled into .so, they need to get recompiled, and the same goes for every bit of software that includes the interpreter. As there is no simple way to differentiate between those two categories of dependencies, I ask people to rebuild (or reinstall, if you're using binary packages) everything. OK. It is all clear now. Thank you for taking the time to explain. It _does_ all make sense now. I assure you, it does not make me happy at all to have people rebuild everything depending on Perl every two weeks (like it feels I've been doing that for a few months...) Well, I apologize if I cam off as being a bit... um... testy. I'm actually one of the lucky people, I guess, since I only update my ports very infrequently... only once in every several months... so I've managed to miss most of the excitement. :-) (As I mentioned in my original post in this thread, it was late and I was tired when I first posted about all this. Please do forgive me if I seemed at all unappreciative of your hard work, which is clearly of great value, both to me personally and also to countless others.) | I'm *not* claiming that the maintainer didn't have a good reason for | suggesting these rebuilds. I'm only saying that *I* personally still | don't have a good understanding of what the need for this is/was. As the maintainer, I hope my previous bit did explain that a bit better, if things are not that clear, do feel free to point them out and I'll try better. No no. You have now explained the resons for the rebuilds clearly and admirably. It all makes sense. The thing is that all those explanations can't go into UPDATING, we try to keep it short not to confuse people. Yes. I'm glad that we have these mailing lists, and their associated archives, so that people like me with an interest in such arcana can ask and get answers... at least from the subset of port maintainers who, like you, are nicely responsive. Keep up the good work! And thanks again, for everthing. Regards, rfg ___ 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
[QAT] r334799: 1x leftovers, 3x success
- Change master sites - Change maintainer email to @FreeBSD.org - Change Desktop entry file - Support STAGEDIR - Add DOCS Option - Use only one WWW Approved by:pawel / wg (mentors, implicit) - Build ID: 2013112500-52849 Job owner: nemy...@freebsd.org Buildtime: 14 minutes Enddate: Mon, 25 Nov 2013 00:13:42 GMT Revision: r334799 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334799 - Port:games/nelly 1.0_3 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/2013112500-52849-231284/nelly-1.0_3.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/2013112500-52849-231285/nelly-1.0_3.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~nemy...@freebsd.org/2013112500-52849-231286/nelly-1.0_3.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~nemy...@freebsd.org/2013112500-52849-231287/nelly-1.0_3.log -- Buildarchive URL: https://qat.redports.org/buildarchive/2013112500-52849 redports https://qat.redports.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
poudirere behave-alike for
I think my question is slightly off-topic, but I think freebsd-ports@ may be the best of many not so good fits: I need to build packages for Solaris and SmartOS. My first choice would be ports, which unfortunately are not very well suited to cross-building. Instead I use, as many people, pkgsrc. I would like to leverage pkgsrc with something like poudriere, especially as I have ZFS and zones in Solaris/SmartOS. I found in a message on the DragonFlyBSD list http://leaf.dragonflybsd.org/mailarchive/users/2013-01/msg8.html a mention of poudriere being used on DragonFly/pkgsrc. Does anybody know of the state of this piece of software? The git repos I can find on google are stale links. As etoilebsd is referenced in the mail from DragonFly, I chose to ask here first. To all of you, have a nice week, cheers, -- Christopher TZ: GMT + 1h GnuPG/GPG: 0xE8DE2C14 FreeBSD 9.2-STABLE #1 r256184: Thu Oct 10 19:12:54 CEST 2013 c...@dijkstra.cruwe.de:/usr/obj/usr/home/cjr/media/src/freebsd/base/stable/9/sys/GEN_WDTRACE Punctuation matters: Lets eat Grandma. or Lets eat, Grandma. - Punctuation saves lives. A panda eats shoots and leaves. or A panda eats, shoots, and leaves. - Punctuation teaches proper biology. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (RFC 1925) ___ 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
Release maintainership of japanese/skk-jisyo
I quit using SKK. Please reset maintainer of following ports. - japanese/skk-jisyo - japanese/skk-jisyo-cdb Rgds, -- `whois vmeta.jp | nkf -w` meta m...@vmeta.jp ___ 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: Upgrading Perl... Somebody just shoot me and put me out of my misery!
Am 22.11.2013 12:52, schrieb Mathieu Arnold: +--On 22 novembre 2013 00:25:26 -0800 Ronald F. Guilmette r...@tristatelogic.com wrote: | AUTHOR: m...@freebsd.org Cough, cough, yeah, I mostly wrote that. | portupgrade -o lang/perl5.16 -f perl-5.14.\* At that time, that line was right. Now, after that, the perl packages name which had the same name (all named perl) and were conflicting and were renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the non default ones, that are 5.12, 5.14 and 5.18. | pkg_info says that at present I have perl5.14-5.14.4_3 installed. So | excuse my french, but why the fuck didn't the command: | |portupgrade -o lang/perl5.16 -f perl-5.14.\* Now, as you can see, your perl is not named perl-5.14 but perl5.14-5.14.4_3, so, you should change that line to : portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3 I'll commit an update to that right now. Please use ... -f perl*5.14* - that should settle old and new installations. And perhaps while at it, we need to tell users to _enable_ the THREADED option in the younger UPDATING entry when make ... config is run. And we should consider reintroducting scripts to help with the updates that avoid reinstalling indirect dependencies. Those we know need to be rebuilt should just get version bumped and that should be it. ___ 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: Upgrading Perl... Somebody just shoot me and put me out of my misery!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 23.11.2013 23:25, schrieb Matthew Seaman: On 23/11/2013 22:12, Ronald F. Guilmette wrote: and you will thus need to recompile all ports that depend on Perl. This is the part that is still utterly baffling. Why would _anything_ that is in any way dependent upon the Perl interpreter need to be rebuilt? In this switch to threads=on, has the language itself changed? And if not, shouldn't the change to multi-threading capability within the interpreter be utterly transparent to (and a non-event for) any and all pre-existing Perl code? Obviously, there's something that I'm missing, but I have no idea what it might be. Technically, you don't actually need to recompile something that's pure perl, or that only requires perl to run some scripts. However everything that has a binary interface with perl -- XS modules, software with embedded perl interpreters -- certainly will need recompiling to match the new threaded ABI that has now become the default. The advice to 'recompile everything that depends on perl' is overkill, but it's a simple way to be sure that you have in fact recompiled everything necessary. Picking out only those ports that really needed to be recompiled would require a procedure too unweildy to be usefully described in UPDATING. Well, we might want to revive a Makefile target or script that helped with that. If we have that in place, perhaps as separate perl-upgrade-helper port, we don't need lengthy fragile explanations... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlKS7/EACgkQvmGDOQUufZXlgwCeK/ddZ9nWPVTzZltLqutKYPVH Io8AnjuXprpF3hL36Wknpi5PrKrj0a5h =du2J -END PGP SIGNATURE- ___ 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: Upgrading Perl... Somebody just shoot me and put me out of my misery!
Am 23.11.2013 12:20, schrieb Mark Martinec: On Friday 22 November 2013 21:40:07 Ronald F. Guilmette wrote: Now, one last little thing... The note in the UPDATING file dated 20131120 gives essentially the same instructions as the one dated 20131023, *however* it also contains this: 1) Change the option in lang/perl5.16: make -C /usr/ports/lang/perl5.16 config HUH?? I don't understand this at all. What exactly is the option that we are changing here? And what does it matter to anything? It would be Nice if this were entierly less opaque. $ man ports [...] config Configure OPTIONS for this port using dialog4ports(1). And what does it matter to anything? Gives you a choice to re-think your existing/chosen port options. For example, a new default is now THREADS, but you may not like it, as it somewhat increases the memory usage and requires to rebuild all perl modules. Which shows an interesting facet of this whole tedious process: We're doing a lousy job of explaining the options to unsavvy users, and we're also doing a lousy job of tracking options. Perhaps we should just slash down the options and go more for build the default - it also reduces testing complexity and would give for a more uniform ports experience for everyone (packages use default options anyways). I would even go that far to propose killing some common options such as NLS DOCS EXAMPLES and replace them by a make globcalconfig that sets them system-wide through make.conf, so that we don't need to set/reset them each and every time a port changes options, nor even offer them. ___ 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: Upgrading Perl... Somebody just shoot me and put me out of my misery!
On 2013-11-25 07:40, Matthias Andree wrote:
Am 23.11.2013 12:20, schrieb Mark Martinec:
On Friday 22 November 2013 21:40:07 Ronald F. Guilmette wrote:
Now, one last little thing...
The note in the UPDATING file dated 20131120 gives essentially the same
instructions as the one dated 20131023, *however* it also contains this:
1) Change the option in lang/perl5.16:
make -C /usr/ports/lang/perl5.16 config
HUH?? I don't understand this at all. What exactly is the option that
we are changing here? And what does it matter to anything?
It would be Nice if this were entierly less opaque.
$ man ports
[...]
config Configure OPTIONS for this port using dialog4ports(1).
And what does it matter to anything?
Gives you a choice to re-think your existing/chosen port options.
For example, a new default is now THREADS, but you may not like
it, as it somewhat increases the memory usage and requires
to rebuild all perl modules.
Which shows an interesting facet of this whole tedious process:
We're doing a lousy job of explaining the options to unsavvy users, and
we're also doing a lousy job of tracking options. Perhaps we should
just slash down the options and go more for build the default - it
also reduces testing complexity and would give for a more uniform ports
experience for everyone (packages use default options anyways).
I would even go that far to propose killing some common options such as
NLS DOCS EXAMPLES and replace them by a make globcalconfig that sets
them system-wide through make.conf, so that we don't need to set/reset
them each and every time a port changes options, nor even offer them.
${opt}_DESC is limited, but help/explanation can be given in pkg-help.
___
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: Upgrading Perl... Somebody just shoot me and put me out of my misery!
Am 25.11.2013 07:53, schrieb olli hauer:
On 2013-11-25 07:40, Matthias Andree wrote:
Am 23.11.2013 12:20, schrieb Mark Martinec:
On Friday 22 November 2013 21:40:07 Ronald F. Guilmette wrote:
Now, one last little thing...
The note in the UPDATING file dated 20131120 gives essentially the same
instructions as the one dated 20131023, *however* it also contains this:
1) Change the option in lang/perl5.16:
make -C /usr/ports/lang/perl5.16 config
HUH?? I don't understand this at all. What exactly is the option that
we are changing here? And what does it matter to anything?
It would be Nice if this were entierly less opaque.
$ man ports
[...]
config Configure OPTIONS for this port using dialog4ports(1).
And what does it matter to anything?
Gives you a choice to re-think your existing/chosen port options.
For example, a new default is now THREADS, but you may not like
it, as it somewhat increases the memory usage and requires
to rebuild all perl modules.
Which shows an interesting facet of this whole tedious process:
We're doing a lousy job of explaining the options to unsavvy users, and
we're also doing a lousy job of tracking options. Perhaps we should
just slash down the options and go more for build the default - it
also reduces testing complexity and would give for a more uniform ports
experience for everyone (packages use default options anyways).
${opt}_DESC is limited, but help/explanation can be given in pkg-help.
Granted, but last time I checked I did not have a Help button on
dialog4ports. Either none of the ports I've seen offering options offer
pkg-help, or dialog4ports needs to be told to feed pkg-help through $PAGER.
___
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: poudirere behave-alike for
On 25/11/2013 11:45, Christopher J. Ruwe wrote: I think my question is slightly off-topic, but I think freebsd-ports@ may be the best of many not so good fits: I need to build packages for Solaris and SmartOS. My first choice would be ports, which unfortunately are not very well suited to cross-building. Instead I use, as many people, pkgsrc. I would like to leverage pkgsrc with something like poudriere, especially as I have ZFS and zones in Solaris/SmartOS. I found in a message on the DragonFlyBSD list http://leaf.dragonflybsd.org/mailarchive/users/2013-01/msg8.html a mention of poudriere being used on DragonFly/pkgsrc. Does anybody know of the state of this piece of software? The git repos I can find on google are stale links. As etoilebsd is referenced in the mail from DragonFly, I chose to ask here first. The freebsd ports tree at http://svnweb.freebsd.org/ports/head/ports-mgmt/poudriere/ shows poudriere source is downloaded from http://fossil.etoilebsd.net/poudriere/tarball/ I think the best place to start would be the DPorts as it mentions they needed to patch it to work on Dragonfly - those patches will highlight the changes you need to make so should be the best start. ___ 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: poudirere behave-alike for
On 11/25/2013 02:15, Christopher J. Ruwe wrote: I think my question is slightly off-topic, but I think freebsd-ports@ may be the best of many not so good fits: I need to build packages for Solaris and SmartOS. My first choice would be ports, which unfortunately are not very well suited to cross-building. Instead I use, as many people, pkgsrc. I would like to leverage pkgsrc with something like poudriere, especially as I have ZFS and zones in Solaris/SmartOS. I found in a message on the DragonFlyBSD list http://leaf.dragonflybsd.org/mailarchive/users/2013-01/msg8.html a mention of poudriere being used on DragonFly/pkgsrc. I was involved in that referenced email. The first point to make is that currently ports is *not* an option for solaris or SmartOS, regardless of its ability to cross compile. Point #2 is that I want to try to bring ports to the solaris-alike family in the future (aka sunports), but work on this hasn't started yet, and adapting solaris will be a lot more work than adapting DragonFly was (and believe me DF was *A LOT* of work. Point #3 is that if I were still heavily involved in pkgsrc, I would probably create a branch of poudriere that supported pkgsrc. It is something I would recommend highly to the pkgsrc community. However, it suffers greatly from Not invented Here syndrome, so most consider (without proper evaluation) that pkgsrc tools are more or less equivalent. The fact is that they are not. Does anybody know of the state of this piece of software? The git repos I can find on google are stale links. As etoilebsd is referenced in the mail from DragonFly, I chose to ask here first. There is no poudriere-for-pkgsrc. The current poudriere branches are here: https://fossil.etoilebsd.net/poudriere/brlist For pkgsrc your choices are: http://pkgsrc.se/pkgtools/distbb http://pkgsrc.se/pkgtools/pbulk Here's a recent post about setting up pbulk: http://mail-index.netbsd.org/pkgsrc-users/2013/11/09/msg018881.html In general its poorly documented and difficult to set up parallel building. The script above is yet another attempt to reduce the complexity but I don't think either pbulk or distcc have nearly the polish or features that poudriere has. But take that with a grain of salt because I haven't used either in a long time. One more thing: SmartOS not only uses pkgsrc officially, they have a full builder farm that makes a full set of packages quarterly packages available. It also works on other illumos platforms. The best approach is just use their work. Another tutorial how to set up bulk build: http://www.perkin.org.uk/posts/distributed-chrooted-pkgsrc-bulk-builds.html info about packages already built: http://www.perkin.org.uk/posts/whats-new-in-pkgsrc-2013Q2.html You might want to check out the reset of www.perkin.org.uk for interesting posts. John ___ 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
