Re: Can't seem to build ruby19 or 18.
I can confirm this issue for other ports, too: security/openssl fails with don't know how to make WHOLE_ARCHIVE_FLAG and www/lynx fails with don't know how to make helpdir. As far as I can see, svn revision 341159 still works, at least for lang/ruby19. ___ 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: xmms-wma crashes
On 01/28/14 00:06, Baptiste Daroussin wrote: On Mon, Jan 27, 2014 at 11:25:18PM +0100, Andrea Venturoli wrote: Hello. The box is 9.1p10/i386. As per subject, since the upgrade to 1.0.5_3, xmms started crashing whenever I added a wma file to the playlist. portupgrade -Rf xmms-wma did not help. portdowngrade to 1.0.5_2 solved. Now I have full functionality back; however, in case anyone wants me to try or check something, I'll be glad to help. Can you try the following patch? on top of 1.0.5_3: http://people.freebsd.org/~bapt/xmms-wma.diff It doesn't solve, same crash. bye Thanks av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ biology/tinker | 6.2.06 | 6.3.01 +-+ dns/p5-Net-DNSBL-Statistics | 0.12| 0.13 +-+ graphics/ImageMagick| 6.8.0-7 | 6.8.8-3 +-+ japanese/wordpress | 3.8 | 3.8.1 +-+ www/groupoffice | 3.7.24 | 5.0.37 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: r341435: deletion of graphics/fotoxx
Michael Gmelin free...@grem.de writes:
His web server reports a content length of 2696186, but only provides
2696168 bytes of data. Tools like wget and curl just stop downloading
data, while fetch hangs waiting for those 18 extra bytes.
Actually, the file *is* 2696168 bytes long. With the following patch,
fetch(1) will still hang getting the last 1018 bytes, but the file will
be complete and the download will be successful.
Index: lib/libfetch/common.c
===
--- lib/libfetch/common.c (revision 260631)
+++ lib/libfetch/common.c (working copy)
@@ -1036,6 +1036,13 @@
if (fetchTimeout 0) {
gettimeofday(now, NULL);
if (!timercmp(timeout, now, )) {
+ /*
+* Return a short read instead of
+* a timeout if we have anything
+* at all.
+*/
+ if (total 0)
+ return (total);
errno = ETIMEDOUT;
fetch_syserr();
return (-1);
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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: r341435: deletion of graphics/fotoxx
Am 28.01.2014 11:04 (UTC+1) schrieb Dag-Erling Smørgrav:
Michael Gmelin free...@grem.de writes:
His web server reports a content length of 2696186, but only provides
2696168 bytes of data. Tools like wget and curl just stop downloading
data, while fetch hangs waiting for those 18 extra bytes.
Actually, the file *is* 2696168 bytes long. With the following patch,
fetch(1) will still hang getting the last 1018 bytes, but the file will
be complete and the download will be successful.
Index: lib/libfetch/common.c
===
--- lib/libfetch/common.c (revision 260631)
+++ lib/libfetch/common.c (working copy)
@@ -1036,6 +1036,13 @@
if (fetchTimeout 0) {
gettimeofday(now, NULL);
if (!timercmp(timeout, now, )) {
+ /*
+ * Return a short read instead of
+ * a timeout if we have anything
+ * at all.
+ */
+ if (total 0)
+ return (total);
errno = ETIMEDOUT;
fetch_syserr();
return (-1);
In the meantime, the author of fotoxx, Michael Cornelison, answered to
me two times. Mike confirms, that the file is fetchable from different
Linux systems and that in his eyes, there is no problem with reported
and de facto file length.
Trying to load fotoxx-14.01.1.tar.gz via ftp/wget seems to work without
problems and gives me a file length of 2696186 (!) bytes.
So I am irritated which file length is right and what's going on here ...
Rainer Hurling
DES
___
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] r341536: 4x leftovers
Make use of ${_MYSQL_SERVER} to support Percona/MariaDB along with MySQL.
PR: ports/186116
Submitted by: fluffy
-
Build ID: 20140128115800-52658
Job owner: k...@freebsd.org
Buildtime: 10 minutes
Enddate: Tue, 28 Jan 2014 12:07:33 GMT
Revision: r341536
Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=341536
-
Port:databases/mysql-q4m 0.9.10_1
Buildgroup: 8.4-QAT/amd64
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~k...@freebsd.org/20140128115800-52658-264552/mysql55-q4m-0.9.10_1.log
Buildgroup: 8.4-QAT/i386
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~k...@freebsd.org/20140128115800-52658-264553/mysql55-q4m-0.9.10_1.log
Buildgroup: 9.2-QAT/amd64
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~k...@freebsd.org/20140128115800-52658-264554/mysql55-q4m-0.9.10_1.log
Buildgroup: 9.2-QAT/i386
Buildstatus: LEFTOVERS
Log:
https://qat.redports.org//~k...@freebsd.org/20140128115800-52658-264555/mysql55-q4m-0.9.10_1.log
--
Buildarchive URL: https://qat.redports.org/buildarchive/20140128115800-52658
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] r341538: 4x leftovers
Take care of CONFIGURE_ARGS and PKGNAMEPREFIX also. - Build ID: 20140128120800-48820 Job owner: k...@freebsd.org Buildtime: 9 minutes Enddate: Tue, 28 Jan 2014 12:17:23 GMT Revision: r341538 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=341538 - Port:databases/mysql-q4m 0.9.10_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140128120800-48820-264564/mysql55-q4m-0.9.10_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140128120800-48820-264565/mysql55-q4m-0.9.10_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140128120800-48820-264566/mysql55-q4m-0.9.10_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~k...@freebsd.org/20140128120800-48820-264567/mysql55-q4m-0.9.10_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140128120800-48820 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: r341435: deletion of graphics/fotoxx
Dag-Erling Smørgrav d...@des.no writes: Actually, the file *is* 2696168 bytes long. With the following patch, fetch(1) will still hang getting the last 1018 bytes, but the file will be complete and the download will be successful. Completely fixed (no hang, no missing data) in head@261230. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: r341435: deletion of graphics/fotoxx
Am 28.01.2014 13:48 (UTC+1) schrieb Dag-Erling Smørgrav: Dag-Erling Smørgrav d...@des.no writes: Actually, the file *is* 2696168 bytes long. With the following patch, fetch(1) will still hang getting the last 1018 bytes, but the file will be complete and the download will be successful. Completely fixed (no hang, no missing data) in head@261230. Wow, many thanks for the fix! After rebuilding 11.0-CURRENT, I can confirm that fetch now is able to load fotoxx-14.01.1.tar.gz as expected. Eventually some of the fetch failures listed in the ports PR database also depended on this behaviour before the fix? Many thanks again. Now there is a real chance of an updated graphics/fotoxx port :) Regards, Rainer Hurling DES ___ 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: r341435: deletion of graphics/fotoxx
Rainer Hurling rhur...@gwdg.de writes: In the meantime, the author of fotoxx, Michael Cornelison, answered to me two times. Mike confirms, that the file is fetchable from different Linux systems and that in his eyes, there is no problem with reported and de facto file length. Trying to load fotoxx-14.01.1.tar.gz via ftp/wget seems to work without problems and gives me a file length of 2696186 (!) bytes. So I am irritated which file length is right and what's going on here ... What's going on is that the server accepts persistent connections but does not have a request timeout set, so libfetch, due to an unexpected interaction between multiple buffering layers, hangs waiting for more data while the server hangs waiting for the next request; then libfetch times out and doesn't notice that it already received exactly the amount of data it expected. Most servers have very short request timeouts, so they close the connection while libfetch is waiting, which libfetch interprets as an EOF (which is an expected condition as long as it received all the data it wanted) as opposed to a timeout (which is an error). Anyway, it was fixed in head in r261230. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: r341435: deletion of graphics/fotoxx
On Tue, Jan 28, 2014 at 03:07:46PM +0100, Rainer Hurling wrote: Am 28.01.2014 13:48 (UTC+1) schrieb Dag-Erling Smørgrav: Dag-Erling Smørgrav d...@des.no writes: Actually, the file *is* 2696168 bytes long. With the following patch, fetch(1) will still hang getting the last 1018 bytes, but the file will be complete and the download will be successful. Completely fixed (no hang, no missing data) in head@261230. Wow, many thanks for the fix! After rebuilding 11.0-CURRENT, I can confirm that fetch now is able to load fotoxx-14.01.1.tar.gz as expected. Eventually some of the fetch failures listed in the ports PR database also depended on this behaviour before the fix? Many thanks again. Now there is a real chance of an updated graphics/fotoxx port :) Can you update the patch for the PR to the 14.01.1 version while here maybe you want to add yourself as a maintainer :) regards, Bapt pgpzridNxjmCp.pgp Description: PGP signature
[QAT] r341561: 4x leftovers
Support stage Use options helpers Modernize lib_depends - Build ID: 20140128134000-26024 Job owner: b...@freebsd.org Buildtime: 36 minutes Enddate: Tue, 28 Jan 2014 14:16:11 GMT Revision: r341561 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=341561 - Port:math/gnuplot 4.6.3_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20140128134000-26024-264656/gnuplot-4.6.3_2.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20140128134000-26024-264657/gnuplot-4.6.3_2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20140128134000-26024-264658/gnuplot-4.6.3_2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20140128134000-26024-264659/gnuplot-4.6.3_2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140128134000-26024 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
What is the problem with ports PR reaction delays?
Hi, Just a little stick in this anthill: - I've seen a few people volunteering, but so far the reaction seems to be: oh, yeah, well, ah, cool. I'd expect, with all the talk about how much they are needed, that they will be snatched immediately and coerced into doing unspeakable things (like processing a 100 PRs a day, ensuring high quality testing and all that :) ). I certainly hope this is happening behind the scenes. - Tools are abundant, focusing on github vs. aegis is really just highjacking this thread. If there's a need for new tool set I suppose people who actually USE the existing ones for ports will be able to identify what's needed FOR THEM. Some form of democracy, I guess. - Yes, fresh look is very important, but you can't tear down something without knowing the consequences, which pretty much means not without in depth knowledge of the existing mechanisms. Not everyone in this discussion seems to be coming from this perspective. - Absolutely, automate the shit out of the process, get rid of stale PR's (and ports, for that matter), retire inactive commiters, etc. But first and foremost, get some stats out of the system, there's no point throwing numbers like 50% this, 80% that, if you simply don't know. Measure, analyze and focus your attention where it gets the most benefits. - And stop petty squabbles. Regards, Daniel ___ 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: How to find removed ports in general math/hexcalc in particular.
On 28 Jan 2014, at 16:28, Julian H. Stacey j...@berklix.com wrote: Hi po...@freebsd.org I'm looking for ports/math/hexcalc or replacement it dissapeared after 8.2-RELEASE, it's not in http://www.freebsd.org/ports/math.html How should one find: Why it dissapeared ? (eg maybe it just lacked a maintainer I have to re-port it? Or ... ? What to replace it with ? A few days ago I tried tracing another port (demime) ploughed through loads of svnweb pages, dividing by 2 until I found exactly the revision when demime had been removed, but even there no hint why removed or what to use instead. ( Eventually I used emil instead of demime. ) After upgrade, recovering abandoned ports is a chore, What - if any - generalised pointer mechanism, does FreeBSD have for providing a hint of Why a port was deleted, what to use instead. Try: grep demime /usr/ports/MOVED which will give: mail/demime||2011-12-28|Has expired: No upstream development since 2007 -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
How to find removed ports in general math/hexcalc in particular.
Hi po...@freebsd.org I'm looking for ports/math/hexcalc or replacement it dissapeared after 8.2-RELEASE, it's not in http://www.freebsd.org/ports/math.html How should one find: Why it dissapeared ? (eg maybe it just lacked a maintainer I have to re-port it? Or ... ? What to replace it with ? A few days ago I tried tracing another port (demime) ploughed through loads of svnweb pages, dividing by 2 until I found exactly the revision when demime had been removed, but even there no hint why removed or what to use instead. ( Eventually I used emil instead of demime. ) After upgrade, recovering abandoned ports is a chore, What - if any - generalised pointer mechanism, does FreeBSD have for providing a hint of Why a port was deleted, what to use instead. ( In CVS days I'd have looked in Attic via web, but though 8.2 was CVS days, it'd be better to know the new [SVN] way ? ) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with . Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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: r341435: deletion of graphics/fotoxx
On Tue, 28 Jan 2014 15:10:49 +0100 Dag-Erling Smørgrav d...@des.no wrote: Rainer Hurling rhur...@gwdg.de writes: In the meantime, the author of fotoxx, Michael Cornelison, answered to me two times. Mike confirms, that the file is fetchable from different Linux systems and that in his eyes, there is no problem with reported and de facto file length. Trying to load fotoxx-14.01.1.tar.gz via ftp/wget seems to work without problems and gives me a file length of 2696186 (!) bytes. So I am irritated which file length is right and what's going on here ... What's going on is that the server accepts persistent connections but does not have a request timeout set, so libfetch, due to an unexpected interaction between multiple buffering layers, hangs waiting for more data while the server hangs waiting for the next request; then libfetch times out and doesn't notice that it already received exactly the amount of data it expected. Most servers have very short request timeouts, so they close the connection while libfetch is waiting, which libfetch interprets as an EOF (which is an expected condition as long as it received all the data it wanted) as opposed to a timeout (which is an error). Anyway, it was fixed in head in r261230. Thank you. -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: What is the problem with ports PR reaction delays?
On 1/28/14, 10:04 AM, Daniel Siechniewicz wrote: Hi, Just a little stick in this anthill: - I've seen a few people volunteering, but so far the reaction seems to be: oh, yeah, well, ah, cool. I'd expect, with all the talk about how much they are needed, that they will be snatched immediately and coerced into doing unspeakable things (like processing a 100 PRs a day, ensuring high quality testing and all that :) ). I certainly hope this is happening behind the scenes. Not. -- Jim Ohlstein Never argue with a fool, onlookers may not be able to tell the difference. - Mark Twain ___ 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: How to find removed ports in general math/hexcalc in particular.
Dimitry Andric wrote: --Apple-Mail=_442D467F-1929-40CE-90B7-0CAD6B1BC540 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 28 Jan 2014, at 16:28, Julian H. Stacey j...@berklix.com wrote: Hi po...@freebsd.org I'm looking for ports/math/hexcalc or replacement it dissapeared after 8.2-RELEASE, it's not in http://www.freebsd.org/ports/math.html How should one find: Why it dissapeared ? (eg maybe it just lacked a maintainer I have to re-port it? Or ... ? What to replace it with ? A few days ago I tried tracing another port (demime) ploughed through loads of svnweb pages, dividing by 2 until I found exactly the revision when demime had been removed, but even there no hint why removed or what to use instead. ( Eventually I used emil instead of demime. ) After upgrade, recovering abandoned ports is a chore, What - if any - generalised pointer mechanism, does FreeBSD have for providing a hint of Why a port was deleted, what to use instead. Try: grep demime /usr/ports/MOVED which will give: mail/demime||2011-12-28|Has expired: No upstream development since 2007 -Dimitry Thanks Dimitry :-) grep hexcalc /usr/ports/MOVED math/hexcalc||2011-08-01|Has expired: Looks like abandonware, no more public distfiles I have a local: 25129 Dec 20 1995 hexcalc..tar.Z (no idea why 2 dots), anyway its a valid tar. I have put it up here http://berklix.com/~jhs/ftp/FreeBSD/ports/distfiles/hexcalc..tar.Z I'll look at creating a port. (unless people know of a newer nice hexcalc ? but this one was always OK for me) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: What is the problem with ports PR reaction delays?
El 28/01/2014 16:04, Daniel Siechniewicz dan...@nulldowntime.com escribió: Hi, Just a little stick in this anthill: - I've seen a few people volunteering, but so far the reaction seems to be: oh, yeah, well, ah, cool. I'd expect, with all the talk about how much they are needed, that they will be snatched immediately and coerced into doing unspeakable things (like processing a 100 PRs a day, ensuring high quality testing and all that :) ). I certainly hope this is happening behind the scenes. - Tools are abundant, focusing on github vs. aegis is really just highjacking this thread. If there's a need for new tool set I suppose people who actually USE the existing ones for ports will be able to identify what's needed FOR THEM. Some form of democracy, I guess. - Yes, fresh look is very important, but you can't tear down something without knowing the consequences, which pretty much means not without in depth knowledge of the existing mechanisms. Not everyone in this discussion seems to be coming from this perspective. - Absolutely, automate the shit out of the process, get rid of stale PR's (and ports, for that matter), retire inactive commiters, etc. But first and foremost, get some stats out of the system, there's no point throwing numbers like 50% this, 80% that, if you simply don't know. Measure, analyze and focus your attention where it gets the most benefits. +1 I wrote the same thing expecting someone to have a look at gnat's database and collect some numbers - And stop petty squabbles. Regards, Daniel ___ 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: devel/libgee 0.8.5 fails to build
On 27-1-2014 20:45, Torfinn Ingolfsen wrote: (g-ir-compiler:83467): GVFS-RemoteVolumeMonitor-WARNING **: cannot open directory /usr/local/share/gvfs/remote-volume-monitors: Error opening directory '/usr/local/share/gvfs/remote-volume-monitors': No such file or directory snip Is this a known issue? Details: root@kg-v7# uname -a FreeBSD kg-v7.kg4.no 9.2-STABLE FreeBSD 9.2-STABLE #1 r261187: Sun Jan 26 15:20:25 CET 2014 r...@kg-v7.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 root@kg-v7# pv libgee* libgee-0.6.2.1needs updating (port has 0.8.5) HTH Hmm the element warnings seem to be harmless, but the but the above gvfs warning seems to be more interesting. Could you rebuild/install gvfs and see if that would fix this? I assume you have gvfs installed with the gphoto and hal options? -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
Re: r341435: deletion of graphics/fotoxx
Am 28.01.2014 15:10, schrieb Baptiste Daroussin:
On Tue, Jan 28, 2014 at 03:07:46PM +0100, Rainer Hurling wrote:
Am 28.01.2014 13:48 (UTC+1) schrieb Dag-Erling Smørgrav:
Dag-Erling Smørgrav d...@des.no writes:
Actually, the file *is* 2696168 bytes long. With the following patch,
fetch(1) will still hang getting the last 1018 bytes, but the file will
be complete and the download will be successful.
Completely fixed (no hang, no missing data) in head@261230.
Wow, many thanks for the fix!
After rebuilding 11.0-CURRENT, I can confirm that fetch now is able to
load fotoxx-14.01.1.tar.gz as expected.
Eventually some of the fetch failures listed in the ports PR database
also depended on this behaviour before the fix?
Many thanks again. Now there is a real chance of an updated
graphics/fotoxx port :)
Can you update the patch for the PR to the 14.01.1 version while here maybe
you
want to add yourself as a maintainer :)
Hi Bapt,
I tried to create an update to version 14.01.1. What I did, was:
- update to version 14.01.1
- new mastersite; 2nd mastersites contents has to be updated
- unbreak the port
- modernize LIB_DEPENDS
- support STAGE_DIR
- strip bin/fotoxx
- correct usage of desktop-file-utils
- update URL in pkg-descr
- update pkg-plist
Known problems or TODOs:
- libexecinfo.so.1 is found in system and from port. No idea, which one
is the correct one to use (depending on OS version?).
- fotoxx now uses /proc for file operations. This was changed by the
author after version 11.03.
The updated port builds and installs fine for me (11.0-CURRENT).
Portlint complains about usage of .if ${PORT_OPTIONS:MDOCS} to wrap
installation of files into /usr/local/share/doc). Is this relevant and
what is necessary to consider it?
The diff is attached. I did not file a PR, because I think the usage of
/proc should be solved before. At runtime, the program is not fully
usable, because many functions try to get their info from /proc/...
I am not sure, if I am the right person to maintain the port. My skills
are very low (I am not a programmer, only an interested scientist ...)
and their are many things I do not fully understand.
Any help is really appreciated.
Greetings,
Rainer
regards,
Bapt
diff -u fotoxx.orig/Makefile fotoxx/Makefile
--- fotoxx.orig/Makefile2014-01-27 19:51:13.0 +0100
+++ fotoxx/Makefile 2014-01-28 16:23:06.0 +0100
@@ -2,38 +2,33 @@
# $FreeBSD: head/graphics/fotoxx/Makefile 341435 2014-01-27 17:35:26Z bapt $
PORTNAME= fotoxx
-PORTVERSION= 11.03
-PORTREVISION= 2
+PORTVERSION= 14.01.1
CATEGORIES=graphics
-MASTER_SITES= http://kornelix.squarespace.com/downloads/ \
+MASTER_SITES= http://www.kornelix.com/uploads/1/3/0/3/13035936/ \
http://www.rodperson.com/DL/
MAINTAINER=po...@freebsd.org
COMMENT= Application to organize and edit image collections
-BROKEN=Does not fetch
-DEPRECATED=Broken for more than 6 month
-EXPIRATION_DATE= 2014-02-27
-
-LIB_DEPENDS= execinfo.1:${PORTSDIR}/devel/libexecinfo
+LIB_DEPENDS= libexecinfo.so:${PORTSDIR}/devel/libexecinfo
RUN_DEPENDS= xdg-open:${PORTSDIR}/devel/xdg-utils \
ufraw-batch:${PORTSDIR}/graphics/ufraw \
- exiftool:${PORTSDIR}/graphics/p5-Image-ExifTool
+ exiftool:${PORTSDIR}/graphics/p5-Image-ExifTool \
+ dcraw:${PORTSDIR}/graphics/dcraw
-USE_GNOME= gtk20
-USE_GMAKE= yes
-MANCOMPRESSED= yes
-MAN1= fotoxx.1
+USES= gmake desktop-file-utils
+USE_GNOME= gtk30
ALL_TARGET=fotoxx
-INSTALL_TARGET=install manpage
+INSTALL_TARGET=install
LDFLAGS+= -O3 -g -Wall -rdynamic -lexecinfo
-NO_STAGE= yes
post-patch:
@${REINPLACE_CMD} -e 's|/usr/local|${LOCALBASE}|' \
- ${WRKSRC}/Makefile \
- ${WRKSRC}/dependencies.sh
+ ${WRKSRC}/Makefile
+
+post-install:
+ @${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/fotoxx
.include bsd.port.mk
diff -u fotoxx.orig/distinfo fotoxx/distinfo
--- fotoxx.orig/distinfo2014-01-22 18:20:45.0 +0100
+++ fotoxx/distinfo 2014-01-07 11:59:27.0 +0100
@@ -1,2 +1,2 @@
-SHA256 (fotoxx-11.03.tar.gz) =
c23e6b7c5517d1509b14a270bd2ad2af6fd2de613e55e79104f77d1748492577
-SIZE (fotoxx-11.03.tar.gz) = 1152890
+SHA256 (fotoxx-14.01.1.tar.gz) =
04746b8ccefca343a2b2f530624f7d98cd8ce17d3f20beaf5171b1dc18c94701
+SIZE (fotoxx-14.01.1.tar.gz) = 2696186
Common subdirectories: fotoxx.orig/files and fotoxx/files
diff -u fotoxx.orig/pkg-descr fotoxx/pkg-descr
--- fotoxx.orig/pkg-descr 2014-01-22 18:20:45.0 +0100
+++ fotoxx/pkg-descr2014-01-07 16:42:35.0 +0100
@@ -2,4 +2,4 @@
and collection management. The goal is to meet most user needs
while remaining fast and easy to use.
-WWW: http://kornelix.squarespace.com/fotoxx
+WWW: http://www.kornelix.com/fotoxx.html
diff -u
Re: devel/libgee 0.8.5 fails to build
Hello, On Tue, Jan 28, 2014 at 5:53 PM, Koop Mast k...@rainbow-runner.nl wrote: Hmm the element warnings seem to be harmless, but the but the above gvfs warning seems to be more interesting. Could you rebuild/install gvfs and see if that would fix this? reinstalling gvfs does not fix this. I assume you have gvfs installed with the gphoto and hal options? Why do you assume I have those options set? Anyway here is the gvfs config I am using: root@kg-v7# cd /usr/ports/devel/gvfs root@kg-v7# make showconfig === The following configuration options are available for gvfs-1.12.3_2: AVAHI=on: Zeroconf support via Avahi CDDA=off: CDDA (enables HAL) FUSE=off: FUSE (Filesystem in Userspace) support GPHOTO2=off: Gphoto 2 camera support (enables HAL) HAL=off: HAL (Hardware Abstraction Layer) support SAMBA=on: Samba support === Use 'make config' to modify these settings HTH -- Regards, Torfinn Ingolfsen ___ 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
Выгодные предложения* на вылеты в Турцию, Индию, Египет, ОАЭ из Киева от 28.01.2014
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle div{color:#1b1515; font-family: Arial; font-size: 12px;}
.blocktitle a{color:#1b1515; font-family: Arial; font-size: 12px;
text-decoration:none;}
.bc{display:inline; margin:6px 5px 0 6px;}
.mar1{padding:7px 32px 16px 32px;}
.prodtitle{color:#381b00; font-family: Arial; font-size: 11px; width:124px;
height:34px;}
.prodtitle a{color:#381b00; font-family: Arial; font-size: 11px;
text-decoration:none;}
.prodprice{width:124px; color:#b60009; font-family: Arial; font-size: 14px;
font-weight:bold;}
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle div{color:#1b1515; font-family: Arial; font-size: 12px;}
.blocktitle a{color:#1b1515; font-family: Arial; font-size: 12px;
text-decoration:none;}
.bc{display:inline; margin:6px 5px 0 6px;}
.mar1{padding:7px 32px 16px 32px;}
.prodtitle{color:#381b00; font-family: Arial; font-size: 11px; width:124px;
height:34px;}
.prodtitle a{color:#381b00; font-family: Arial; font-size: 11px;
text-decoration:none;}
.prodprice{width:124px; color:#b60009; font-family: Arial; font-size: 14px;
font-weight:bold;}
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle div{color:#1b1515; font-family: Arial; font-size: 12px;}
.blocktitle a{color:#1b1515; font-family: Arial; font-size: 12px;
text-decoration:none;}
.bc{display:inline; margin:6px 5px 0 6px;}
.mar1{padding:7px 32px 16px 32px;}
.prodtitle{color:#381b00; font-family: Arial; font-size: 11px; width:124px;
height:34px;}
.prodtitle a{color:#381b00; font-family: Arial; font-size: 11px;
text-decoration:none;}
.prodprice{width:124px; color:#b60009; font-family: Arial; font-size: 14px;
font-weight:bold;}
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle div{color:#1b1515; font-family: Arial; font-size: 12px;}
.blocktitle a{color:#1b1515; font-family: Arial; font-size: 12px;
text-decoration:none;}
.bc{display:inline; margin:6px 5px 0 6px;}
.mar1{padding:7px 32px 16px 32px;}
.prodtitle{color:#381b00; font-family: Arial; font-size: 11px; width:124px;
height:34px;}
.prodtitle a{color:#381b00; font-family: Arial; font-size: 11px;
text-decoration:none;}
.prodprice{width:124px; color:#b60009; font-family: Arial; font-size: 14px;
font-weight:bold;}
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle div{color:#1b1515; font-family: Arial; font-size: 12px;}
.blocktitle a{color:#1b1515; font-family: Arial; font-size: 12px;
text-decoration:none;}
.bc{display:inline; margin:6px 5px 0 6px;}
.mar1{padding:7px 32px 16px 32px;}
.prodtitle{color:#381b00; font-family: Arial; font-size: 11px; width:124px;
height:34px;}
.prodtitle a{color:#381b00; font-family: Arial; font-size: 11px;
text-decoration:none;}
.prodprice{width:124px; color:#b60009; font-family: Arial; font-size: 14px;
font-weight:bold;}
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle div{color:#1b1515; font-family: Arial; font-size: 12px;}
.blocktitle a{color:#1b1515; font-family: Arial; font-size: 12px;
text-decoration:none;}
.bc{display:inline; margin:6px 5px 0 6px;}
.mar1{padding:7px 32px 16px 32px;}
.prodtitle{color:#381b00; font-family: Arial; font-size: 11px; width:124px;
height:34px;}
.prodtitle a{color:#381b00; font-family: Arial; font-size: 11px;
text-decoration:none;}
.prodprice{width:124px; color:#b60009; font-family: Arial; font-size: 14px;
font-weight:bold;}
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle div{color:#1b1515; font-family: Arial; font-size: 12px;}
.blocktitle a{color:#1b1515; font-family: Arial; font-size: 12px;
text-decoration:none;}
.bc{display:inline; margin:6px 5px 0 6px;}
.mar1{padding:7px 32px 16px 32px;}
.prodtitle{color:#381b00; font-family: Arial; font-size: 11px; width:124px;
height:34px;}
.prodtitle a{color:#381b00; font-family: Arial; font-size: 11px;
text-decoration:none;}
.prodprice{width:124px; color:#b60009; font-family: Arial; font-size: 14px;
font-weight:bold;}
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle div{color:#1b1515; font-family: Arial; font-size: 12px;}
.blocktitle a{color:#1b1515; font-family: Arial; font-size: 12px;
text-decoration:none;}
.bc{display:inline; margin:6px 5px 0 6px;}
.mar1{padding:7px 32px 16px 32px;}
.prodtitle{color:#381b00; font-family: Arial; font-size: 11px; width:124px;
height:34px;}
.prodtitle a{color:#381b00; font-family: Arial; font-size: 11px;
text-decoration:none;}
.prodprice{width:124px; color:#b60009; font-family: Arial; font-size: 14px;
font-weight:bold;}
body {}
.blocktitle{color:#1b1515; font-family: Arial; font-size: 12px; margin:1px 0 0
28px;}
.blocktitle
Error compiling ports on FreeBSD 10 for ARM (Raspberry Pi)
Hi Ports subscribers, I've been trying out a recent build of what may become the FreeBSD 10.0 release for ARM (FreeBSD 10.0-RELEASE (RPI-B) #0 r261135). There aren't any non-x86 pkg builds available yet, so I used portsnap to install ports. All the ports I have tried to install (tmux, curl, pkg, sudo) fail with the same error: /usr/lib/libcrypto.a(pmeth_lib.o):(.data+0x0): undefined reference to `rsa_pkey_meth' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [pkg-static] Error code 1 For example, if I go to /usr/ports/sysutils/tmux and run make install as root, and fifteen minutes later the build fails with this error. Does anyone know how what the cause of an issue like this might be? I'm relatively new to FreeBSD, so I'm out of my depth when it comes to compile issues on a new architecture. Searches for rsa_pkey_meth linker errors using a popular web search engine didn't yield anything that looked useful. Are packages being signed after they are built? Thank-you in advance for any thoughts or insights that you may have, Steve. ___ 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: Can't seem to build ruby19 or 18.
On Mon, Jan 27, 2014 at 12:11:52PM -0600, Edwin L. Culp W. wrote: === Building for ruby-1.9.3.484_1,1 make: don't know how to make OPENSSL_CFLAGS. Stop *** [do-build] Error code 1 I just want to be sure that it isn't me, hopefully. I'm unable to reproduce, and based on other responses and another thread, I think this isn't something ruby specific. Perhaps you can share your make.conf? Thanks, Steve ___ 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: lang/ruby19: fails to build on 9.2-STABLE: don't know how to make OPENSSL_CFLAGS. Stop
On Mon, Jan 27, 2014 at 04:14:14PM +0100, Herbert J. Skuhra wrote: Den 27.01.2014 11:48, skrev O. Hartmann: On all FreeBSD 9.2-STABLE oboxes, the update of port lang/ruby19 fails with checking for nroff... /usr/bin/nroff .ext/include/amd64-freebsd9/ruby/config.h updated ruby library version = 1.9 configure: creating ./config.status config.status: creating Makefile config.status: creating ruby-1.9.pc === Building for ruby-1.9.3.484_1,1 make: don't know how to make OPENSSL_CFLAGS. Stop *** [do-build] Error code 1 Stop in /usr/ports/lang/ruby19. *** [build] Error code 1 This is caused by: r341335 I'm unable to reproduce on r341678, perhaps there is something in your make.conf that's triggering it? Can you share your make.conf? Thanks, Steve ___ 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: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.
Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. A) Clang does not need to to be installed first. B) FreeBSD 10's change to pkg(8) (a.k.a. PKGNG) affects the portupgrade tools as well as the package tools. Even if you are not using packages, before upgrading to FreeBSD 10 install pkg(8) as described in: http://www5.us.freebsd.org/doc/handbook/pkgng-intro.html and be sure to run pkg2ng. C) FreeBSD 10 moves converters/libiconv into the base system, which directly or indirectly affects many ports. This migration has largely been taken care of for the official packages, however, if you are rebuilding from the ports tree pkg_delete libiconv must be run, or converters/libiconv must be deinstalled, before your post OS recompile of all your ports. Most of the iconv hardcodes have been addressed in the ports tree, but this is still being worked on. D) Many Gnome ports still had issues with continuing to link to libiconv.so.3, such as avahi-app and gdm. People who deleted all ports, removed /usr/local and reinstalled have reported that they do not have the problem. Apparently, some Gnome components are finicky about how they are built. A note from https://wiki.gnome.org/Projects/Jhbuild/FreeBSD Remove all .la files from the packages you just installed to prevent problems during the build. You'll have to remember to do this again each time you install more packages. I deleted the contents of /usr/local/lib and ran portupgrade -afu which rebuilt most of the problematic ports. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Lessons-learned-from-source-upgrade-from-FreeBSD-i386-9-2-Stable-to-FreeBSD-i386-10-0-Release-tp5878893p5880956.html Sent from the freebsd-ports mailing list archive at Nabble.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: net/avahi-app core dumps signal 11
People who deleted all ports, removed /usr/local and reinstalled have reported that they do not have the problem. I have deleted the contents of /usr/local/lib and am running a portupgrade -afu I'll report back if that is a quicker fix. Amazing, this worked. Apparently, some Gnome components are finicky about how they are built. A note from https://wiki.gnome.org/Projects/Jhbuild/FreeBSD Remove all .la files from the packages you just installed to prevent problems during the build. You'll have to remember to do this again each time you install more packages. -- View this message in context: http://freebsd.1045724.n5.nabble.com/net-avahi-app-core-dumps-signal-11-tp5878518p5880954.html Sent from the freebsd-ports mailing list archive at Nabble.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: net/avahi-app core dumps signal 11
Amazing, this worked. Nope, built but still fails. :-( -- View this message in context: http://freebsd.1045724.n5.nabble.com/net-avahi-app-core-dumps-signal-11-tp5878518p5880958.html Sent from the freebsd-ports mailing list archive at Nabble.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
