Re: texinfo
On Fri, Mar 15, 2013 at 04:11:17PM +0100, Daniel Thiele wrote: On 03/15/13 12:21, Baptiste Daroussin wrote: On Fri, Mar 15, 2013 at 12:03:08PM +0100, Daniel Thiele wrote: On 03/14/13 23:04, Johan van Selst wrote: Hi Mitja, ajtiM wrote: In ports is texinfo-5.1 update but whenever is texinfo new version (update) I have a problem: print/texinfo-5.1 confilcts with texi2html-5.0 (installs files into the same place. Problematic: /usr/local/share/texinfo/init/book.init This is curious: texinfo does not install this book.init file; and neither port seems to mention a potential conflict in the port Makefile. Could this be a left-over warning from an old version? Are other people seeing this problem as well? I also see this problem. I am experiencing this on a freshly installed system, so no updating of any of the two ports is involved. texi2html was installed first and seems to install a couple of init files in TEXINFODIR. An installation of texinfo then fails with === Registering installation for texinfo-5.1.20130313 as automatic Installing texinfo-5.1.20130313...pkg: texinfo-5.1.20130313 conflicts with texi2html-5.0_1,1 (installs files into the same place). Problematic file: /usr/local/share/texinfo/init/book.init *** [fake-pkg] Error code 70 although the conflicting file is not listed in texinfo's pkg-plist. Regards, Daniel Ok I'll try to reproduce, and fix pkgng is the bug comes from pkgng or come back with an explanation But do not expect something before next week. regards Bapt Thanks for looking into it. If you need any assistance or more information, just drop me a line. I finally got it. The bug is in the texinfo port: PORTDATA= * This globbing makes texinfo pick up all the files inside /usr/local/share/texinfo but if texi2html is installed before texinfo then it installs some files in that place, and those files are picked up in the texinfo plist. Thus pkgng is right yelling about a conflict in files. The fix would be to expand the files in PORTDATADIR directly into the texinfo plist. Until we get the stage feature into the ports tree regards, Bapt pgp2eINa4YgTv.pgp Description: PGP signature
Re: texinfo
Hi Baptiste, Baptiste Daroussin wrote: I finally got it. The bug is in the texinfo port: PORTDATA= * This globbing makes texinfo pick up all the files inside /usr/local/share/texinfo but if texi2html is installed before texinfo then it installs some files in that place, and those files are picked up in the texinfo plist. Thus pkgng is right yelling about a conflict in files. The fix would be to expand the files in PORTDATADIR directly into the texinfo plist. Thank you for working this out: I completely missed that. I'll update the plist for texinfo now. Will look into texi2html later and see if it really makes sense to install its files in share/texinfo. Regards, Johan pgpnfIk4Babtu.pgp Description: PGP signature
Re: Updating curl
On Sat, 23 Mar 2013 22:08:16 -0400 Robert Huff articulated: The port version of curl is 7.24.0_2. On February 6th. curl-7.29.0 was released. Is there any possibility that this port might be updated. Of course. However: my system alone has around two dozen ports that list curl as a dependency. No update will happen without sufficient testing to make sure there's no breakage. Volunteers for testing should probably contact the maintainer. That is an excuse, not a reason. If the maintainer, who has not bothered to reply, were to issue an experimental or devel port of curl, I would be happy to try it. The fact that curl is a dependent of numerous ports is also irrelevant. There are ports that are in far greater demand on the system that get updated in less than a year, and multiple versions, time. There have been several versions released since the one in the port's system and over a years time. The KDE and GNOME team often state why they are not updating a particular port and what to expect in its regards. If the curl maintainer either has lost interest in maintaining the port or has a specific reason for not keeping it relatively current, then I think he|she|they have an obligation to at least make that know to the FreeBSD community. I can totally understand a maintainer walking away from a port, it happens here all the time. However, if the maintainer no longer desires to keep the port current, it would behoove them to state so, so that another individual who might have the knowledge and time to do so can take over maintainer ship. I am not upset at the maintainer, I just want to know what the future of the curl port is. I use it extensively. Your statement regarding testing is a non-starter Robert. Other versions of this port were released sans any formal testing that I am aware of. Plus, the maintainer, again to the best of my knowledge, has not offered any of the versions of curl issued since the port's version, for public testing. It appears to me that the port is abandoned. We have ports like Postfix that are updated in virtual real time and then we have ports that seem to orphaned. It is too bad we cannot find a nice happy medium. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Chicago law prohibits eating in a place that is on fire. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Ports should provide knobs disabling unwanted network services
Many ports, (specially the KDE-related ones) provide no option to disable network-related options. Usually these are things like samba-client, Avahi-mDNS* (with variants), and the like. Gnome usually provides a choice to disable gnome-vfs. I really don't understand why such ports enable those services by default, then provide a warning along the lines of if you are unhappy with the security risk present through this service, uninstall the port... etc. I usually end up hacking the Makefile and disabling the cr*p that I don't want, then build. I understand the purpose of those services, but as an example, is net/mDNSResponder REALLY mandatory for everyone who intends to use graphics/okular? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Ports-should-provide-knobs-disabling-unwanted-network-services-tp5798581.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: Ports should provide knobs disabling unwanted network services
If you want, you can submit a little patch adding choice to disable these options. You'll see if it is adopted or not, but you have more chance to get your request done with something than without. Le 24/03/2013 11:09, Beeblebrox a écrit : Many ports, (specially the KDE-related ones) provide no option to disable network-related options. Usually these are things like samba-client, Avahi-mDNS* (with variants), and the like. Gnome usually provides a choice to disable gnome-vfs. I really don't understand why such ports enable those services by default, then provide a warning along the lines of if you are unhappy with the security risk present through this service, uninstall the port... etc. I usually end up hacking the Makefile and disabling the cr*p that I don't want, then build. I understand the purpose of those services, but as an example, is net/mDNSResponder REALLY mandatory for everyone who intends to use graphics/okular? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Ports-should-provide-knobs-disabling-unwanted-network-services-tp5798581.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 -- Florent Peterschmitt +33 (0)6 64 33 97 92 flor...@peterschmitt.fr signature.asc Description: OpenPGP digital signature
Re: Ports should provide knobs disabling unwanted network services
I would be very happy to submit a patch, if I actually knew how to write one... -- View this message in context: http://freebsd.1045724.n5.nabble.com/Ports-should-provide-knobs-disabling-unwanted-network-services-tp5798581p5798594.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: Ports should provide knobs disabling unwanted network services
It's no something difficult. Rewrite the Makefile port (based on the one already here of course) and use diff util. Or if you want, submit the whole file ;) Le 24/03/2013 12:00, Beeblebrox a écrit : I would be very happy to submit a patch, if I actually knew how to write one... -- View this message in context: http://freebsd.1045724.n5.nabble.com/Ports-should-provide-knobs-disabling-unwanted-network-services-tp5798581p5798594.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 -- Florent Peterschmitt +33 (0)6 64 33 97 92 flor...@peterschmitt.fr signature.asc Description: OpenPGP digital signature
Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load
On Sat, Mar 23, 2013 at 01:26:27PM +0200, Ivan Klymenko wrote: I have uname -a FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: Fri Mar 22 01:17:08 EET 2013 ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC amd64 I updated the ports tree to r314921 and recompiled virtualbox-ose-kmod After load the module a have kernel panic. Panic String: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:1396 http://pkgupdate.nevosoft.ru/backtrace.txt This looks like a vbox issue, the driver did not properly locked the object passed to the vm_page_alloc_contig(). If you want this fixed, you probably need to look up the code yourself, compiling the vbox kld with debugging, finding the offending call to vm_page_alloc_contig() and looking around it to see which object is passed and why it is not locked. pgpuAsk05vmKU.pgp Description: PGP signature
Re: Updating curl
On 2013-03-24 12:04, Jerry wrote: On Sat, 23 Mar 2013 22:08:16 -0400 Robert Huff articulated: The port version of curl is 7.24.0_2. On February 6th. curl-7.29.0 was released. Is there any possibility that this port might be updated. Of course. However: my system alone has around two dozen ports that list curl as a dependency. No update will happen without sufficient testing to make sure there's no breakage. Volunteers for testing should probably contact the maintainer. That is an excuse, not a reason. If the maintainer, who has not bothered to reply, were to issue an experimental or delve port of curl, I would be happy to try it. The fact that curl is a dependent of numerous ports is also irrelevant. There are ports that are in far greater demand on the system that get updated in less than a year, and multiple versions, time. There have been several versions released since the one in the port's system and over a years time. The KDE and GNOME team often state why they are not updating a particular port and what to expect in its regards. If the curl maintainer either has lost interest in maintaining the port or has a specific reason for not keeping it relatively current, then I think he|she|they have an obligation to at least make that know to the FreeBSD community. I can totally understand a maintainer walking away from a port, it happens here all the time. However, if the maintainer no longer desires to keep the port current, it would behoove them to state so, so that another individual who might have the knowledge and time to do so can take over maintainer ship. I am not upset at the maintainer, I just want to know what the future of the curl port is. I use it extensively. Your statement regarding testing is a non-starter Robert. Other versions of this port were released sans any formal testing that I am aware of. Plus, the maintainer, again to the best of my knowledge, has not offered any of the versions of curl issued since the port's version, for public testing. It appears to me that the port is abandoned. We have ports like Postfix that are updated in virtual real time and then we have ports that seem to orphaned. It is too bad we cannot find a nice happy medium. Just a quick question. How many ports do you maintain? I have to ask this question because it looks like you are always coming up with the same copy pasted text snippets (do you have them as text blocks in vim or emacs?) If you are willing to do the maintenance of an actual curl port please come up with an patch and request maintainer ship. ___ 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: texinfo
On 03/24/13 09:59, Baptiste Daroussin wrote: On Fri, Mar 15, 2013 at 04:11:17PM +0100, Daniel Thiele wrote: On 03/15/13 12:21, Baptiste Daroussin wrote: On Fri, Mar 15, 2013 at 12:03:08PM +0100, Daniel Thiele wrote: On 03/14/13 23:04, Johan van Selst wrote: Hi Mitja, ajtiM wrote: In ports is texinfo-5.1 update but whenever is texinfo new version (update) I have a problem: print/texinfo-5.1 confilcts with texi2html-5.0 (installs files into the same place. Problematic: /usr/local/share/texinfo/init/book.init This is curious: texinfo does not install this book.init file; and neither port seems to mention a potential conflict in the port Makefile. Could this be a left-over warning from an old version? Are other people seeing this problem as well? I also see this problem. I am experiencing this on a freshly installed system, so no updating of any of the two ports is involved. texi2html was installed first and seems to install a couple of init files in TEXINFODIR. An installation of texinfo then fails with === Registering installation for texinfo-5.1.20130313 as automatic Installing texinfo-5.1.20130313...pkg: texinfo-5.1.20130313 conflicts with texi2html-5.0_1,1 (installs files into the same place). Problematic file: /usr/local/share/texinfo/init/book.init *** [fake-pkg] Error code 70 although the conflicting file is not listed in texinfo's pkg-plist. Regards, Daniel Ok I'll try to reproduce, and fix pkgng is the bug comes from pkgng or come back with an explanation But do not expect something before next week. regards Bapt Thanks for looking into it. If you need any assistance or more information, just drop me a line. I finally got it. The bug is in the texinfo port: PORTDATA= * This globbing makes texinfo pick up all the files inside /usr/local/share/texinfo but if texi2html is installed before texinfo then it installs some files in that place, and those files are picked up in the texinfo plist. Thus pkgng is right yelling about a conflict in files. The fix would be to expand the files in PORTDATADIR directly into the texinfo plist. Until we get the stage feature into the ports tree regards, Bapt Thank you for your effort to fix this issue. I can confirm, that now the issue with the conflicting files seems to be resolved. Thank you again! 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: Updating curl
On 24/03/2013 10:04 PM, Jerry wrote: On Sat, 23 Mar 2013 22:08:16 -0400 Robert Huff articulated: The port version of curl is 7.24.0_2. On February 6th. curl-7.29.0 was released. Is there any possibility that this port might be updated. Of course. However: my system alone has around two dozen ports that list curl as a dependency. No update will happen without sufficient testing to make sure there's no breakage. Volunteers for testing should probably contact the maintainer. That is an excuse, not a reason. If the maintainer, who has not bothered to reply, were to issue an experimental or devel port of curl, I would be happy to try it. The fact that curl is a dependent of numerous ports is also irrelevant. There are ports that are in far greater demand on the system that get updated in less than a year, and multiple versions, time. There have been several versions released since the one in the port's system and over a years time. The KDE and GNOME team often state why they are not updating a particular port and what to expect in its regards. If the curl maintainer either has lost interest in maintaining the port or has a specific reason for not keeping it relatively current, then I think he|she|they have an obligation to at least make that know to the FreeBSD community. I can totally understand a maintainer walking away from a port, it happens here all the time. However, if the maintainer no longer desires to keep the port current, it would behoove them to state so, so that another individual who might have the knowledge and time to do so can take over maintainer ship. I am not upset at the maintainer, I just want to know what the future of the curl port is. I use it extensively. Your statement regarding testing is a non-starter Robert. Other versions of this port were released sans any formal testing that I am aware of. Plus, the maintainer, again to the best of my knowledge, has not offered any of the versions of curl issued since the port's version, for public testing. It appears to me that the port is abandoned. We have ports like Postfix that are updated in virtual real time and then we have ports that seem to orphaned. It is too bad we cannot find a nice happy medium. To get this going, find attached a emphasiswork in progress/emphasis patch updating curl to 7.29.0, with the following notes: 1) I've moved patch-configure to DONT-patch-configure Note A: You may assist by merging the patch against 7.29.0 Note B: This change means the port doesn't honour debug/opt flags 2) OPTIONS need to be converted to OPTIONSng Note: You can assist by merging the changes from this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/172325 3) It fails `make test` (from port dir) with regressions: --- test 2030...OK (782 out of 784, remaining: 00:00) test 2031...OK (783 out of 784, remaining: 00:00) test 2032...OK (784 out of 784, remaining: 00:00) TESTDONE: 624 tests out of 626 reported OK: 99% TESTFAIL: These test cases failed: 591 1316 TESTDONE: 787 tests were considered during 291 seconds. *** [quiet-test] Error code 1 --- You may assist by testing and identifying the causes and providing patches for changes 4) This will require an exp-run when its considered 'ready' 5) I ran the port test with default OPTIONS A final comment that I was inspired to do this because of my desire to improve FreeBSD and the experience of our (my) community, and the satisfaction I get from contributing. A commitment to reporting issues is appreciated (so thank you), and is more than what most do. It is also however, a minimum expectation. Perhaps a more mindful, positive approach to encouraging action from others will garner a higher incidence of favourable responses in the future. I hope my work helps. -- Ta, Koobs Index: Makefile === --- Makefile(revision 315110) +++ Makefile(working copy) @@ -1,13 +1,8 @@ -# New ports collection makefile for: curl -# Date created:12 December 1998 -# Whom:Neil Blakey-Milner n...@rucus.ru.ac.za -# +# Created by: Neil Blakey-Milner n...@rucus.ru.ac.za # $FreeBSD$ -# PORTNAME= curl -PORTVERSION= 7.24.0 -PORTREVISION= 2 +PORTVERSION= 7.29.0 CATEGORIES=ftp ipv6 www MASTER_SITES= http://curl.haxx.se/download/ \ LOCAL/sunpoet @@ -52,7 +47,7 @@ MANUAL README.netware README.win32 RESOURCES SSLCERTS THANKS \ TODO TheArtOfHttpScripting VERSIONS curl-config.html \ curl-config.pdf curl.html curl.pdf index.html -MAN1= curl.1 curl-config.1 +MAN1= curl.1 curl-config.1 mk-ca-bundle.1 MAN3= curl_easy_cleanup.3 curl_easy_duphandle.3 curl_easy_escape.3 \ curl_easy_getinfo.3 curl_easy_init.3 curl_easy_pause.3 \ curl_easy_perform.3 curl_easy_recv.3 curl_easy_reset.3
Re: Updating curl
On Sun, 24 Mar 2013 13:10:25 +0100 olli hauer articulated: [snip} Just a quick question. How many ports do you maintain? Three, very simple ports. I have to ask this question because it looks like you are always coming up with the same copy pasted text snippets (do you have them as text blocks in vim or emacs?) I have never created a boilerplate if that is what you are referring to. If you are willing to do the maintenance of an actual curl port please come up with an patch and request maintainer ship. I am actually thinking about updating curl on my system and no I would not release it since I am (1) not the maintain of said port, and (2) I don't have the time to actively maintain it. Which brings us back to my original statement, that being that if the current maintainer is not going to properly maintain the port than they should publicly state that fact which would allow another individual with sufficient time and skill to do so. If you remember a few months ago, there was a discussion as to why Bash lingered on for months, actually a year, with numerous patches being issued by the Bash author yet never being included in the port's system. Finally, another user created a devel port. Perhaps that is the proper way to handle this problem. Postfix, probably the best maintained port in the entire system. has both a stable release and a current release in the ports system. I will agree that sa...@freebsd.org is probably an over achiever, but it is an example of what can be accomplished, and in virtual real time no less, when someone dedicates themselves to a task. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: OpenCASCADE
Le ven 22 mar 13 à 14:58:48 +0100, Andrea Venturoli m...@netfence.it écrivait : Hello. Hello Andrea, Several months ago, I sent you a port skeleton for OpenCASCADE 6.5.2. The version in ports is still at 6.3. In the meanwhile 6.5.2 is already old, as 6.5.3 is out. I understand there are other ports in the tree which require OpenCASCADE 6.3. This is the first point. The second one is my lack of availability... Have you checked that the ports depending on OpenCASCADE are really incompatible with this latest release? My proposal is to rename 6.3 from opencascade to opencascade-legacy or opencascade63 and introduce a new 6.5.3 port. I could create the latter and volunteer to maintain it. What do you think? Yes, that would be fine! Please go. -- Th. Thomas. ___ 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 +-+ editors/tea | 34.0.1 | 35.0.0 +-+ 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 If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org 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: Updating curl
On Sun, Mar 24, 2013 at 1:53 PM, Jerry je...@seibercom.net wrote: On Sun, 24 Mar 2013 13:10:25 +0100 olli hauer articulated: [snip} Just a quick question. How many ports do you maintain? Three, very simple ports. I have to ask this question because it looks like you are always coming up with the same copy pasted text snippets (do you have them as text blocks in vim or emacs?) I have never created a boilerplate if that is what you are referring to. If you are willing to do the maintenance of an actual curl port please come up with an patch and request maintainer ship. I am actually thinking about updating curl on my system and no I would not release it since I am (1) not the maintain of said port, and (2) I don't have the time to actively maintain it. Which brings us back to my original statement, that being that if the current maintainer is not going to properly maintain the port than they should publicly state that fact which would allow another individual with sufficient time and skill to do so. If you remember a few months ago, there was a discussion as to why Bash lingered on for months, actually a year, with numerous patches being issued by the Bash author yet never being included in the port's system. Finally, another user created a devel port. Perhaps that is the proper way to handle this problem. Postfix, probably the best maintained port in the entire system. has both a stable release and a current release in the ports system. I will agree that sa...@freebsd.org is probably an over achiever, but it is an example of what can be accomplished, and in virtual real time no less, when someone dedicates themselves to a task. Sorry, but that is the absolutely wrong approach. The way it works is by contributing not by keeping stuff in your hands and telling other that they should come up with a solution. If a port maintainer is unavailable for some time and unable to update the port himself then it would be the best way to contact him if he has something that you can help with. If he does not respond prepare an update yourself, test it and verify that it works fine and then submit the patch as PR. Then some committer will have a look and either the maintainer approves it or it becomes a maintainer timeout and after that the patch is committed. If you talk to the maintainer and he feels that you already care more about the port than he does I'm pretty sure he will offer to pass maintainership to you. If a maintainer is unavailable for a longer period (multiple maintainer timeouts) then the port maintainer will be reset anyway and can be adopted. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
ports/175104: [PATCH] net/libosip: update to 4.0.0
Hi, Can anyone please take care of ports/175104? It has been a while and I need to update libexosip2, which is dependent on this. Regards, Muhammad ___ 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
skipping system Makefile?
As I understand it: If I go to the directory for port FOO and type make, this invokes the local Makefile ... which invokes various thing in ports/Mk/ ... which at some point read /etc/make.conf. Is there a per-invocation way to avoid the last step? I need to test whether the problem with a particular port is something in make,conf, and it would be ... expedient ... to not have to move it aside and then remember to move it back. Curiously and lazily, Robert Huff ___ 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: skipping system Makefile?
On 24 March 2013 14:08, Robert Huff roberth...@rcn.com wrote: As I understand it: If I go to the directory for port FOO and type make, this invokes the local Makefile ... which invokes various thing in ports/Mk/ ... which at some point read /etc/make.conf. Is there a per-invocation way to avoid the last step? I need to test whether the problem with a particular port is something in make,conf, and it would be ... expedient ... to not have to move it aside and then remember to move it back. Curiously and lazily, Robert Huff make __MAKE_CONF=/nonexistent Chris ___ 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
Bigbluebutton - is this port being maintained?
Hi I have asked a couple of questions about www/bigbluebutton. The current port is looking for openoffice files in the wrong place and the port has not been updated to 0.8. I have cc'd posts to the listed maintainer and emailed directly but so far there have been no responses. Can anyone enlighten me? Thanks in advance David -- David Southwell ARPS AFIAP Photographic Arts Trained experienced competition judge, mentor, trainer, lecturer, Advanced digital techniques, international project photography ___ 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
Could you remove the *-rtems-* ports?
Hi FreeBSD Ports Maintainer, Could you remove the *-rtems-* ports? They fail to build (the user has to change to bash to build them), and once built they don't build RTEMS. There are additional issues stated below. Thanks! Cynthia Rempel From: bugzilla-dae...@rtems.org [bugzilla-dae...@rtems.org] Sent: Sunday, March 24, 2013 7:40 AM To: cynt6...@vandals.uidaho.edu Subject: [Bug 2099] sparc-gcc: error: cannot compute suffix of object files https://www.rtems.org/bugzilla/show_bug.cgi?id=2099 --- Comment #3 from Joel Sherrill joel.sherr...@oarcorp.com 2013-03-24 09:40:35 CDT --- We really want the RTEMS Ports collections deleted. They do not include the RTEMS version in the target name and do not include recent patches. They were not submitted by the project and have no maintainer. You just tripped into a pit we wanted to fill with dirt. :) -- Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. ___ 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
graphics/gimp-resynthesizer on single core i386
Hi, is there any Single Core i386 user out there which is using graphics/gimp-resynthesizer? It is hanging a lot on my machine. What is on yours? Heino ___ 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: Ports should provide knobs disabling unwanted network services
On Sun, Mar 24, 2013 at 7:00 AM, Beeblebrox zap...@berentweb.com wrote: I would be very happy to submit a patch, if I actually knew how to write one... It is quite simple to create the patch. If you have a working copy checked out with svn, then it would be: cd /usr/ports/[category]/[port] - Make the necessary changes to the port - After testing the port make sure to do a 'make clean' svn diff port.diff Otherwise make a copy of the port: cd /usr/ports/[catagory] cp port port-orig cd port - Make the necessary changes to port - After testing port make sure to do a 'make clean' cd .. diff -ruN port-orig port port.diff Then just submit the port.diff in a PR using either send-pr or http://www.freebsd.org/send-pr.html. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ 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
py-qt maintenance
Hello, I have a need for py-qt to ultimately get to a native salome 6.5. I see it is not maintained presently, and am interested in taking ownership. I've been using FreeBSD for so long I figure I should start helping out where I can. I know the latest version of py-qt (4.10) builds against my current system, so I do not think it would be hard to get going considering the old version is about to expire. I do not know what I would need to do to become a maintainer but I figure this is the first step. I will read the docs more in depth though. Not sure if it would be possible to have an @freebsd.org email address, but that would be cool. I'd be interested in helping out other places of the organization too, but I'm not much of a coder. This is a skill I very much need to learn though. I've been using the system since 5.4 as my main OS, and have gotten good at making it work without much help. Love me some beastie, want to help make it keep going. Let me know if I can help. Brian ___ 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: py-qt maintenance
On 3/24/2013 18:40, Brian McKeon wrote: I have a need for py-qt to ultimately get to a native salome 6.5. I see it is not maintained presently, and am interested in taking ownership. I've been using FreeBSD for so long I figure I should start helping out where I can. I know the latest version of py-qt (4.10) builds against my current system, so I do not think it would be hard to get going considering the old version is about to expire. I do not know what I would need to do to become a maintainer but I figure this is the first step. I will read the docs more in depth though. Not sure if it would be possible to have an @freebsd.org email address, but that would be cool. I'd be interested in helping out other places of the organization too, but I'm not much of a coder. This is a skill I very much need to learn though. I've been using the system since 5.4 as my main OS, and have gotten good at making it work without much help. Love me some beastie, want to help make it keep going. Let me know if I can help. Hi Brian, I fixed py-qt a few days ago in DragonFly Ports. The patches are here: https://github.com/jrmarino/DeltaPorts/commit/7cf2d3f44950fa3929d9d1d9fb3d1fb9dc4edf8a I guess I should submit a PR on it John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/175104: [PATCH] net/libosip: update to 4.0.0
Hi Muhammad, Muhammad Moinur Rahman wrote on 24.03.2013 17:41: Hi, Can anyone please take care of ports/175104? It has been a while and I need to update libexosip2, which is dependent on this. Regards, Muhammad net/siproxd fails to build with this version of libosip [1] (and builds fine with 3.6.0), so or this update should be coordinated with siproxd maintainer (cc:ed) or it should be added to the tree as libosip24 or something. The first one is preferred, because there is newer version of siproxd that may work with new libosip. [1] http://people.freebsd.org/~rm/siproxd-0.7.2_3.log -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/175104: [PATCH] net/libosip: update to 4.0.0
Ruslan Makhmatkhanov wrote on 24.03.2013 22:07: Hi Muhammad, Muhammad Moinur Rahman wrote on 24.03.2013 17:41: Hi, Can anyone please take care of ports/175104? It has been a while and I need to update libexosip2, which is dependent on this. Regards, Muhammad net/siproxd fails to build with this version of libosip [1] (and builds fine with 3.6.0), so or this update should be coordinated with siproxd maintainer (cc:ed) or it should be added to the tree as libosip24 or something. The first one is preferred, because there is newer version of siproxd that may work with new libosip. [1] http://people.freebsd.org/~rm/siproxd-0.7.2_3.log Looks like the first one will fail because 0.8.1 also requires libosip2 (3.x.x), according to release notes [1]. It may worth to check, but I'm afraid it will be new port. [1] http://siproxd.sourceforge.net/index.php?op=relnotes -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/175104: [PATCH] net/libosip: update to 4.0.0
Hi Ruslan, Do we need to do it in a REPOCOPY style? Or plain simple new port? Regards, Muhammad On Mon, Mar 25, 2013 at 12:14 AM, Ruslan Makhmatkhanov cvs-...@yandex.ruwrote: Ruslan Makhmatkhanov wrote on 24.03.2013 22:07: Hi Muhammad, Muhammad Moinur Rahman wrote on 24.03.2013 17:41: Hi, Can anyone please take care of ports/175104? It has been a while and I need to update libexosip2, which is dependent on this. Regards, Muhammad net/siproxd fails to build with this version of libosip [1] (and builds fine with 3.6.0), so or this update should be coordinated with siproxd maintainer (cc:ed) or it should be added to the tree as libosip24 or something. The first one is preferred, because there is newer version of siproxd that may work with new libosip. [1] http://people.freebsd.org/~rm/**siproxd-0.7.2_3.loghttp://people.freebsd.org/~rm/siproxd-0.7.2_3.log Looks like the first one will fail because 0.8.1 also requires libosip2 (3.x.x), according to release notes [1]. It may worth to check, but I'm afraid it will be new port. [1] http://siproxd.sourceforge.**net/index.php?op=relnoteshttp://siproxd.sourceforge.net/index.php?op=relnotes -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cannot open tty-output
*Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec JID /bin/tcsh # cd SomePortDir # make config cannot open tty-output === Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a make config in a jail. Outside the jail all goes well. MfG CoCo -- Eugene ___ 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: Could you remove the *-rtems-* ports?
On 24 March 2013 11:34, Rempel, Cynthia cynt6...@vandals.uidaho.edu wrote: Hi FreeBSD Ports Maintainer, Could you remove the *-rtems-* ports? They fail to build (the user has to change to bash to build them), and once built they don't build RTEMS. There are additional issues stated below. I'm following up and will act as needed. Thanks for the heads up. -- Eitan Adler ___ 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: cannot open tty-output
On Sun, 24 Mar 2013 23:40:47 +0400 Eugene V. Boontseff eug...@home.wdc.spb.ru wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec JID /bin/tcsh # cd SomePortDir # make config cannot open tty-output === Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a make config in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer (screen will do as well, but is also heavier). -- 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: Updating curl
(Please keep me CC'd as I'm not subscribed to -ports)
curl tests 591 and 1316 pass for me using vanilla source and running
configure + make test (i.e. not as a port/not using your patch).
However, test 1316 does intermittently fail with socket-related problems
(see the logs referenced below).
What those tests are:
test 591...[FTP multi PORT and 425 on upload]
test 1316...[FTP LIST tunneled through HTTP proxy]
You can list tests by doing:
cd tests
./runtests.pl -l
And can run an individual test:
./runtests.pl -v -k {testnum}
The results are stored in the underlying log/ directory.
I've uploaded two test 1316 log directories (one for the failure, one
for the success during the subsequent run) in case someone wants to
figure this out.
Whether this is a curl bug vs. a test case bug vs. a FreeBSD bug vs. a
regression from older curl versions I do not know, and am not
particularly interested in figuring it out myself. Enjoy:
http://jdc.koitsu.org/freebsd/curl-7.29-tests/
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
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
LEGAL variable to capture generic issues
Hi all,
I have been trying to capture the differences between LEGAL and the ports tree.
At this point I am convinced we need a new variable to capture in a
machine usable way issues such as special permission granted to
distribute under the GPL or No license -- see
http://cr.yp.to/softwarelaw.html;. Furthermore some ports define
NO_PACKAGE for reasons of legality (GPL issues) and others defined it
for other reasons (the package becomes too big). We have no method to
differentiate between these two reasons.
I'd like to add a global meta variable that captures this
relationship. This would add the ability to mark per port special
text to be included in LEGAL even if it doesn't affect the ports tee
behavior.
The patch below would require a little bit of additional work (ports
which defined NO_PACKAGE for reasons other than legality would also
need to define LEGAL_PACKAGE= yes). This would make it much easier to
autogenerate LEGAL from the tree.
Thoughts?
Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk (revision 315169)
+++ Mk/bsd.port.mk (working copy)
@@ -161,6 +161,9 @@ FreeBSD_MAINTAINER= port...@freebsd.org
#but distfiles can be put on ftp sites and
CDROMs.
# FORBIDDEN- Package build should not be attempted because of
#security vulnerabilities.
+# LEGAL_TEXT - Port has legal issues (e.g., special
+#permission to distribute, lacks a license).
+# LEGAL_PACKAGE- Port has no legal issues but defines NO_PACKAGE
# IGNORE - Package build should be skipped entirely (e.g.
#because of serious unfixable problems in the
build,
#because it cannot be manually fetched, etc).
Error
@@ -3200,6 +3203,17 @@ IGNORE= is marked as broken: ${BROKEN}
IGNORE=is forbidden: ${FORBIDDEN}
.endif
+# Define the text to be output to LEGAL
+.if defined(LEGAL_TEXT)
+LEGAL= ${LEGAL_TEXT}
+.elif defined(RESTRICTED)
+LEGAL= ${RESTRICTED}
+.elif defined(NO_CDROM)
+LEGAL= ${NO_CDROM}
+.elif defined(NO_PACKAGE) ! defined(LEGAL_PACKAGE)
+LEGAL= ${NO_PACKAGE}
+.endif
+
.if (defined(MANUAL_PACKAGE_BUILD) defined(PACKAGE_BUILDING))
IGNORE=has to be built manually: ${MANUAL_PACKAGE_BUILD}
clean:
--
Eitan Adler
___
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: LEGAL variable to capture generic issues
On Sun, Mar 24, 2013 at 3:33 PM, Eitan Adler li...@eitanadler.com wrote:
Hi all,
I have been trying to capture the differences between LEGAL and the ports
tree.
At this point I am convinced we need a new variable to capture in a
machine usable way issues such as special permission granted to
distribute under the GPL or No license -- see
http://cr.yp.to/softwarelaw.html;. Furthermore some ports define
NO_PACKAGE for reasons of legality (GPL issues) and others defined it
for other reasons (the package becomes too big). We have no method to
differentiate between these two reasons.
I'd like to add a global meta variable that captures this
relationship. This would add the ability to mark per port special
text to be included in LEGAL even if it doesn't affect the ports tee
behavior.
The patch below would require a little bit of additional work (ports
which defined NO_PACKAGE for reasons other than legality would also
need to define LEGAL_PACKAGE= yes). This would make it much easier to
autogenerate LEGAL from the tree.
Thoughts?
Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk (revision 315169)
+++ Mk/bsd.port.mk (working copy)
@@ -161,6 +161,9 @@ FreeBSD_MAINTAINER= port...@freebsd.org
#but distfiles can be put on ftp sites
and CDROMs.
# FORBIDDEN- Package build should not be attempted because of
#security vulnerabilities.
+# LEGAL_TEXT - Port has legal issues (e.g., special
+#permission to distribute, lacks a
license).
+# LEGAL_PACKAGE- Port has no legal issues but defines NO_PACKAGE
# IGNORE - Package build should be skipped entirely (e.g.
#because of serious unfixable problems in
the build,
#because it cannot be manually fetched,
etc). Error
@@ -3200,6 +3203,17 @@ IGNORE= is marked as broken: ${BROKEN}
IGNORE=is forbidden: ${FORBIDDEN}
.endif
+# Define the text to be output to LEGAL
+.if defined(LEGAL_TEXT)
+LEGAL= ${LEGAL_TEXT}
+.elif defined(RESTRICTED)
+LEGAL= ${RESTRICTED}
+.elif defined(NO_CDROM)
+LEGAL= ${NO_CDROM}
+.elif defined(NO_PACKAGE) ! defined(LEGAL_PACKAGE)
+LEGAL= ${NO_PACKAGE}
+.endif
+
.if (defined(MANUAL_PACKAGE_BUILD) defined(PACKAGE_BUILDING))
IGNORE=has to be built manually: ${MANUAL_PACKAGE_BUILD}
clean:
--
Eitan Adler
___
This is very useful feature because to find such information sometimes
requires much search work .
During package/port development , this information is easily available and
recording it into visible field will make external searches unnecessary .
At the beginning , this field may be empty , but over time , it may be
populated during renew of package/port descriptions/versions .
Thank you very much .
Mehmet Erol Sanliturk
___
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
Fwd: seom-2010011201 failed on i386 8
Hi, Could someone plz have a look? kthxbye Begin forwarded message: From: Portbuild user portbu...@freebsd.org Subject: seom-2010011201 failed on i386 8 Date: March 25, 2013 5:58:21 AM GMT+08:00 To: m...@freebsd.org You can also find this build log at http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20130324140101.pointyhat/seom-2010011201.log building seom-2010011201 on beefy3.isc.freebsd.org in directory /a/pkgbuild/8/20130324140101.pointyhat/chroot/19778 building for: 8.3-RELEASE-p6 i386 maintained by: po...@freebsd.org port directory: /usr/ports/graphics/seom Makefile ident: $FreeBSD: head/graphics/seom/Makefile 311878 2013-02-07 17:40:34Z mi $ build started at Sun Mar 24 21:55:03 UTC 2013 FETCH_DEPENDS= PATCH_DEPENDS= EXTRACT_DEPENDS= BUILD_DEPENDS=damageproto-1.2.1.tbz dri2proto-2.6.tbz expat-2.0.1_2.tbz fixesproto-5.0.tbz gettext-0.18.1.1_1.tbz kbproto-1.0.5.tbz libGL-7.6.1_3.tbz libGLU-7.6.1_2.tbz libX11-1.4.4,1.tbz libXau-1.0.6.tbz libXdamage-1.1.3.tbz libXdmcp-1.1.0.tbz libXext-1.3.0_1,1.tbz libXfixes-5.0.tbz libXv-1.0.6,1.tbz libXxf86vm-1.1.1.tbz libdrm-2.4.17_1.tbz libiconv-1.14_1.tbz libpciaccess-0.12.1.tbz libpthread-stubs-0.3_3.tbz libxcb-1.7.tbz pciids-20130313.tbz pkgconf-0.9.1_2.tbz videoproto-2.3.1.tbz xextproto-7.2.0.tbz xf86vidmodeproto-2.3.1.tbz xproto-7.0.22.tbz yasm-1.2.0.tbz RUN_DEPENDS=damageproto-1.2.1.tbz dri2proto-2.6.tbz expat-2.0.1_2.tbz fixesproto-5.0.tbz kbproto-1.0.5.tbz libGL-7.6.1_3.tbz libGLU-7.6.1_2.tbz libX11-1.4.4,1.tbz libXau-1.0.6.tbz libXdamage-1.1.3.tbz libXdmcp-1.1.0.tbz libXext-1.3.0_1,1.tbz libXfixes-5.0.tbz libXv-1.0.6,1.tbz libXxf86vm-1.1.1.tbz libdrm-2.4.17_1.tbz libpciaccess-0.12.1.tbz libpthread-stubs-0.3_3.tbz libxcb-1.7.tbz pciids-20130313.tbz pkgconf-0.9.1_2.tbz videoproto-2.3.1.tbz xextproto-7.2.0.tbz xf86vidmodeproto-2.3.1.tbz xproto-7.0.22.tbz PKG_DEPENDS= prefixes: LOCALBASE=usr/local add_pkg add_pkg phase 1: make checksum = seom-2010011201.tar.bz2 doesn't seem to exist in /tmp/distfiles/. = Attempting to fetch ftp://ftp-master.freebsd.org/pub/FreeBSD/ports/distfiles//seom-2010011201.tar.bz2 seom-2010011201.tar.bz2 23 kB 1956 kBps === Fetching all distfiles required by seom-2010011201 for building = SHA256 Checksum OK for seom-2010011201.tar.bz2. phase 2: make extract add_pkg === Fetching all distfiles required by seom-2010011201 for building === Extracting for seom-2010011201 = SHA256 Checksum OK for seom-2010011201.tar.bz2. phase 3: make patch add_pkg === Patching for seom-2010011201 === Applying FreeBSD patches for seom-2010011201 phase 4: make build add_pkg damageproto-1.2.1.tbz dri2proto-2.6.tbz expat-2.0.1_2.tbz fixesproto-5.0.tbz gettext-0.18.1.1_1.tbz kbproto-1.0.5.tbz libGL-7.6.1_3.tbz libGLU-7.6.1_2.tbz libX11-1.4.4,1.tbz libXau-1.0.6.tbz libXdamage-1.1.3.tbz libXdmcp-1.1.0.tbz libXext-1.3.0_1,1.tbz libXfixes-5.0.tbz libXv-1.0.6,1.tbz libXxf86vm-1.1.1.tbz libdrm-2.4.17_1.tbz libiconv-1.14_1.tbz libpciaccess-0.12.1.tbz libpthread-stubs-0.3_3.tbz libxcb-1.7.tbz pciids-20130313.tbz pkgconf-0.9.1_2.tbz videoproto-2.3.1.tbz xextproto-7.2.0.tbz xf86vidmodeproto-2.3.1.tbz xproto-7.0.22.tbz yasm-1.2.0.tbz adding dependencies adding package damageproto-1.2.1.tbz adding package dri2proto-2.6.tbz adding package expat-2.0.1_2.tbz adding package fixesproto-5.0.tbz adding package gettext-0.18.1.1_1.tbz adding package kbproto-1.0.5.tbz adding package libGL-7.6.1_3.tbz adding package libGLU-7.6.1_2.tbz adding package libX11-1.4.4,1.tbz skipping libX11-1.4.4,1, already added adding package libXau-1.0.6.tbz skipping libXau-1.0.6, already added adding package libXdamage-1.1.3.tbz skipping libXdamage-1.1.3, already added adding package libXdmcp-1.1.0.tbz skipping libXdmcp-1.1.0, already added adding package libXext-1.3.0_1,1.tbz skipping libXext-1.3.0_1,1, already added adding package libXfixes-5.0.tbz skipping libXfixes-5.0, already added adding package libXv-1.0.6,1.tbz adding package libXxf86vm-1.1.1.tbz skipping libXxf86vm-1.1.1, already added adding package libdrm-2.4.17_1.tbz skipping libdrm-2.4.17_1, already added adding package libiconv-1.14_1.tbz skipping libiconv-1.14_1, already added adding package libpciaccess-0.12.1.tbz skipping libpciaccess-0.12.1, already added adding package libpthread-stubs-0.3_3.tbz skipping libpthread-stubs-0.3_3, already added adding package libxcb-1.7.tbz skipping libxcb-1.7, already added adding package pciids-20130313.tbz
Re: cannot open tty-output
Michael Gmelin schrieb: On Sun, 24 Mar 2013 23:40:47 +0400 Eugene V. Boontseff eug...@home.wdc.spb.ru wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec JID /bin/tcsh # cd SomePortDir # make config cannot open tty-output === Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a make config in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer (screen will do as well, but is also heavier). dialog4ports(1) uses stdout for passing back results, where the former dialog(1) used stderr. I reverted the new behaviour back to the previous one, which fixed the problem for me. I don't know about other implications, though. Ilya (author of dialog4ports) is aware of the problem and having a look at it. I'm glad that other people are running into this, also. I was beginning to think, that there's something fundamentally wrong with the way our 8.x jails are configured. MfG CoCo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] add a config.site cache for the ports
I'm sure your list probably includes this, but just in case, databases/db42 broke with this for me. Steve just a fyi this exp-run broke quiet a lot. On Mar 23, 2013, at 11:18 PM, Bryan Drewery bdrew...@freebsd.org wrote: On 3/18/2013 12:41 PM, Baptiste Daroussin wrote: Hi, The autotools allows us to have a config.site cache where we define our defaults values for a couple of things, and prevent the slow and possibly wrong autodetection. Here is a patch that makes use of it: http://people.freebsd.org/~bapt/autotools_config_site.diff As the libiconv/gettext update has shown the configure scripts can fall back on gnu version of commands first if it find it, and in case gettext is removed you can get trouble. In this config.site, I hardcoded a couple of FreeBSD binaries in order to always use them, but I let the toolchain being autodetected. I also added a couple of headers to avoid useless checks and more can be added in the futur. Any thought? regards, Bapt This will be great. I've added it to my jails for testing too. Bryan +-oOO--(_)--OOo-+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest ___ 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: Could you remove the *-rtems-* ports?
On 3/24/2013 3:19 PM, Eitan Adler wrote: On 24 March 2013 11:34, Rempel, Cynthia cynt6...@vandals.uidaho.edu wrote: Hi FreeBSD Ports Maintainer, Could you remove the *-rtems-* ports? They fail to build (the user has to change to bash to build them), and once built they don't build RTEMS. There are additional issues stated below. I'm following up and will act as needed. Thanks for the heads up. Just to be prudent. These appear to be being updated which hints that someone cares about them. It would be good to know why they are updating them. Are they actually using RTEMS or just doing it to them up to date. But there are some general issues: + the official tools use CPU-rtemsVERSION as the target where VERSION is 4.10, 4.11, etc to indicate the major RTEMS version. We have included the VERSION component for a decade. + The particular set of tool versions and patches do not correspond to anything the RTEMS Project considers a set. We are trying to separate tool version and patch management from packaging. If the person who maintains these wants to work with us so the ports collection follows the recommended naming, versions, patches, etc., we would be very grateful. Otherwise, they are just wrong and that's not good. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ 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: Ports should provide knobs disabling unwanted network services
Le 24/03/2013 17:34, Scot Hetzel a écrit : On Sun, Mar 24, 2013 at 7:00 AM, Beeblebrox zap...@berentweb.com wrote: I would be very happy to submit a patch, if I actually knew how to write one... It is quite simple to create the patch. If you have a working copy checked out with svn, then it would be: cd /usr/ports/[category]/[port] - Make the necessary changes to the port - After testing the port make sure to do a 'make clean' svn diff port.diff Otherwise make a copy of the port: cd /usr/ports/[catagory] cp port port-orig cd port - Make the necessary changes to port - After testing port make sure to do a 'make clean' cd .. diff -ruN port-orig port port.diff Then just submit the port.diff in a PR using either send-pr or http://www.freebsd.org/send-pr.html. Is there a way to manually make a patch that will say : --- MyFile +++ MyFile Even if these files are in two distinct trees ? -- Florent Peterschmitt +33 (0)6 64 33 97 92 flor...@peterschmitt.fr signature.asc Description: OpenPGP digital signature
Ports as an unprivileged user
Hi. While looking up how to configure ports to run as a user other than root, I came across a few pages that describe setting some make.conf variables. http://forums.freebsd.org/showthread.php?t=22368 http://www.mail-archive.com/freebsd-questions@freebsd.org/msg31323.html Is there any plans or work being done on making this kind of system default? There probably won't be any exploits in fetch/libfetch, but there's also no reason to do everything as root. Even just the distfile fetching as a user would be better I think. We could have a dedicated ports user that has access to /usr/ports/distfiles or something. Just some security for consideration. ___ 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: Ports should provide knobs disabling unwanted network services
On Sun, Mar 24, 2013 at 10:33 PM, Florent Peterschmitt flor...@peterschmitt.fr wrote: Le 24/03/2013 17:34, Scot Hetzel a écrit : On Sun, Mar 24, 2013 at 7:00 AM, Beeblebrox zap...@berentweb.com wrote: I would be very happy to submit a patch, if I actually knew how to write one... It is quite simple to create the patch. If you have a working copy checked out with svn, then it would be: cd /usr/ports/[category]/[port] - Make the necessary changes to the port - After testing the port make sure to do a 'make clean' svn diff port.diff Otherwise make a copy of the port: cd /usr/ports/[catagory] cp port port-orig cd port - Make the necessary changes to port - After testing port make sure to do a 'make clean' cd .. diff -ruN port-orig port port.diff Then just submit the port.diff in a PR using either send-pr or http://www.freebsd.org/send-pr.html. Is there a way to manually make a patch that will say : --- MyFile +++ MyFile Even if these files are in two distinct trees ? There is always a way to do that: diff -u /path/to/original/port/MyFile /path/to/modified/port/MyFile /place/to/save/patch/port.diff or if you modifed several files: diff -ruN /path/to/original/port /path/to/modified/port /place/to/save/patch/port.diff -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ 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
