How to resurrect ltrace from Attic?
Hi, I noticed that someone has removed sysutils/ltrace for some reason. However for me this software works very well and I am not aware of any replacement. (Please point me to a replacement if there is one.) There was lots of discussion recently about deprecating ports and someone mentioned that it does not really matter because people can still checkout the port from the Attic. So, my question is: how exactly do I check it out from the Attic so that I can install it on new FreeBSD installations? I probably knew the answer many years ago, but I have not used CVS for more than 10 years because better tools have been invented. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.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: How to resurrect ltrace from Attic?
On Sun, Sep 18, 2011 at 06:45:21AM +, Janne Snabb wrote: I noticed that someone has removed sysutils/ltrace for some reason. If we pull up the page on CVSWeb: http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/ltrace/Attic/Makefile We find: 2011-08-08 sysutils/ltrace: Has expired: Looks like an abandonware, no more public distfiles (or, you could take a look in ports/MOVED, which has the same info) For CVS, you could note the date on that page, and then subtract a bit from the commit date, and then do: cd /usr; cvs co -D 20110731 ports/sysutils/ltrace You would have to modify that if your ports are not in /usr/ports, of course. If you were not using cvs to get your ports, well, AFAIK you'll have to do some manual operations, e.g., for each file in: http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/ltrace/Attic/ click on filename, go to previous revision, click download ... ... at least, for the files that existed at removal time. (e.g. pkg_comment and pkg_plist were removed years ago, and are thus were no longer needed even before the port was removed.) mcl ___ 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 resurrect ltrace from Attic?
On Sun, 18 Sep 2011, Mark Linimon wrote: cd /usr; cvs co -D 20110731 ports/sysutils/ltrace Oh, ok, that simple. Stupid me :). I had an impression that there is some special trickery to access the Attic files (I could not figure out how to reference the file version just before the moment it vanished). Thank you! Your detailed instructions could be cut'n'pasted to the Handbook to a new subsection titled how to use ports that someone has decided to deprecate. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.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: Substitute dependencies?
On Sun, 18 Sep 2011 05:38:00 + (GMT) Thomas Mueller wrote: First case I think of is the misc/freebsd-doc-* ports which want links1, which would be redundant if I already have lynx installed, or lynx and seamonkey too. I don't really like links1, prefer links with graphic capability though links with graphics is still a lame horse compared to Firefox or Seamonkey. I have viewed the FreeBSD Handbook quite successfully with Seamonkey, even Lynx. links1 isn't simply installed as browser to read the documentation. It's a dependency of docproj, and is used to generate formatted text from HTML. ___ 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
Version of opencv-core-2.3.1
When running: /usr/sbin/pkg_version -vIL=, I received this rather strange output: opencv-core-2.3.1 succeeds index (index has 2.3.1.a) I would have expected output to be more like this: apache-2.2.20_1needs updating (index has 2.2.21) I have never seen this before. Is there something broken? I have a suspicion that programs like portupgrade or portmanager will not properly handle this. This is on a FreeBSD-8.2 amd64 system. -- Carmel ✌ carmel...@hotmail.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: Version of opencv-core-2.3.1
On 18 Sep 2011 12:36, Carmel carmel...@hotmail.com wrote: When running: /usr/sbin/pkg_version -vIL=, I received this rather strange output: opencv-core-2.3.1 succeeds index (index has 2.3.1.a) I would have expected output to be more like this: apache-2.2.20_1needs updating (index has 2.2.21) I have never seen this before. Is there something broken? I have a suspicion that programs like portupgrade or portmanager will not properly handle this. This is on a FreeBSD-8.2 amd64 system. On second thoughts, this looks like EVERSIONNUMBERGOINGBACKWARDS; alphabetical characters in versions usually indicate beta status and are numerically less than the numeric version. Perhaps a PORTEPOCH bump is in order, or some creativity with DISTVERSION. 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
Re: Version of opencv-core-2.3.1
On 18 Sep 2011 12:36, Carmel carmel...@hotmail.com wrote: When running: /usr/sbin/pkg_version -vIL=, I received this rather strange output: opencv-core-2.3.1 succeeds index (index has 2.3.1.a) I would have expected output to be more like this: apache-2.2.20_1needs updating (index has 2.2.21) I have never seen this before. Is there something broken? I have a suspicion that programs like portupgrade or portmanager will not properly handle this. This is on a FreeBSD-8.2 amd64 system. Have you run make fetchindex? 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
Re: Version of opencv-core-2.3.1
On 18/09/2011 12:36, Carmel wrote: When running: /usr/sbin/pkg_version -vIL=, I received this rather strange output: opencv-core-2.3.1 succeeds index (index has 2.3.1.a) I would have expected output to be more like this: apache-2.2.20_1needs updating (index has 2.2.21) I have never seen this before. Is there something broken? I have a suspicion that programs like portupgrade or portmanager will not properly handle this. This is on a FreeBSD-8.2 amd64 system. It's not a particularly rare thing. All it means is that the INDEX file is somewhat out of date. There's many reasons why that can happen -- eg. plenty of ways to commit things to the ports that will break generating the INDEX, the machines doing the generation getting their knickers in a twist or not being able to upload the new INDEX to the right servers. If you wait for a few hours and re-csup it should be fixed. AFAIK, I don't think this affects portsnap because it generates the INDEX in a different way. Or you can create your own INDEX if you want. However, for most uses, you don't actually need a 100% accurate INDEX. If you install from ports and set any OPTIONS to non-default values, then chances are the default INDEX won't match the actual dependencies in your ports tree anyhow. Same if you use a non-default version of perl, python, mysql, postgresql, apache or several other important ports. That doesn't impede normal ports usage. portmaster(8) only uses the INDEX file if you specifically tell it to: usually that's if run it in packages-only mode. portupgrade(8) -- it's been a while since I've used portmaster, but as far as I recall, it didn't particularly need the INDEX either. Even if a broken INDEX does screw things up, generally what will happen is that your upgrading session will fail to upgrade certain packages leaving the old versions in place and still working, and you can just wait a while and try again later. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Substitute dependencies?
Eitan Adler writes: Another case I think of is mysql as a dependency when the user might prefer MariaDB or PostgreSQL. This may not always be possible, but I do understand the point you are trying to make Having never experimented with this, it is my understanding there are some cases where such substitution is possible, but many more where it is not. One would hope if it were, it would be taken care of in the Makefile or OPTIONS. If you know of cases where it _can_ be done (i.e. you have done it successfully), please (at the very least) post them. If you're feeling really motivated, patches would be as welcome to others as they would have been yo you. Respectfully, 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: Version of opencv-core-2.3.1
On 18/09/2011 12:59, Chris Rees wrote: On 18 Sep 2011 12:36, Carmel carmel...@hotmail.com wrote: opencv-core-2.3.1 succeeds index (index has 2.3.1.a) On second thoughts, this looks like EVERSIONNUMBERGOINGBACKWARDS; alphabetical characters in versions usually indicate beta status and are numerically less than the numeric version. Usually fixable without bumping portepoch -- just tweak the way PORTVERSION is generated from DISTVERSION slightly differently. Compare: % pkg_version -t 2.3.1 2.3.1.a % pkg_version -t 2.3.1 2.3.1a In this case, setting: PORTVERSION = DISTVERSION should be sufficient. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Error building x11-wm/i3 and x11-wm/awesome
Greetings
Trying to test a couple of window managers and get the same error on
both. Something to do with devel/libev. Same error on 8.2 stable amd64
and 9.0 Beta2 i386.
=== Installing for libev-4.04,1
=== libev-4.04,1 depends on executable: pkg-config - found
=== Generating temporary packing list
=== Checking if devel/libev already installed
test -z /usr/local/lib || ./install-sh -c -d /usr/local/lib
/bin/sh ./libtool --mode=install /usr/bin/install -c -o root -g
wheel libev.la '/usr/local/lib' libtool: install: /usr/bin/install -c
-o root -g wheel .libs/libev.so.4 /usr/local/lib/libev.so.4 libtool:
install: (cd /usr/local/lib { ln -s -f libev.so.4 libev.so || { rm
-f libev.so ln -s libev.so.4 libev.so; }; }) libtool: install:
(cd /usr/local/lib { ln -s -f libev.so.4 libev.so || { rm -f
libev.so ln -s libev.so.4 libev.so; }; }) libtool:
install: /usr/bin/install -c -o root -g
wheel .libs/libev.lai /usr/local/lib/libev.la libtool:
install: /usr/bin/install -c -o root -g
wheel .libs/libev.a /usr/local/lib/libev.a libtool: install: chmod
644 /usr/local/lib/libev.a libtool: install:
ranlib /usr/local/lib/libev.a
--
Libraries have been installed in: /usr/local/lib
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--
test -z /usr/local/include || ./install-sh -c -d /usr/local/include
install -o root -g wheel -m 444 ev.h ev++.h '/usr/local/include'
test -z /usr/local/man/man3 || ./install-sh -c -d
/usr/local/man/man3 install -o root -g wheel -m 444 ev.3
'/usr/local/man/man3' === Compressing manual pages for libev-4.04,1
=== Running ldconfig
/sbin/ldconfig -m /usr/local/lib
=== Registering installation for libev-4.04,1
=== Returning to build of i3-3.e.b3
Error: shared library ev.3 does not exist
*** Error code 1
Stop in /usr/ports/x11-wm/i3.
Anyone have an idea?
TIA
Robert
___
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: Error building x11-wm/i3 and x11-wm/awesome
В Sun, 18 Sep 2011 05:04:40 -0700
Robert travelin...@cox.net пишет:
ev.3
--- Makefile.orig 2011-09-18 15:32:03.0 +0300
+++ Makefile2011-09-18 15:32:12.0 +0300
@@ -21,7 +21,7 @@
xcb-util=0.3.6:${PORTSDIR}/x11/xcb-util \
xproto=7.0.11:${PORTSDIR}/x11/xproto
LIB_DEPENDS= cairo.2:${PORTSDIR}/graphics/cairo \
- ev.3:${PORTSDIR}/devel/libev \
+ ev.4:${PORTSDIR}/devel/libev \
freetype.9:${PORTSDIR}/print/freetype2 \
startup-notification-1.0:${PORTSDIR}/x11/startup-notification
\ xdg-basedir.1:${PORTSDIR}/x11/libxdg-basedir \
___
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 resurrect ltrace from Attic?
On Sun, 18 Sep 2011, Mark Linimon wrote: On Sun, Sep 18, 2011 at 06:45:21AM +, Janne Snabb wrote: I noticed that someone has removed sysutils/ltrace for some reason. If we pull up the page on CVSWeb: http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/ltrace/Attic/Makefile We find: 2011-08-08 sysutils/ltrace: Has expired: Looks like an abandonware, no more public distfiles (or, you could take a look in ports/MOVED, which has the same info) For CVS, you could note the date on that page, and then subtract a bit from the commit date, and then do: cd /usr; cvs co -D 20110731 ports/sysutils/ltrace You would have to modify that if your ports are not in /usr/ports, of course. If you were not using cvs to get your ports, well, AFAIK you'll have to do some manual operations, e.g., for each file in: http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/ltrace/Attic/ click on filename, go to previous revision, click download ... ... at least, for the files that existed at removal time. (e.g. pkg_comment and pkg_plist were removed years ago, and are thus were no longer needed even before the port was removed.) Also, saving a backup copy of the distfile somewhere outside of /usr/ports might be a good idea. Sometimes distfiles from old ports are very difficult to find, and automated port tools might prune them from /usr/ports/distfiles as obsolete. ___ 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: Error building x11-wm/i3 and x11-wm/awesome SOLVED
On Sun, 18 Sep 2011 15:32:41 +0300
Ivan Klymenko fi...@ukr.net wrote:
В Sun, 18 Sep 2011 05:04:40 -0700
Robert travelin...@cox.net пишет:
ev.3
--- Makefile.orig 2011-09-18 15:32:03.0 +0300
+++ Makefile 2011-09-18 15:32:12.0 +0300
@@ -21,7 +21,7 @@
xcb-util=0.3.6:${PORTSDIR}/x11/xcb-util \
xproto=7.0.11:${PORTSDIR}/x11/xproto
LIB_DEPENDS= cairo.2:${PORTSDIR}/graphics/cairo \
- ev.3:${PORTSDIR}/devel/libev \
+ ev.4:${PORTSDIR}/devel/libev \
freetype.9:${PORTSDIR}/print/freetype2 \
startup-notification-1.0:${PORTSDIR}/x11/startup-notification
\ xdg-basedir.1:${PORTSDIR}/x11/libxdg-basedir \
___
Thanks Ivan, that fixed it.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Version of opencv-core-2.3.1
On Sun, 18 Sep 2011 13:04:37 +0100 Matthew Seaman articulated: If you wait for a few hours and re-csup it should be fixed. AFAIK, I don't think this affects portsnap because it generates the INDEX in a different way. Or you can create your own INDEX if you want. Thanks Mathew for you info. I am using portsnap so apparently it does exhibit this behavior. I any case, since it is apparently not a critical problem I will just ignore it for now. -- Carmel ✌ carmel...@hotmail.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: Version of opencv-core-2.3.1
On 18 Sep 2011 15:02, Carmel carmel...@hotmail.com wrote: On Sun, 18 Sep 2011 13:04:37 +0100 Matthew Seaman articulated: If you wait for a few hours and re-csup it should be fixed. AFAIK, I don't think this affects portsnap because it generates the INDEX in a different way. Or you can create your own INDEX if you want. Thanks Mathew for you info. I am using portsnap so apparently it does exhibit this behavior. I any case, since it is apparently not a critical problem I will just ignore it for now. Since Matthew pointed out that the versions were actually going forwards, you can indeed fix this with make fetchindex. 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
Re: How to resurrect ltrace from Attic?
Note that the source code can be obtained from Debian, apparently. Does it work, i don't know. -- Michel TALON ___ 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: Version of opencv-core-2.3.1
On Sun, 18 Sep 2011 15:14:56 +0100 Chris Rees articulated: On 18 Sep 2011 15:02, Carmel carmel...@hotmail.com wrote: On Sun, 18 Sep 2011 13:04:37 +0100 Matthew Seaman articulated: If you wait for a few hours and re-csup it should be fixed. AFAIK, I don't think this affects portsnap because it generates the INDEX in a different way. Or you can create your own INDEX if you want. Thanks Mathew for you info. I am using portsnap so apparently it does exhibit this behavior. I any case, since it is apparently not a critical problem I will just ignore it for now. Since Matthew pointed out that the versions were actually going forwards, you can indeed fix this with make fetchindex. Running make fetchindex then /usr/sbin/pkg_version -vIL= results in the exact same output as I originally reported. I reran portsnap to see if that made any difference and it did not. Maybe this is just a localized phenomena. In any case, if it doesn't affect anything, I am not going to go all ballistic over it. -- Carmel ✌ carmel...@hotmail.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: Version of opencv-core-2.3.1
On 18/09/2011 15:14, Chris Rees wrote: Since Matthew pointed out that the versions were actually going forwards, you can indeed fix this with make fetchindex. Err... no I didn't. I wasn't very clear in my explanation though -- sorry about that. I showed that the old version (2.3.1) was treated as newer than the latest version (2.3.1.a) -- ie. going in reverse, as you said. The important bit was that it could be fixed without bumping port epoch by making the port version come out to 2.3.1a -- that missing dot makes all the difference. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Re-starting daemons across upgrades?
W dniu 2011-09-17 11:08, Matthias Andree pisze: - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. Or we could have a facility to check whether services are running. For example, I have some cron scripts, which are similar for all of the services that I'm watching. They run periodically and restart services if they are down. It does not matter if they are down because of an upgrade or a failure, so this solution is more general. Here's an example that I have for MySQL: Before we go that way, we should consider using runit by Gerrit Pape (smarden.org), Upstart, or port systemd. We shouldn't go that way at all. Restarting service right after it's update is not a good thing. In many cases service will not start, because of needed configuration changes od other ports not recompiled or updated. The safe way is to not stop service at all. Let the system operator restart service manually when he finish all the needed update tasks. -- best regards, Lukasz Wasikowski ___ 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: Version of opencv-core-2.3.1
On Sun, Sep 18, 2011 at 7:20 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: The important bit was that it could be fixed without bumping port epoch by making the port version come out to 2.3.1a -- that missing dot makes all the difference. i don't think that's an allowed PORTVERSION value -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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/153429: [patch] Fix explicite uses of unzip in ports
On Sun, Sep 18, 2011 at 12:39:48PM -0400, Eitan Adler wrote: This patch requires approval from those CCed. I approve the patch. Herve ___ 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 with CPPFLAGS in CONFIGURE_(ARGS|ENV)
I did a check yesterday to see how many ports in the tree still have CPPFLAGS defined in either the CONFIGURE_ARGS or CONFIGURE_ENV variable. There are still quite a few, I'm afraid. Anyway, I was wondering how best to go about rectifying this (admittedly minor) problem. I don't want to bombard the pr system with a flurry of individual reports/patches, but I'm not sure I want to pester each and every maintainer about this either. So, what would be a good approach? Any suggestions? -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/153429: [patch] Fix explicite uses of unzip in ports
* Eitan Adler (ead...@freebsd.org) wrote: This patch requires approval from those CCed. Approved, thanks! -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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/153429: [patch] Fix explicite uses of unzip in ports
On 2011.09.18. 18:39, Eitan Adler wrote: This patch requires approval from those CCed. Approved for my ports. And thanks! Gabor ___ 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 with CPPFLAGS in CONFIGURE_(ARGS|ENV)
So, what would be a good approach? Any suggestions? Prepare a patch and get a committer to ask portmgr@ for approval. I volunteer if you need someone. -- 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: Ports with CPPFLAGS in CONFIGURE_(ARGS|ENV)
On Sun, 18 Sep 2011 20:04:32 -0400 Eitan Adler li...@eitanadler.com wrote: So, what would be a good approach? Any suggestions? Prepare a patch and get a committer to ask portmgr@ for approval. I volunteer if you need someone. Do you mean one gigantic, monolithic patch that would amend all of them, or a large set of individual patches (last I checked, there were ~1453 ports in need of this sort of revision)? I could go either way, just need to know which would be preferred. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Detecting dependencies
On 09/17/11 18:09, b. f. wrote: On 09/15/11 07:06, chukharev at mail.ru wrote: Hi, There have been a discussion about finding interdependencies of ports. I have a relatively simple Python script for that. There is a pr ports/160007 to add its early version. Unfortunately, I missed a reply to it, so there is an issue which I have not yet addressed... Since that time, I added reverse dependencies with full ports tree scanning (1 h on my 2.5GHz notebook) and saving the tree (directed graph, actually) to a file, so that rescanning all ports tree is not needed. See http://code.google.com/p/porttree/ If there will be interest, scanning packages interdependencies could also be added. On a related subtopic, we also need a tool that identifies implicit dependencies not captured in the ports Makefiles. I hacked the following together earlier this year to smooth over the updating process when key libraries get bumped (e.g. the gettext update at the time I wrote the script was a nightmare). There were a tonne of ports which needed to be updated even though they didn't explicitly record a dependency on gettext. https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh It's still quite rough and manually driven and is tied to portmaster at the moment, but I use it routinely after a portmaster -ad to check that no libs are missing dependencies. It works pretty well most of the time, but definitely needs more finessing. I share it mostly to prove the feasibility of the approach and in case anyone is curious. What, no check to see if the libraries listed in the DT_NEEDED tags are actually needed? And no kitchen sink? ;) err... look, over there! A dog with a puffy tail chasing a kitchen sink! *runs* There are scripts in ports/Tools/scripts that were intended to perform similar tasks, although they may be rougher than your script. Yes they provide various bits and pieces of the puzzle. I haven't thought the following ideas through a great deal and welcome feedback, but I think the basic functionality/premise of this script could be integrated into the ports framework so that at package registration time, implicit deps are identified and marked in the package database. A warning could also be generated that the port is using deps not identified in the Makefile, and perhaps trigger a send-pr to the port maintainer to let them know. ... A script like this could also be integrated/called somehow from a tool like portmaster during an update to ensure ports with implicit dependencies on another port which has been updated are identified and recompiled too so that we avoid the nasty problems that crop up with missing library dependencies. Just as in the other *_DEPENDS lists, it was a conscious policy decision, for the sake of brevity and efficiency, that if port B requires port C, and port A requires port B, then libraries from port C will not be listed in the LIB_DEPENDS of port A, even if port A links directly to those libraries. But because Right, which is fine (and more desirable - simpler is better) if we have a way built into the system to actually derive them at upgrade/install time and ensure we don't leave the system broken. Given that the information can be derived, it seems sensible not to have ports' Makefiles define all deps explicitly, and instead use tools at install/upgrade time to do the heavy lifting automatically. Going for brevity without the infrastructure in place to automagically compensate for the information not being explicitly codified in the makefiles means certain brokeness, which is not cool. of recurring problems with partial port updates, this policy has been criticized. I think that the last time the matter was raised, the consensus seemed to lean toward listing all needed libraries, but the amount of work involved in, and the likely disruption arising from, refactoring all LIB_DEPENDS in the tree dissuaded anyone doing so. I can't see a reason why the policy can't stay as it is if the smarts can be added to generate the implicit dependency info when needed, and more importantly use that generated information to avoid leaving the system broken. Whether we argue the smarts belong solely in a tool like portmaster or should be integrated into the ports infrastructure itself is fair game. My gut feeling is that the deps list stored on disk by the ports system at registration time should be complete with explicit and implicit deps, even though the port's Makefile only lists those which are explicit. Tools like portmaster then only need to use the information as is to do their part of the job and the system should be left intact post upgrade cycle, at least from a broken lib deps perspective. If my gut feeling is valid, then that implies the ports infrastructure itself should do a step post install but pre registration where implicit deps are identified and added to the port's +CONTENTS file. I'm very unfamiliar with the
Re: Ports with CPPFLAGS in CONFIGURE_(ARGS|ENV)
Do you mean one gigantic, monolithic patch that would amend all of them, or a large set of individual patches (last I checked, there were ~1453 ports in need of this sort of revision)? I could go either way, just need to know which would be preferred. One monolithic patch (preferably generated with cvs diff -Nu) -- 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: Ports with CPPFLAGS in CONFIGURE_(ARGS|ENV)
On Sun, 18 Sep 2011 21:38:46 -0400 Eitan Adler li...@eitanadler.com wrote: Do you mean one gigantic, monolithic patch that would amend all of them, or a large set of individual patches (last I checked, there were ~1453 ports in need of this sort of revision)? I could go either way, just need to know which would be preferred. One monolithic patch (preferably generated with cvs diff -Nu) OK. Just a few more questions: portlint -A issues no warning in the case of CPPFLAGS being added to CONFIGURE_ARGS. Should I concern myself only with CONFIGURE_ENV, or would it be best to modify in either case? Also, is there any possibility of either CONFIGURE_ENV or CONFIGURE_ARGS being used in some non-standard fashion, i.e., with anything other than a GNU configure script, meaning they should just be left alone? Just trying to avoid any potential gotchas. Thanks again. -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
