databases/ip4r
Maintainer nudge (timeout?) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190104 -- Michelle Sullivan http://www.mhix.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
[no subject]
dear maintainer , please add to chromium PepperFlash Chrome PDF Viewer ___ 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
FF 30 XPCOM and xpcshell
Hi, FF seems really broken now. It cannot start because of an error: .. XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so: Shared object libsqlite3.so.8 not found, required by libxul.so Couldn't load XPCOM. .. I think this can be repaired when FF is reinstalled, but that doesn't work because xpcshell coredumps at installation. Has anyone an idea how to solve this? Regards, Marco -- Lord, defend me from my friends; I can account for my enemies. -- Charles D'Hericault ___ 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] 360246: 3x depend (fetch in japanese/kappa20), 78x success, 4x ignored: you must fetch the distribution manually. please access http://www.adobe.com/products/flex/sdk/ with a web browser. please
Resetting maintainership on ports that have not been staged and without any pending PR With hat: portmgr - Build ID: 20140702192201-38449 Job owner: anto...@freebsd.org Buildtime: 38 hours Enddate: Fri, 04 Jul 2014 09:50:26 GMT Revision: 360246 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=360246 - Port:japanese/alias-fonts 1.0_8 Buildgroup: 8.4-QAT/amd64 Buildstatus: DEPEND (FETCH IN JAPANESE/KAPPA20) Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365734/ja-k20fonts-0.396_6.log Buildgroup: 8.4-QAT/i386 Buildstatus: DEPEND (FETCH IN JAPANESE/KAPPA20) Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365735/ja-k20fonts-0.396_6.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365736/ja-alias-fonts-1.0_8.log Buildgroup: 9.2-QAT/i386 Buildstatus: DEPEND (FETCH IN JAPANESE/KAPPA20) Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365737/ja-k20fonts-0.396_6.log - Port:japanese/cannadic 0.95c_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365738/ja-cannadic-0.95c_2.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365739/ja-cannadic-0.95c_2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365740/ja-cannadic-0.95c_2.log Buildgroup: 9.2-QAT/i386 Buildstatus: FETCH Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365741/ja-cannadic-0.95c_2.log - Port:japanese/fcitx-anthy 0.1.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365742/ja-fcitx-anthy-0.1.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365743/ja-fcitx-anthy-0.1.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365744/ja-fcitx-anthy-0.1.1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365745/ja-fcitx-anthy-0.1.1.log - Port:japanese/flex-sdk 2.0.1_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: IGNORED: YOU MUST FETCH THE DISTRIBUTION MANUALLY. PLEASE ACCESS HTTP://WWW.ADOBE.COM/PRODUCTS/FLEX/SDK/ WITH A WEB BROWSER. PLEASE PLACE THE DOWNLOADED FLEX_SDK_2_JA.ZIP IN /USR/PORTS/DISTFILES AND RE-RUN MAKE Buildgroup: 8.4-QAT/i386 Buildstatus: IGNORED: YOU MUST FETCH THE DISTRIBUTION MANUALLY. PLEASE ACCESS HTTP://WWW.ADOBE.COM/PRODUCTS/FLEX/SDK/ WITH A WEB BROWSER. PLEASE PLACE THE DOWNLOADED FLEX_SDK_2_JA.ZIP IN /USR/PORTS/DISTFILES AND RE-RUN MAKE Buildgroup: 9.2-QAT/amd64 Buildstatus: IGNORED: YOU MUST FETCH THE DISTRIBUTION MANUALLY. PLEASE ACCESS HTTP://WWW.ADOBE.COM/PRODUCTS/FLEX/SDK/ WITH A WEB BROWSER. PLEASE PLACE THE DOWNLOADED FLEX_SDK_2_JA.ZIP IN /USR/PORTS/DISTFILES AND RE-RUN MAKE Buildgroup: 9.2-QAT/i386 Buildstatus: IGNORED: YOU MUST FETCH THE DISTRIBUTION MANUALLY. PLEASE ACCESS HTTP://WWW.ADOBE.COM/PRODUCTS/FLEX/SDK/ WITH A WEB BROWSER. PLEASE PLACE THE DOWNLOADED FLEX_SDK_2_JA.ZIP IN /USR/PORTS/DISTFILES AND RE-RUN MAKE - Port:japanese/guesswork-classic 0.0.3_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365750/ja-guesswork-classic-0.0.3_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365751/ja-guesswork-classic-0.0.3_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~anto...@freebsd.org/20140702192201-38449-365752/ja-guesswork-classic-0.0.3_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log:
Re: Patch (not perfect but half way there) for DBIx::SearchBuilder...
First, Thanks Matthew and Dimitry, and indeed Jesse is still listed as the maintainer - however I have had no reply from him over the last few weeks, I could be wrong but I think he no longer works for Best Practical. Matthew Seaman wrote: On 03/07/2014 03:52, Michelle Sullivan wrote: Matthew, Demon (cc'd you two specifically because the patch affects ports you maintain directly) I created a patch a while ago and sent it off to Jesse and the RT-Users mailing list to fix extremely slow loading of tickets for Request-Tracker. The patch is for DBIx::Searchbuilder-Fields() and you can see it here: https://rt.cpan.org/Public/Ticket/Attachment/WithHeaders/733854 (bug: https://rt.cpan.org/Public/Bug/Display.html?id=96902 ) If it were to be shipped as an 'option' in FreeBSD ports would it be attached to DBIx::SearchBuilder or RT 4.x? (the patch is against DBIx::SearchBuilder, but very specifically affects RT) The rt4x ports can't patch files belonging to DBIx::Searchbuilder -- Thought so but thought I'd check... would be a bit complex to do a slave port... that's not allowed. The options are: * Unconditionally patch DBIx::Searchbuilder -- given the patch hasn't been accepted upstream and it looks like it could have a deleterious impact in some setups, this doesn't seem a good idea to me Well actually I could dix it to make it case sensitive, (which would be the correct thing to do) but it's likely others are using it in a non case sensitive way - this would affect MySQL users in that multiple calls would be made for each case (but not deleterious because it'll just store the same results under different cases) ... the main problem with the whole thing is if applications are using it and are not using the correct case then it won't return the correct information (if anything at all) ... however the flipside is if people have multiple schema's with the same table names in different case then results will be unpredictable... which brings to another issue... 2 schemas with the same table names in the same DB and with or without the patch the returned results would be unpredictable. * Add an option to DBIx::SearchBuilder -- Apply the patch only by user choice. Doesn't help with pre-compiled packages, but seems like a reasonable alternative to me. Sounds good to me - I'll make a patch if I don't get any response from Jesse within a reasonable time frame. * Do nothing -- Means you'ld have to maintain a locally modified version of DBIx::SearchBuilder Not preferred - it caused me huge amounts of pain and I'm sure others will have had the same issue - I should share my results. I think if you prepared a patch implementing the second case for the databases/p5-DBIx-SearchBuilder port to improve performance under high network latency (which should be off by default, so not changing behaviour for other users unexpectedly) there's a good chance we'd accept it. Yup - as above.. will give Jesse time now that I have 'officially' logged a bug against DBIx::SearchBuilder. For a brief background on it... I've been trying to upgrade SORBS Support from RT3.8 to RT4.0 and ticket loads are 4-6 minutes in RT4.0 compared to my old 3.8 system.. The cause being that the new System has a Pg cluster of 4 servers which are in their own datacentres.. the RT 'Front Ends' being in public network space in other datacentres. This is a fairly standard security model.. put your application servers in a DMZ (or public network) and keep the Database Servers locked in their own network.. Just a modest 20ms Ping time and 3 schemas (RT (public), Bucardo and Postgres) causes the ticket load to be 4-6 minutes per ticket - single user, 2 frontends. Patching DBIx::SearchBuilder with the patch in the bug, drops that down to 7 seconds. Yes, the patch is an obvious win for your circumstances. The question is what will it do for the majority of installations where the PostgreSQL database is on the same machine as the web frontend, or on a very nearby machine? It still speeds it up - but it's not as noticeable depending on the database setup ... if it's a user with 119 schema's or *lots* of tables in just one or 2 schema's it will make a huge difference... in my DBs a ticket load using the original call - with nothing but bucardo and RT in the DB causes over 1000 sequential queries.. the the pg_constraints table it hits only has 38 rows! Best Practical have been less than helpful, so thinking about writing a patch for FreeBSD ports as a new 'option' as most of my servers are FreeBSD with my own Pkg Repo... Thoughts? In this case you can quite easily maintain a local patch in your checked-out ports tree. You know about 'make makepatch' ? That will create a files/patch-Mumble file which will be applied automatically every time you re-build
audio/gtmp does not work with nexus7
Hello :-) For some reason gmtp stopped working with my Nexus7... anyone knows why? % gmtp Unable to open ~/.mtpz-data for reading, MTPZ disabled.Device 0 (VID=18d1 and PID=4e41) is a Google Inc (for Asus) Nexus 7 (MTP). Android device detected, assigning default bug flags ^C % uname -a FreeBSD hexagon 10.0-RELEASE-p4 FreeBSD 10.0-RELEASE-p4 #0: Tue Jun 3 13:14:57 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 % pkg info gmtp gmtp-1.3.4_2 Name : gmtp Version: 1.3.4_2 Installed on : Fri Jul 4 12:56:57 CEST 2014 Origin : audio/gmtp Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : audio Licenses : BSD Maintainer : freebsd-ports-lo...@be-well.ilk.org WWW: http://gmtp.sourceforge.net/ Comment: Media Transfer Protocol (MTP) GUI client Options: DOCS : on GTK2 : on GTK3 : off Shared Libs required: libvorbisfile.so.6 libpangoft2-1.0.so.0 libpangocairo-1.0.so.0 libpango-1.0.so.0 libmtp.so.10 libintl.so.9 libid3tag.so.0 libgtk-x11-2.0.so.0 libgthread-2.0.so.0 libgobject-2.0.so.0 libglib-2.0.so.0 libgio-2.0.so.0 libgdk_pixbuf-2.0.so.0 libgdk-x11-2.0.so.0 libgconf-2.so.4 libfreetype.so.6 libfontconfig.so.1 libcairo.so.2 libatk-1.0.so.0 libXrender.so.1 libXrandr.so.2 libXinerama.so.1 libXi.so.6 libXfixes.so.3 libXext.so.6 libXdamage.so.1 libXcursor.so.1 libXcomposite.so.1 libX11.so.6 libFLAC.so.11 Flat size : 596KiB Description: Basic GUI for Microsoft's Media Transfer Protocol (MTP) including file transer and some playlist handling. Any hints welcome :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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
Latest c-icap update
Hello. I've got three box running squid+c-icap+squidclamav. This morning I upgraded c-icap from 0.3.3_1,2 to 0.3.3_2,2 and on an 8.4/amd64 box it suddenly stopped working. Logs started showing lots of: main proc, Child 51981 did not exit normally. Downgrading again to 0.3.3_1,2 solved. The same did not happen on the other two boxes, which are resp. 9.2/amd64 and 9.1/i386 and are happily running the latest version. I see lots of bug reports on the net wrt to c-icap on FreeBSD and signal 11; however I believe they are all referring to old, now solved, problems. Is it so? Is c-icap expected to work on 8.4? Do you want me to collect any data? 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: Latest c-icap update
On 07/04/14 13:20, Andrea Venturoli wrote: Hello. I've got three box running squid+c-icap+squidclamav. This morning I upgraded c-icap from 0.3.3_1,2 to 0.3.3_2,2 and on an 8.4/amd64 box it suddenly stopped working. Logs started showing lots of: main proc, Child 51981 did not exit normally. Downgrading again to 0.3.3_1,2 solved. On closer investigation, downgrading helped, but did not solve. Some sites are accessible, other will yield error. 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: Latest c-icap update
On Fri, 04 Jul 2014 13:20:49 +0200 Andrea Venturoli m...@netfence.it wrote: I see lots of bug reports on the net wrt to c-icap on FreeBSD and signal 11; however I believe they are all referring to old, now solved, problems. Is it so? Those are probably mostly mine. I can't get squidclamav get to work on 10.0 without exiting on signals 10 and 11. I had a correspondence in March directly with Gilles Darold, author of squidclamav. He was helpful, sending me experimental code for testing, but finally instructed me to use a Linux distribution instead I think you will be more sure to have a working solution, until he figures things out. Since then, I am monitoring ports for new versions of c-icap and squidclamav, update every time new port is out, enable squidclamav in squid configuration only to see it crashing after a few minutes, then disabling it back. My PR opened here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190336 -- Marko Cupać ___ 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: Latest c-icap update
On 07/04/14 14:40, Marko Cupać wrote: On Fri, 04 Jul 2014 13:20:49 +0200 Andrea Venturoli m...@netfence.it wrote: I see lots of bug reports on the net wrt to c-icap on FreeBSD and signal 11; however I believe they are all referring to old, now solved, problems. Is it so? Those are probably mostly mine. I can't get squidclamav get to work on 10.0 without exiting on signals 10 and 11. Hello. It's strange it gives problems on 8 and 10, while I'm using it without problems on 9... Did you have the chance to try FreeBSD 9? 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: Latest c-icap update
Am Fri, 04 Jul 2014 13:20:49 +0200 schrieb Andrea Venturoli m...@netfence.it: I see lots of bug reports on the net wrt to c-icap on FreeBSD and signal 11; however I believe they are all referring to old, now solved, problems. Is it so? I am running c-icap on 10.0-RELEASE and have been waiting for the right time to address this issue. From the very beginning I have been observing these numerous signal 11 kernel errors in my syslog. I am currently the only user using squid+c-icap+squidclamav on my FreeBSD server. In spite of the above errors I could not yet detect any restrictions or errors on the application level e.g. when browsing the internet. This is the reason why I have delayed any PR on this. Regards, Peter ___ 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
kde4 packages, WITHOUT_NEW_XORG fails
I have run into a problem trying to recompile the KDE4 packages with WITHOUT_NEW_XORG=YES. From the CHANGES file: 20140416: AFFECTS: users of x11/xorg graphics/dri graphics/libGL and related ports AUTHOR: x...@freebsd.org The default xorg version has been switched on FreeBSD 10-STABLE and FreeBSD 9-STABLE. To upgrade graphics/libGL, graphics/dri and related MESA ports, it is necessary to first remove the old versions of those ports. No special upgrade procedure is needed for xorg ports but it is necessary to recompile all xorg drivers (xf86-*) and other ports that depend on the xserver version, including emulators/virtualbox-ose-additions. Portrevisions have been bumped where needed, but users of drivers not in the ports tree will need to recompile those. If it is important to stay on the old versions, it is possible to specify WITHOUT_NEW_XORG= in /etc/make.conf to get the old xorg distribution. My make.conf file: WITH_PKGNG=yes WITHOUT_NEW_XORG=yes I did portsnap fetch update, and then did: # cd /usr/ports/x11/kde4 # make missing /tmp/missing_files I massaged the /tmp/missing_files to use pkg to try to download a package if it was in the repository. If they were not, I then tried to use 'make BATCH=YES install' to compile and install the port. Here is the output of the script, showing the errors for the ports that did not compile. x11-themes/kdeartwork4 deskutils/kdeplasma-addons x11-clocks/kdetoys4 x11/kde4-workspace net/kget net/krdc x11-clocks/ktux graphics/libEGL graphics/libglesv2 print/indexinfo graphics/libglapi multimedia/libdvdcss Output: + p x11-themes/kdeartwork4 + pkg install x11-themes/kdeartwork4 Updating repository catalogue pkg: No packages matching 'x11-themes/kdeartwork4' available in the repositories + cd /usr/ports/x11-themes/kdeartwork4 + make BATCH=yes install ===Verifying install for /usr/local/lib/libkworkspace.so in /usr/ports/x11/kde4-workspace === kde-workspace-4.11.9 requires modern libGL. Please, set WITH_NEW_XORG and update your ports. *** Error code 1 Stop in /usr/ports/x11/kde4-workspace. *** Error code 1 Stop in /usr/ports/x11-themes/kdeartwork4. + p deskutils/kdeplasma-addons + pkg install deskutils/kdeplasma-addons Updating repository catalogue pkg: No packages matching 'deskutils/kdeplasma-addons' available in the repositories + cd /usr/ports/deskutils/kdeplasma-addons + make BATCH=yes install ===Verifying install for /usr/local/lib/libkworkspace.so in /usr/ports/x11/kde4-workspace === kde-workspace-4.11.9 requires modern libGL. Please, set WITH_NEW_XORG and update your ports. *** Error code 1 Stop in /usr/ports/x11/kde4-workspace. *** Error code 1 Stop in /usr/ports/deskutils/kdeplasma-addons. + p x11-clocks/kdetoys4 + pkg install x11-clocks/kdetoys4 Updating repository catalogue pkg: No packages matching 'x11-clocks/kdetoys4' available in the repositories + cd /usr/ports/x11-clocks/kdetoys4 + make BATCH=yes install === Staging for kdetoys-4.12.5 ===Verifying install for /usr/local/bin/ktux in /usr/ports/x11-clocks/ktux ===Verifying install for /usr/local/lib/libkworkspace.so in /usr/ports/x11/kde4-workspace === kde-workspace-4.11.9 requires modern libGL. Please, set WITH_NEW_XORG and update your ports. *** Error code 1 Stop in /usr/ports/x11/kde4-workspace. *** Error code 1 Stop in /usr/ports/x11-clocks/ktux. *** Error code 1 Stop in /usr/ports/x11-clocks/kdetoys4. + p x11/kde4-workspace + pkg install x11/kde4-workspace Updating repository catalogue pkg: No packages matching 'x11/kde4-workspace' available in the repositories + cd /usr/ports/x11/kde4-workspace + make BATCH=yes install === kde-workspace-4.11.9 requires modern libGL. Please, set WITH_NEW_XORG and update your ports. *** Error code 1 Stop in /usr/ports/x11/kde4-workspace. + p net/kget + pkg install net/kget Updating repository catalogue kg: No packages matching 'net/kget' available in the repositories + cd /usr/ports/net/kget + make BATCH=yes install ===Verifying install for /usr/local/lib/libkworkspace.so in /usr/ports/x11/kde4-workspace === kde-workspace-4.11.9 requires modern libGL. Please, set WITH_NEW_XORG and update your ports. *** Error code 1 Stop in /usr/ports/x11/kde4-workspace. *** Error code 1 Stop in /usr/ports/net/kget. + p net/krdc + pkg install net/krdc Updating repository catalogue pkg: No packages matching 'net/krdc' available in the repositories + cd /usr/ports/net/krdc + make BATCH=yes install === Building for krdc-4.12.5 [ 83%] Built target krdc /usr/ports/net/krdc/work/krdc-4.12.5/vnc/vncclientthread.cpp: In member function 'void VncClientThrea d::clientSetKeepalive()': /usr/ports/net/krdc/work/krdc-4.12.5/vnc/vncclientthread.cpp:610: error: 'TCP_KEEPIDLE' was not decla red in this scope /usr/ports/net/krdc/work/krdc-4.12.5/vnc/vncclientthread.cpp:616: error: 'TCP_KEEPINTVL' was not decl ared in this scope
FreeBSD Port: mail/dspam Bug and Bugfix
Good day, I found a bug in the Makefile for mail/dspam. Line 522 is missing a \ at the end of the file that throws a compilation error. Thanks, ___ Michael Tomasek(Owner) t: 715.309.3556 http://www.complete-solutions.net/ http://www.complete-solutions.net https://rs.complete-solutions.net/ Support Portal - Click Here ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: mail/dspam Bug and Bugfix
Please file a bug on this at https://bugs.freebsd.org/bugzilla/. Otherwise this will likely get lost. (Not that the note here was a bad idea.) On Fri, Jul 4, 2014 at 9:33 AM, Michael Tomasek michael.toma...@complete-solutions.net wrote: Good day, I found a bug in the Makefile for mail/dspam. Line 522 is missing a \ at the end of the file that throws a compilation error. Thanks, ___ Michael Tomasek(Owner) t: 715.309.3556 http://www.complete-solutions.net/ http://www.complete-solutions.net https://rs.complete-solutions.net/ Support Portal - Click Here ___ 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 -- 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: kde4 packages, WITHOUT_NEW_XORG fails
On Fri, Jul 4, 2014 at 9:14 AM, Patrick Powell papow...@astart.com wrote: I have run into a problem trying to recompile the KDE4 packages with WITHOUT_NEW_XORG=YES. From the CHANGES file: 20140416: AFFECTS: users of x11/xorg graphics/dri graphics/libGL and related ports AUTHOR: x...@freebsd.org The default xorg version has been switched on FreeBSD 10-STABLE and FreeBSD 9-STABLE. To upgrade graphics/libGL, graphics/dri and related MESA ports, it is necessary to first remove the old versions of those ports. No special upgrade procedure is needed for xorg ports but it is necessary to recompile all xorg drivers (xf86-*) and other ports that depend on the xserver version, including emulators/virtualbox-ose-additions. Portrevisions have been bumped where needed, but users of drivers not in the ports tree will need to recompile those. If it is important to stay on the old versions, it is possible to specify WITHOUT_NEW_XORG= in /etc/make.conf to get the old xorg distribution. My make.conf file: WITH_PKGNG=yes WITHOUT_NEW_XORG=yes I did portsnap fetch update, and then did: # cd /usr/ports/x11/kde4 # make missing /tmp/missing_files I massaged the /tmp/missing_files to use pkg to try to download a package if it was in the repository. If they were not, I then tried to use 'make BATCH=YES install' to compile and install the port. Unfortunately, many ports have been updated with calls to the Mesa API that do not exist in the WITHOUT_NEW_XORG version of Mesa. As a result, you can no longer build/run recent version of those ports WITHOUT_NEW_XORG. KDE is probably the bast known of these. That leaves two options: 1. Move to the new Xorg versions (which may not support some older hardware) 2. Use an old (and possibly vulnerable) version of KDE The Xorg and KDE folks simply don't provide any other options that I am aware of. -- 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: Latest c-icap update
On Fri, 4 Jul 2014 14:40:57 +0200 Marko Cupać wrote: On Fri, 04 Jul 2014 13:20:49 +0200 Andrea Venturoli m...@netfence.it wrote: I see lots of bug reports on the net wrt to c-icap on FreeBSD and signal 11; however I believe they are all referring to old, now solved, problems. Is it so? Those are probably mostly mine. I can't get squidclamav get to work on 10.0 without exiting on signals 10 and 11. I had a correspondence in March directly with Gilles Darold, author of squidclamav. He was helpful, sending me experimental code for testing, but finally instructed me to use a Linux distribution instead I think you will be more sure to have a working solution, until he figures things out. Since then, I am monitoring ports for new versions of c-icap and squidclamav, update every time new port is out, enable squidclamav in squid configuration only to see it crashing after a few minutes, then disabling it back. My PR opened here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190336 If you build c-icap with the POSIXSEM option enabled does that make any difference? Anything interesting in the server log? What if you set DebugLevel to 10 in the config 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
Bug 191256 - [PATCH] security/libgcrypt: update to 1.6.1
Fri, 4 Jul 2014 13:19:27 -0400 I was just wondering if this port could please be committed. -- Jerry signature.asc Description: PGP signature
Need some help staging mail/tkrat2
I'm working on staging the mail/tkrat2 port and I've run into the following error: ... === Staging for tkrat-2.1.5_5 === tkrat-2.1.5_5 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found === tkrat-2.1.5_5 depends on file: /usr/local/libdata/pkgconfig/xt.pc - found === tkrat-2.1.5_5 depends on shared library: libc-client4.so - found (/usr/local/lib/libc-client4.so.9) === tkrat-2.1.5_5 depends on shared library: libtk84.so - found (/usr/local/lib/libtk84.so.1) === Generating temporary packing list cd lib; /usr/bin/make install.bin if test ! -d /usr/local/lib/`echo tkrat2.1 | sed 's,x,x,'` ; then /usr/bin/install -c -m 0755 -d /usr/local/lib/`echo tkrat2.1 | sed 's,x,x,'` ; fi /usr/bin/install -c -m 0755 ratatosk2.1.so /usr/local/lib/`echo tkrat2.1 | sed 's,x,x,'`/ratatosk2.1.so install: /usr/local/lib/tkrat2.1/ratatosk2.1.so: Permission denied *** [install.bin] Error code 71 Stop in /tmp/ports/tkrat2/work/tkrat-2.1.5/lib. *** [install.bin] Error code 1 Stop in /tmp/ports/tkrat2/work/tkrat-2.1.5. *** [do-install] Error code 1 Stop in /tmp/ports/tkrat2. I've looked through the documentation and don't see anything obvious that I missed. Help? Thanks. -- Stephen J. Roznowski(sj...@verizon.net) ___ 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: kde4 packages, WITHOUT_NEW_XORG fails
On 07/04/14 09:56, Kevin Oberman wrote: On Fri, Jul 4, 2014 at 9:14 AM, Patrick Powell papow...@astart.com mailto:papow...@astart.com wrote: I have run into a problem trying to recompile the KDE4 packages with WITHOUT_NEW_XORG=YES. From the CHANGES file: 20140416: AFFECTS: users of x11/xorg graphics/dri graphics/libGL and related ports AUTHOR: x...@freebsd.org The default xorg version has been switched on FreeBSD 10-STABLE and FreeBSD 9-STABLE. To upgrade graphics/libGL, graphics/dri and related MESA ports, it is necessary to first remove the old versions of those ports. No special upgrade procedure is needed for xorg ports but it is necessary to recompile all xorg drivers (xf86-*) and other ports that depend on the xserver version, including emulators/virtualbox-ose-additions. Portrevisions have been bumped where needed, but users of drivers not in the ports tree will need to recompile those. If it is important to stay on the old versions, it is possible to specify WITHOUT_NEW_XORG= in /etc/make.conf to get the old xorg distribution. My make.conf file: WITH_PKGNG=yes WITHOUT_NEW_XORG=yes I did portsnap fetch update, and then did: # cd /usr/ports/x11/kde4 # make missing /tmp/missing_files I massaged the /tmp/missing_files to use pkg to try to download a package if it was in the repository. If they were not, I then tried to use 'make BATCH=YES install' to compile and install the port. Unfortunately, many ports have been updated with calls to the Mesa API that do not exist in the WITHOUT_NEW_XORG version of Mesa. As a result, you can no longer build/run recent version of those ports WITHOUT_NEW_XORG. KDE is probably the bast known of these. That leaves two options: 1. Move to the new Xorg versions (which may not support some older hardware) 2. Use an old (and possibly vulnerable) version of KDE The Xorg and KDE folks simply don't provide any other options that I am aware of. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com mailto:rkober...@gmail.com OK, then could they please update the CHANGES file and state that? And/or put a warning in the UPDATING or CHANGES ports file: WITHOUT_NEW_XORG option not supported I appreciate the problems, I was just hoping that there was a trivial solution to 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: Need some help staging mail/tkrat2
You need to hack the Makefiles a lot for staging it. I have got a working copy for this one. On Fri, Jul 4, 2014 at 11:34 PM, Stephen Roznowski sj...@verizon.net wrote: I'm working on staging the mail/tkrat2 port and I've run into the following error: ... === Staging for tkrat-2.1.5_5 === tkrat-2.1.5_5 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found === tkrat-2.1.5_5 depends on file: /usr/local/libdata/pkgconfig/xt.pc - found === tkrat-2.1.5_5 depends on shared library: libc-client4.so - found (/usr/local/lib/libc-client4.so.9) === tkrat-2.1.5_5 depends on shared library: libtk84.so - found (/usr/local/lib/libtk84.so.1) === Generating temporary packing list cd lib; /usr/bin/make install.bin if test ! -d /usr/local/lib/`echo tkrat2.1 | sed 's,x,x,'` ; then /usr/bin/install -c -m 0755 -d /usr/local/lib/`echo tkrat2.1 | sed 's,x,x,'` ; fi /usr/bin/install -c -m 0755 ratatosk2.1.so /usr/local/lib/`echo tkrat2.1 | sed 's,x,x,'`/ratatosk2.1.so install: /usr/local/lib/tkrat2.1/ratatosk2.1.so: Permission denied *** [install.bin] Error code 71 Stop in /tmp/ports/tkrat2/work/tkrat-2.1.5/lib. *** [install.bin] Error code 1 Stop in /tmp/ports/tkrat2/work/tkrat-2.1.5. *** [do-install] Error code 1 Stop in /tmp/ports/tkrat2. I've looked through the documentation and don't see anything obvious that I missed. Help? Thanks. -- Stephen J. Roznowski(sj...@verizon.net) ___ 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: print/cups new 1.7.3 fails on undefined references in http.c
from Matthias Andree: It is compiled as though it should use GNUTLS, but links against OPENSSL (-lssl -lcrypto) - the port maintainer might want to look into this; until then, flip the options to use OPENSSL, then it might work. There is no port maintainer (po...@freebsd.org). I could possibly wait and see if there is an update/correction? I checked the selected options for the failed build of cups: OPENSSL was on, GNUTLS was off. from Dewayne Geraghty: To build without dialogue stuff: cd /usr/ports/print/cups-base # To see options make showconfig # To find the ports unique name, you'll need this to set the port specific options in make make -VUNIQUENAME # To define options in make.conf, similar to pkgsrc though reversed echo cups-base_SET=LIBPAPER /etc/make.conf # To make without dialogue make -DBATCH If you wish to set global options, for all ports or really don't want to lookup the UNIQUENAME echo OPTION_SET=\heimdal_home=/usr\ /etc/make.conf I actually use /usr/ports/port-mgmt/portconf to manage all changes, but that is largely historical. Hope that assists. Dewayne PS You will need to do something? delete? where-ever your previously defined options, via dialoue have been set. I can't help there. Thanks for hints. I'll have to read through the Porters' Handbook. Sort of a nuisance to change options formats in midstream. Now my erratic FreeBSD wi-fi connection quit about 12 hours ago, so I am that much behind with the mail. Tom ___ 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: Need some help staging mail/tkrat2
Am 04.07.2014 19:34, schrieb Stephen Roznowski:
I'm working on staging the mail/tkrat2 port and I've run into the
following error:
...
=== Staging for tkrat-2.1.5_5
=== tkrat-2.1.5_5 depends on file:
/usr/local/libdata/pkgconfig/x11.pc - found
=== tkrat-2.1.5_5 depends on file:
/usr/local/libdata/pkgconfig/xt.pc - found
=== tkrat-2.1.5_5 depends on shared library: libc-client4.so - found
(/usr/local/lib/libc-client4.so.9)
=== tkrat-2.1.5_5 depends on shared library: libtk84.so - found
(/usr/local/lib/libtk84.so.1)
=== Generating temporary packing list
cd lib; /usr/bin/make install.bin
if test ! -d /usr/local/lib/`echo tkrat2.1 | sed 's,x,x,'` ; then
/usr/bin/install -c -m 0755 -d /usr/local/lib/`echo tkrat2.1 | sed 's,x,x,'`
; fi
/usr/bin/install -c -m 0755 ratatosk2.1.so /usr/local/lib/`echo
tkrat2.1 | sed 's,x,x,'`/ratatosk2.1.so
install: /usr/local/lib/tkrat2.1/ratatosk2.1.so: Permission denied
*** [install.bin] Error code 71
Stop in /tmp/ports/tkrat2/work/tkrat-2.1.5/lib.
*** [install.bin] Error code 1
Stop in /tmp/ports/tkrat2/work/tkrat-2.1.5.
*** [do-install] Error code 1
Stop in /tmp/ports/tkrat2.
I've looked through the documentation and don't see anything obvious
that I missed.
Have it install into ${STAGEDIR}${PREFIX}/lib/... - check its Makefile
if it supports DESTDIR, STAGEDIR, INSTDIR or thereabouts, or have a look
at Muhammad's Makefile (you may need to ask him to send it to you).
Also see: https://wiki.freebsd.org/ports/StageDir
___
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
ASSP Port
I have been fighting for some time to get ASSP updated to stage. I will be submitting a PR soon to update but need to do some additional testing. Am requesting that assp be set back to myself as maintainer. Rusty ___ 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: ASSP Port
On 07/04/14 21:57, Rusty Nejdl wrote: I have been fighting for some time to get ASSP updated to stage. I will be submitting a PR soon to update but need to do some additional testing. Am requesting that assp be set back to myself as maintainer. You can include such update in the PR you will submit. BTW there is already an open PR about assp: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186610 What should be done with that? -- Guido Falsi madpi...@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: kde4 packages, WITHOUT_NEW_XORG fails
On Fri, Jul 4, 2014 at 12:03 PM, Patrick Powell papow...@astart.com wrote: On 07/04/14 09:56, Kevin Oberman wrote: On Fri, Jul 4, 2014 at 9:14 AM, Patrick Powell papow...@astart.com wrote: I have run into a problem trying to recompile the KDE4 packages with WITHOUT_NEW_XORG=YES. From the CHANGES file: 20140416: AFFECTS: users of x11/xorg graphics/dri graphics/libGL and related ports AUTHOR: x...@freebsd.org The default xorg version has been switched on FreeBSD 10-STABLE and FreeBSD 9-STABLE. To upgrade graphics/libGL, graphics/dri and related MESA ports, it is necessary to first remove the old versions of those ports. No special upgrade procedure is needed for xorg ports but it is necessary to recompile all xorg drivers (xf86-*) and other ports that depend on the xserver version, including emulators/virtualbox-ose-additions. Portrevisions have been bumped where needed, but users of drivers not in the ports tree will need to recompile those. If it is important to stay on the old versions, it is possible to specify WITHOUT_NEW_XORG= in /etc/make.conf to get the old xorg distribution. My make.conf file: WITH_PKGNG=yes WITHOUT_NEW_XORG=yes I did portsnap fetch update, and then did: # cd /usr/ports/x11/kde4 # make missing /tmp/missing_files I massaged the /tmp/missing_files to use pkg to try to download a package if it was in the repository. If they were not, I then tried to use 'make BATCH=YES install' to compile and install the port. Unfortunately, many ports have been updated with calls to the Mesa API that do not exist in the WITHOUT_NEW_XORG version of Mesa. As a result, you can no longer build/run recent version of those ports WITHOUT_NEW_XORG. KDE is probably the bast known of these. That leaves two options: 1. Move to the new Xorg versions (which may not support some older hardware) 2. Use an old (and possibly vulnerable) version of KDE The Xorg and KDE folks simply don't provide any other options that I am aware of. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com OK, then could they please update the CHANGES file and state that? And/or put a warning in the UPDATING or CHANGES ports file: WITHOUT_NEW_XORG option not supported I appreciate the problems, I was just hoping that there was a trivial solution to them... I have no commit bit, but perhaps someone who does will put a note in CHANGES. I certainly think it would be a good idea. This discussion begs the question of why won't WITH_NEW_XORG work for you? I am aware of some pretty old hardware that simply has no support in recent Xorg servers, but these are pretty old by now. And, as time passes, the bit rot will make more and more things fail with the old code. I am far from an X expert, but a post to x11@ of the failure you see WITH_NEW_XORG including the Xorg.0.log, /etc/make.conf, /etc/src.conf and any Xorg.conf you are using might get things working (and might not). x11@ is a far better place to ask any of the questions about X issues. I should also recommend that, if you have not already tried, move your Xorg.conf aside and let X try to configure itself. It is very rare to require a full configuration these days. Most only need things for added fonts and extra modules. The xorg.conf on my laptop is only about 27 lines long and mostly added fonts. -- 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
[QAT] 360459: 4x leftovers
Attempt to unbreak on freebsd 10, the desthack was not properly quoted - Build ID: 20140703212800-15137 Job owner: anto...@freebsd.org Buildtime: 23 hours Enddate: Fri, 04 Jul 2014 20:55:10 GMT Revision: 360459 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=360459 - Port:print/dvipsk-tetex 5.95a_8 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~anto...@freebsd.org/20140703212800-15137-367058/dvipsk-tetex-5.95a_8.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~anto...@freebsd.org/20140703212800-15137-367059/dvipsk-tetex-5.95a_8.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~anto...@freebsd.org/20140703212800-15137-367060/dvipsk-tetex-5.95a_8.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~anto...@freebsd.org/20140703212800-15137-367061/dvipsk-tetex-5.95a_8.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140703212800-15137 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
Re: kde4 packages, WITHOUT_NEW_XORG fails
On 4-7-2014 22:49, Kevin Oberman wrote: On Fri, Jul 4, 2014 at 12:03 PM, Patrick Powell papow...@astart.com wrote: On 07/04/14 09:56, Kevin Oberman wrote: On Fri, Jul 4, 2014 at 9:14 AM, Patrick Powell papow...@astart.com wrote: I have run into a problem trying to recompile the KDE4 packages with WITHOUT_NEW_XORG=YES. From the CHANGES file: 20140416: AFFECTS: users of x11/xorg graphics/dri graphics/libGL and related ports AUTHOR: x...@freebsd.org The default xorg version has been switched on FreeBSD 10-STABLE and FreeBSD 9-STABLE. To upgrade graphics/libGL, graphics/dri and related MESA ports, it is necessary to first remove the old versions of those ports. No special upgrade procedure is needed for xorg ports but it is necessary to recompile all xorg drivers (xf86-*) and other ports that depend on the xserver version, including emulators/virtualbox-ose-additions. Portrevisions have been bumped where needed, but users of drivers not in the ports tree will need to recompile those. If it is important to stay on the old versions, it is possible to specify WITHOUT_NEW_XORG= in /etc/make.conf to get the old xorg distribution. My make.conf file: WITH_PKGNG=yes WITHOUT_NEW_XORG=yes I did portsnap fetch update, and then did: # cd /usr/ports/x11/kde4 # make missing /tmp/missing_files I massaged the /tmp/missing_files to use pkg to try to download a package if it was in the repository. If they were not, I then tried to use 'make BATCH=YES install' to compile and install the port. Unfortunately, many ports have been updated with calls to the Mesa API that do not exist in the WITHOUT_NEW_XORG version of Mesa. As a result, you can no longer build/run recent version of those ports WITHOUT_NEW_XORG. KDE is probably the bast known of these. That leaves two options: 1. Move to the new Xorg versions (which may not support some older hardware) 2. Use an old (and possibly vulnerable) version of KDE The Xorg and KDE folks simply don't provide any other options that I am aware of. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com OK, then could they please update the CHANGES file and state that? And/or put a warning in the UPDATING or CHANGES ports file: WITHOUT_NEW_XORG option not supported I appreciate the problems, I was just hoping that there was a trivial solution to them... I have no commit bit, but perhaps someone who does will put a note in CHANGES. I certainly think it would be a good idea. This discussion begs the question of why won't WITH_NEW_XORG work for you? I am aware of some pretty old hardware that simply has no support in recent Xorg servers, but these are pretty old by now. And, as time passes, the bit rot will make more and more things fail with the old code. I am far from an X expert, but a post to x11@ of the failure you see WITH_NEW_XORG including the Xorg.0.log, /etc/make.conf, /etc/src.conf and any Xorg.conf you are using might get things working (and might not). x11@ is a far better place to ask any of the questions about X issues. I should also recommend that, if you have not already tried, move your Xorg.conf aside and let X try to configure itself. It is very rare to require a full configuration these days. Most only need things for added fonts and extra modules. The xorg.conf on my laptop is only about 27 lines long and mostly added fonts. ports/UPDATING states: 20140218: AFFECTS: users of KDE SC 4 AUTHOR: k...@freebsd.org KDE SC ports have been updated to 4.12.2. kdeadmin, kdenetwork, kdesdk, and kdetoys ports have been split due to upstream changes. KDE Workspace port has been updated to 4.11.6. It requires modern Mesa libraries, provided by WITH_NEW_XORG knob. To update Xorg ports to newer version follow instructions at https://wiki.freebsd.org/Graphics So it not possible anymore to run KDE4 with WITHOUT_NEW_XORG. -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
[QAT] 360463: 4x leftovers, 4x makefile, 80x success
Nuke NOPORTDOCS. While, here, correct a couple offenders who label examples with PORTDOCS. And, fix a couple WITH_foo invocations. - Build ID: 20140703215000-19779 Job owner: ad...@freebsd.org Buildtime: 24 hours Enddate: Fri, 04 Jul 2014 22:03:24 GMT Revision: 360463 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=360463 - Port:databases/dbtool 1.7_4 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367074/dbtool-1.7_4.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367075/dbtool-1.7_4.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367076/dbtool-1.7_4.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367077/dbtool-1.7_4.log - Port:databases/jakarta-commons-dbutils Buildgroup: 8.4-QAT/amd64 Buildstatus: MAKEFILE Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367078/.txz.log Buildgroup: 8.4-QAT/i386 Buildstatus: MAKEFILE Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367079/.txz.log Buildgroup: 9.2-QAT/amd64 Buildstatus: MAKEFILE Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367080/.txz.log Buildgroup: 9.2-QAT/i386 Buildstatus: MAKEFILE Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367081/.txz.log - Port:databases/java-mybatis 3.0.3_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367082/java-mybatis-3.0.3_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367083/java-mybatis-3.0.3_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367084/java-mybatis-3.0.3_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367085/java-mybatis-3.0.3_1.log - Port:databases/mysql++1 1.7.40_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367086/mysql++1-mysql55-1.7.40_2.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367087/mysql++1-mysql55-1.7.40_2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367088/mysql++1-mysql55-1.7.40_2.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367089/mysql++1-mysql55-1.7.40_2.log - Port:databases/mysql++3 3.1.0 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367090/mysql++-mysql55-3.1.0.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367091/mysql++-mysql55-3.1.0.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367092/mysql++-mysql55-3.1.0.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367093/mysql++-mysql55-3.1.0.log - Port:databases/mysql-q4m 0.9.13_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ad...@freebsd.org/20140703215000-19779-367094/mysql55-q4m-0.9.13_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log:
Re: kde4 packages, WITHOUT_NEW_XORG fails
On 07/04/14 14:23, Koop Mast wrote: On 4-7-2014 22:49, Kevin Oberman wrote: On Fri, Jul 4, 2014 at 12:03 PM, Patrick Powell papow...@astart.com wrote: On 07/04/14 09:56, Kevin Oberman wrote: On Fri, Jul 4, 2014 at 9:14 AM, Patrick Powell papow...@astart.com wrote: I have run into a problem trying to recompile the KDE4 packages with WITHOUT_NEW_XORG=YES. From the CHANGES file: 20140416: AFFECTS: users of x11/xorg graphics/dri graphics/libGL and related ports AUTHOR: x...@freebsd.org The default xorg version has been switched on FreeBSD 10-STABLE and FreeBSD 9-STABLE. To upgrade graphics/libGL, graphics/dri and related MESA ports, it is necessary to first remove the old versions of those ports. No special upgrade procedure is needed for xorg ports but it is necessary to recompile all xorg drivers (xf86-*) and other ports that depend on the xserver version, including emulators/virtualbox-ose-additions. Portrevisions have been bumped where needed, but users of drivers not in the ports tree will need to recompile those. If it is important to stay on the old versions, it is possible to specify WITHOUT_NEW_XORG= in /etc/make.conf to get the old xorg distribution. My make.conf file: WITH_PKGNG=yes WITHOUT_NEW_XORG=yes I did portsnap fetch update, and then did: # cd /usr/ports/x11/kde4 # make missing /tmp/missing_files I massaged the /tmp/missing_files to use pkg to try to download a package if it was in the repository. If they were not, I then tried to use 'make BATCH=YES install' to compile and install the port. Unfortunately, many ports have been updated with calls to the Mesa API that do not exist in the WITHOUT_NEW_XORG version of Mesa. As a result, you can no longer build/run recent version of those ports WITHOUT_NEW_XORG. KDE is probably the bast known of these. That leaves two options: 1. Move to the new Xorg versions (which may not support some older hardware) 2. Use an old (and possibly vulnerable) version of KDE The Xorg and KDE folks simply don't provide any other options that I am aware of. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com OK, then could they please update the CHANGES file and state that? And/or put a warning in the UPDATING or CHANGES ports file: WITHOUT_NEW_XORG option not supported I appreciate the problems, I was just hoping that there was a trivial solution to them... I have no commit bit, but perhaps someone who does will put a note in CHANGES. I certainly think it would be a good idea. This discussion begs the question of why won't WITH_NEW_XORG work for you? I am aware of some pretty old hardware that simply has no support in recent Xorg servers, but these are pretty old by now. And, as time passes, the bit rot will make more and more things fail with the old code. I am far from an X expert, but a post to x11@ of the failure you see WITH_NEW_XORG including the Xorg.0.log, /etc/make.conf, /etc/src.conf and any Xorg.conf you are using might get things working (and might not). x11@ is a far better place to ask any of the questions about X issues. I should also recommend that, if you have not already tried, move your Xorg.conf aside and let X try to configure itself. It is very rare to require a full configuration these days. Most only need things for added fonts and extra modules. The xorg.conf on my laptop is only about 27 lines long and mostly added fonts. ports/UPDATING states: 20140218: AFFECTS: users of KDE SC 4 AUTHOR: k...@freebsd.org KDE SC ports have been updated to 4.12.2. kdeadmin, kdenetwork, kdesdk, and kdetoys ports have been split due to upstream changes. KDE Workspace port has been updated to 4.11.6. It requires modern Mesa libraries, provided by WITH_NEW_XORG knob. To update Xorg ports to newer version follow instructions at https://wiki.freebsd.org/Graphics So it not possible anymore to run KDE4 with WITHOUT_NEW_XORG. -Koop Ahhh!!! I missed that. If this is the case, then perhaps the default for generating the PKGNG repository should be WITH_NEW_XORG? Then we could use the PKGNG respository for KDE4 applications. OR: we could have two repositories: one which uses WITHOUT_NEW_XORG and has the old Xorg drivers and no KDE4 support and one with WITH_NEW_XORG which has the new Xorg drivers and KDE4 support. I think I read some discussion about this possibility but I can't recall the outcome. ___ 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: kde4 packages, WITHOUT_NEW_XORG fails
On Fri, Jul 4, 2014 at 4:15 PM, Patrick Powell papow...@astart.com wrote: On 07/04/14 14:23, Koop Mast wrote: [...] On 4-7-2014 22:49, Kevin Oberman wrote: This discussion begs the question of why won't WITH_NEW_XORG work for you? I am aware of some pretty old hardware that simply has no support in recent Xorg servers, but these are pretty old by now. And, as time passes, the bit rot will make more and more things fail with the old code. I am far from an X expert, but a post to x11@ of the failure you see WITH_NEW_XORG including the Xorg.0.log, /etc/make.conf, /etc/src.conf and any Xorg.conf you are using might get things working (and might not). x11@ is a far better place to ask any of the questions about X issues. I should also recommend that, if you have not already tried, move your Xorg.conf aside and let X try to configure itself. It is very rare to require a full configuration these days. Most only need things for added fonts and extra modules. The xorg.conf on my laptop is only about 27 lines long and mostly added fonts. ports/UPDATING states: 20140218: AFFECTS: users of KDE SC 4 AUTHOR: k...@freebsd.org KDE SC ports have been updated to 4.12.2. kdeadmin, kdenetwork, kdesdk, and kdetoys ports have been split due to upstream changes. KDE Workspace port has been updated to 4.11.6. It requires modern Mesa libraries, provided by WITH_NEW_XORG knob. To update Xorg ports to newer version follow instructions at https://wiki.freebsd.org/ Graphics So it not possible anymore to run KDE4 with WITHOUT_NEW_XORG. -Koop Ahhh!!! I missed that. If this is the case, then perhaps the default for generating the PKGNG repository should be WITH_NEW_XORG? Then we could use the PKGNG respository for KDE4 applications. OR: we could have two repositories: one which uses WITHOUT_NEW_XORG and has the old Xorg drivers and no KDE4 support and one with WITH_NEW_XORG which has the new Xorg drivers and KDE4 support. I think I read some discussion about this possibility but I can't recall the outcome. Your timing is MOST excellent. Koop just announced those repositories were available a few hours ago. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=306646+0+current/freebsd-announce The repositories cover 9.x and 10.x for i386 and amd64. -- 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
FreeBSD Port: observium-0.11.5.2261_1
Hi there, Should this port install using pkgng? [root@NAS ~]# pkg info observium pkg: No package(s) matching observium FreeBSD NAS 10.0-STABLE FreeBSD 10.0-STABLE #1 r264363: Sat Apr 12 13:37:38 CST 2014 dhunt@NAS:/usr/obj/usr/src/sys/GENERIC amd64 Thanks David ___ 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: Some suggestions about PKGNG documentation
Patrick Powell wrote: TUTORIAL: The Savant's Guide To Ports, Packages, PkgNG Try to put a lot of the information about pkgng, repositories, etc. in a single place. I suggest a tutorial format, rather than a user manual format, with references to the various man pages, other documents, etc. Your suggestions sound good to me. Unfortunately, it's not like there's a team of tech writers sitting around waiting for suggestions of things to write and put into the docs. Rather, updating pretty much anything in the documentation -- or the ports for that matter -- requires suggesting the actual changes you want in the form of patches that replace the existing content with your version. http://lists.freebsd.org/mailman/listinfo/freebsd-doc http://www.freebsd.org/docproj/ http://www.freebsd.org/doc/en/books/fdp-primer/book.html After starting down this road, you may decide it's less of an ordeal just to write something yourself and put it up on your own blog. :/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: observium-0.11.5.2261_1
David Hunt wrote: Should this port install using pkgng? [root@NAS ~]# pkg info observium pkg: No package(s) matching observium That only means the port hasn't been installed yet, that's what pkg info is for. It displays information about *installed* packages. For packages you haven't installed yet, use pkg search, e.g. % pkg search -f observium If this returns anything useful, use # pkg install observium to actually install it. After that, feel free to see what the result of % pkg info observium has become now that the package has actually been installed. AvW -- Imbibo, ergo sum. pgp8ZsB7lDP9s.pgp Description: PGP signature
Re: Some suggestions about PKGNG documentation
On Fri, 4 Jul 2014, Mike Brown wrote: Patrick Powell wrote: TUTORIAL: The Savant's Guide To Ports, Packages, PkgNG Try to put a lot of the information about pkgng, repositories, etc. in a single place. I suggest a tutorial format, rather than a user manual format, with references to the various man pages, other documents, etc. Your suggestions sound good to me. Unfortunately, it's not like there's a team of tech writers sitting around waiting for suggestions of things to write and put into the docs. Rather, updating pretty much anything in the documentation -- or the ports for that matter -- requires suggesting the actual changes you want in the form of patches that replace the existing content with your version. The documentation team has a standing offer to either assist with markup or accept content-only submissions and do the markup on them. Clear, useful instructions are the difficult part to create. It helps if the writer is familiar with existing work like the Handbook, but is not required. After starting down this road, you may decide it's less of an ordeal just to write something yourself and put it up on your own blog. :/ It's sometimes easier to do that, but fewer people benefit. ___ 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
Upgrade to sysutils/nut-2.7.2 yesterday broke rc.d scripts by deleting libexec/nut/upsdrvctl
Hi cy, itetcu, An upgrade to the sysutils/nut port happened on Friday July 4, and was portmaster -a’d on my system this morning, and now doesn’t start properly. Specifically rc.d/nut has a prestart command that attempts to run /usr/local/libexec/upsdrvctl start, but that file was deleted by this change. http://svnweb.freebsd.org/ports/head/sysutils/nut/pkg-plist?r1=360497r2=360496pathrev=360497 I didn’t see any descriptions or work-arounds in UPDATING. Any suggestions for how to proceed? Cheers, — Andrew ___ 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: Upgrade to sysutils/nut-2.7.2 yesterday broke rc.d scripts by deleting libexec/nut/upsdrvctl
Hi again, Found it: it has moved to /usr/local/sbin. So the attached patch is needed to the sysutils/nut port. Works for me. nut.in.diff Description: Binary data Cheers, — Andrew On 5 Jul 2014, at 14:14 , Andrew Reilly arei...@bigpond.net.au wrote: Hi cy, itetcu, An upgrade to the sysutils/nut port happened on Friday July 4, and was portmaster -a’d on my system this morning, and now doesn’t start properly. Specifically rc.d/nut has a prestart command that attempts to run /usr/local/libexec/upsdrvctl start, but that file was deleted by this change. http://svnweb.freebsd.org/ports/head/sysutils/nut/pkg-plist?r1=360497r2=360496pathrev=360497 I didn’t see any descriptions or work-arounds in UPDATING. Any suggestions for how to proceed? Cheers, — Andrew ___ 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: Upgrade to sysutils/nut-2.7.2 yesterday broke rc.d scripts by deleting libexec/nut/upsdrvctl
In message f7eee4a9-e6c5-4433-8ad6-d9e1f434e...@bigpond.net.au, Andrew Reilly writes: Hi again, Found it: it has moved to /usr/local/sbin. So the attached patch is = needed to the sysutils/nut port. Works for me. Sorry about that. Must be ESP, just committed it a moment ago. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.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: Upgrade to sysutils/nut-2.7.2 yesterday broke rc.d scripts by deleting libexec/nut/upsdrvctl
On Fri, 4 Jul 2014, Cy Schubert wrote: In message f7eee4a9-e6c5-4433-8ad6-d9e1f434e...@bigpond.net.au, Andrew Reilly writes: Hi again, Found it: it has moved to /usr/local/sbin. So the attached patch is = needed to the sysutils/nut port. Works for me. Sorry about that. Must be ESP, just committed it a moment ago. For me it builds ok, but I get a staging error on install: # uname -mrs FreeBSD 9.3-PRERELEASE i386 # make reinstall === Installing for nut-2.7.2_1 === nut-2.7.2_1 depends on shared library: libgd.so - found (/usr/local/lib/libgd.so.5.0.0) === nut-2.7.2_1 depends on shared library: libnetsnmp.so - found (/usr/local/lib/libnetsnmp.so.30.0.2) === nut-2.7.2_1 depends on shared library: libneon.so - found (/usr/local/lib/libneon.so.27.2.6) === Registering installation for nut-2.7.2_1 pkg-static: lstat(/usr/ports/sysutils/nut/work/stage/usr/local/libexec/nut/al175): No such file or directory pkg-static: lstat(/usr/ports/sysutils/nut/work/stage/usr/local/libexec/nut/apcupsd-ups): No such file or directory pkg-static: lstat(/usr/ports/sysutils/nut/work/stage/usr/local/libexec/nut/riello_ser): No such file or directory pkg-static: lstat(/usr/ports/sysutils/nut/work/stage/usr/local/man/man8/al175.8.gz): No such file or directory pkg-static: lstat(/usr/ports/sysutils/nut/work/stage/usr/local/man/man8/apcupsd-ups.8.gz): No such file or directory pkg-static: lstat(/usr/ports/sysutils/nut/work/stage/usr/local/man/man8/blazer_ser.8.gz): No such file or directory pkg-static: lstat(/usr/ports/sysutils/nut/work/stage/usr/local/man/man8/riello_ser.8.gz): No such file or directory *** [fake-pkg] Error code 74 Stop in /usr/ports/sysutils/nut. *** [install] Error code 1 Stop in /usr/ports/sysutils/nut. *** [reinstall] Error code 1 Stop in /usr/ports/sysutils/nut. -- Greg ___ 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
