Re: remove BUILD_DEPENDS automatically after install
Sandra Kachelmann wrote: > On Tue, Nov 17, 2009 at 12:58 AM, Doug Barton wrote: >> I have a new feature in the svn version of portmaster called >> --packages-build that for any given run creates an internal list of >> dependencies that are only ever listed as build deps (never run deps) >> and installs packages for them but builds everything else. This >> feature was created at the request of one of companies that sponsored >> the package installation code. Currently it does not pkg_delete those >> packages when it's done, but I could easily add that. > > This is exactly what I was looking for. Good! :) >> Actually I suppose it would not be too hard to extend that "list of >> build only deps" idea to a general feature which deletes them when >> done. Something like --delete-build-only maybe? This would be limited > > I would find such an option extremely useful. > >> to the subset of the list of build-only deps that portmaster actually >> installed. Just because something is build-only for a given run of >> portmaster doesn't mean that it isn't a run dep for something else if >> it is already installed. > > Or if it's already installed before the actual port build it could be > considered as "wanted" and therefor not to be deleted after the build. That's what I was getting at, sorry if I wasn't clear. > Just out of curiosity, is your svn repository publicly accessible? You can get access to the svn version and more information about the sponsorship program at http://dougbarton.us/portmaster-proposal.html. I just committed the --delete-build-only feature so enjoy that. :) Actually at this point I encourage everyone who is interested in package support in portmaster to download the svn version and put it through its paces. I am very close to considering this round of features "finished" and committing them to the port so the more people that can help with the testing the better. > Thank you so much for the good work. You're welcome, and thank you for the kind words. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: remove BUILD_DEPENDS automatically after install
On Mon, 16 Nov 2009 15:58:23 -0800, Doug Barton wrote: > Sandra Kachelmann wrote: >> (portmaster author cc:ed) >> >> On Mon, Nov 16, 2009 at 1:06 AM, Erik Trulsson >> wrote: >>> On Sun, Nov 15, 2009 at 11:44:04PM +0100, Sandra Kachelmann wrote: Is there a reason why BUILD_DEPENDS aren't being removed after a port has been installed and if no other installed port depends on it? >>> How do you know that the user does not want that port installed? >>> And what if the user will install 20 other ports afterwards - all of >>> which >>> is that same port as a BUILD_DEPENDS - should that port be >>> installed/deinstalled each and every time? >> >> It would be nice if this was configurable. Maybe it could be even >> integrated into portupgrade or portmaster. If such a port is installed >> directly it could get a package entry DIRECT_INSTALLED=yes in >> /var/db/pkg/.. or something (there is probably a better way to do >> this). > > I have a new feature in the svn version of portmaster called > --packages-build that for any given run creates an internal list of > dependencies that are only ever listed as build deps (never run deps) > and installs packages for them but builds everything else. This > feature was created at the request of one of companies that sponsored > the package installation code. Currently it does not pkg_delete those > packages when it's done, but I could easily add that. \o/ > Actually I suppose it would not be too hard to extend that "list of > build only deps" idea to a general feature which deletes them when > done. Something like --delete-build-only maybe? This would be limited > to the subset of the list of build-only deps that portmaster actually > installed. Just because something is build-only for a given run of > portmaster doesn't mean that it isn't a run dep for something else if > it is already installed. I think this can be handled better with a "--finish-cmd". After portmaster is done with everything, exec the finish command. A port build server can then pkg_delete -a and see what's still left in $PREFIX, while a casual user can run pkg_cutleaves -xRg to add the newly installed leafs to the exclude file and remove the build dependencies and their dependencies. >>> (Personally I would be *very* annoyed if, for example, libtool or >>> automake/autoconf would be reinstalled every time I installed a port >>> which >>> had one of them as a build-time dependency. > > Well then don't use the option. :) Options are generally good things. With libtool there is a gotcha though. If you change CC/CXX, libtool has to be rebuilt, so the package may not be valid. -- -- Mel ___ 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: RFC: svn for make fetch
On Mon, 16 Nov 2009 15:16:22 +0300, Dmitry Marakasov wrote: > * Eitan Adler (eitanadlerl...@gmail.com) wrote: > >> I was hoping to get a bit more of a response to a recent posting of >> mine with regard to using svn to fetch files for ports >> My proposal: >> http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html >> A summary of what has been going on: >> http://wiki.freebsd.org/EitanAdler/ports-svn > > This was discussed many times before, and this is a bad idea. > - No checksums -> security issue > - No distfile caching/mirroring -> excess traffic consumption and > horrible availability Actually, I *had* a patch that got the source from svn, tarred it and checksummed it, with little modification to the do-fetch target and abusing FETCH_* variables. The unsolvable problem I ran in to, is that svn doesn't adjust timestamps for directories on export, so the checksum for the tar was always different. Hacking svn export was outside my timeframe and hacking tar to grow an option that sets all created dirs to a fixed time stamp, seemed too hackish, so I let it go. -- Mel ___ 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: remove BUILD_DEPENDS automatically after install
On Tue, Nov 17, 2009 at 12:58 AM, Doug Barton wrote: > Sandra Kachelmann wrote: >> (portmaster author cc:ed) >> >> On Mon, Nov 16, 2009 at 1:06 AM, Erik Trulsson >> wrote: >>> On Sun, Nov 15, 2009 at 11:44:04PM +0100, Sandra Kachelmann wrote: Is there a reason why BUILD_DEPENDS aren't being removed after a port has been installed and if no other installed port depends on it? >>> How do you know that the user does not want that port installed? >>> And what if the user will install 20 other ports afterwards - all of which >>> is that same port as a BUILD_DEPENDS - should that port be >>> installed/deinstalled each and every time? >> >> It would be nice if this was configurable. Maybe it could be even >> integrated into portupgrade or portmaster. If such a port is installed >> directly it could get a package entry DIRECT_INSTALLED=yes in >> /var/db/pkg/.. or something (there is probably a better way to do >> this). > > I have a new feature in the svn version of portmaster called > --packages-build that for any given run creates an internal list of > dependencies that are only ever listed as build deps (never run deps) > and installs packages for them but builds everything else. This > feature was created at the request of one of companies that sponsored > the package installation code. Currently it does not pkg_delete those > packages when it's done, but I could easily add that. This is exactly what I was looking for. > Actually I suppose it would not be too hard to extend that "list of > build only deps" idea to a general feature which deletes them when > done. Something like --delete-build-only maybe? This would be limited I would find such an option extremely useful. > to the subset of the list of build-only deps that portmaster actually > installed. Just because something is build-only for a given run of > portmaster doesn't mean that it isn't a run dep for something else if > it is already installed. Or if it's already installed before the actual port build it could be considered as "wanted" and therefor not to be deleted after the build. Just out of curiosity, is your svn repository publicly accessible? Thank you so much for the good work. Sandra ___ 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: sysutils/libcdio provides no cdio_paranoia.0 for ports/devel/gvfs
Hi Eugene, Reference: > From: Eygene Ryabinkin > Reply-to: rea-f...@codelabs.ru > Date: Mon, 16 Nov 2009 11:29:46 +0300 > Message-id: <7cnpo33btpf0wvk2b4xgmufs...@7anlw7wpnqueviofvqmcirbmcl4> Eygene Ryabinkin wrote: > Sun, Nov 15, 2009 at 10:51:55PM +0100, Julian H. Stacey wrote: > > A hint would be welcome please with sysutils/libcdio, Paranoia stuff seems > > broken, but I'm not clear what's intended, hence mail rather than a send-pr. > > > > uname -a > > FreeBSD laps.js.berklix.net 7.2-RELEASE FreeBSD 7.2-RELEASE #2: \ > > Wed Sep 9 11:33:57 CEST 2009 \ > > j...@laps.no.net:/usr/src/sys/i386/compile/LAPS.small i386 > > > > cd /usr/ports/net-mgmt/etherape ; make > > ===> gvfs-1.2.1 depends on shared library: cdio_paranoia.0 - not found > > ===>Verifying install for cdio_paranoia.0 in \ > > /usr/ports/sysutils/libcdio > > ===> Returning to build of gvfs-1.2.1 > > Error: shared library "cdio_paranoia.0" does not exist > > Do you have /usr/ports/sysutils/libcdio/work? Yes, & No, different times, ie ive tried both ways :-) When gvfs failed to make, I did cd /usr/ports/sysutils/libcdio ; make clean ; make cd usr/ports/devel/gvfs ; make clean ; make > If yes, remove it > and try the build once again. > > Do you really have nothing between "Verifying install for cdio_paranoia.0" > and "Returning to build of gvfs"? Not even a try to build libcdio port? It was already built I just tried cd /usr/ports/sysutils/libcdio make clean cd ../../*/gvfs make clean make & got ===> Registering installation for libcdio-0.78.2_2 ===> Returning to build of gvfs-1.2.1 Error: shared library "cdio_paranoia.0" does not exist *** Error code 1 Thanks anyway, PS Next will get to replies from Tılman Linneweh & Koop Mast Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64: http://asciiribbon.org Vote For Smoke Free Bavarian Pubs Restaurants http://berklix.org/~jhs/nim/ ___ 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: RFC: svn for make fetch
Thomas Sandford wrote: > If it were just one port and/or just a port maintainers tool I'd agree. > But this is something that affects MULTIPLE ports. You still seem to be advocating the idea of making this a mechanism for users, in spite of the fact that numerous people have said that idea is not likely to ever be approved. Given the universe where this feature is only used by maintainers, a tool script is a good solution. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: remove BUILD_DEPENDS automatically after install
Sandra Kachelmann wrote: > (portmaster author cc:ed) > > On Mon, Nov 16, 2009 at 1:06 AM, Erik Trulsson wrote: >> On Sun, Nov 15, 2009 at 11:44:04PM +0100, Sandra Kachelmann wrote: >>> Is there a reason why BUILD_DEPENDS aren't being removed after a port >>> has been installed and if no other installed port depends on it? >> How do you know that the user does not want that port installed? >> And what if the user will install 20 other ports afterwards - all of which >> is that same port as a BUILD_DEPENDS - should that port be >> installed/deinstalled each and every time? > > It would be nice if this was configurable. Maybe it could be even > integrated into portupgrade or portmaster. If such a port is installed > directly it could get a package entry DIRECT_INSTALLED=yes in > /var/db/pkg/.. or something (there is probably a better way to do > this). I have a new feature in the svn version of portmaster called --packages-build that for any given run creates an internal list of dependencies that are only ever listed as build deps (never run deps) and installs packages for them but builds everything else. This feature was created at the request of one of companies that sponsored the package installation code. Currently it does not pkg_delete those packages when it's done, but I could easily add that. Actually I suppose it would not be too hard to extend that "list of build only deps" idea to a general feature which deletes them when done. Something like --delete-build-only maybe? This would be limited to the subset of the list of build-only deps that portmaster actually installed. Just because something is build-only for a given run of portmaster doesn't mean that it isn't a run dep for something else if it is already installed. >> (Personally I would be *very* annoyed if, for example, libtool or >> automake/autoconf would be reinstalled every time I installed a port which >> had one of them as a build-time dependency. Well then don't use the option. :) Options are generally good things. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: FreeBSD Port: gtkam-0.1.16.1_1
Sven Göttner píše v po 16. 11. 2009 v 21:26 +0100: > Adding > > add path 'ugen*' 0660 group operator > > to /etc/devfs.rules (as done before for USB sticks) and restarting > devfs and devd via the /etc/rc.d/dev* scripts finally solved the > problem and now also non-root users are able to connect to the camera > via PTP. Yes, this is even included in the gphoto online docu at http://gphoto.sourceforge.net/doc/manual/permissions-usb.html#usb-on-FreeBSD But I just keep running sudo gphoto2, simpler for me :) -- Pav Lucistnik Any Palm app requiring an 90+ page manual has lost its vision. -- words about DateBk4 on Action Names list signature.asc Description: Toto je digitálně podepsaná část zprávy
FreeBSD Port: gtkam-0.1.16.1_1
Dear maintainer of gtkam, just tried out gktam on FBSD 7.1-RELEASE-p8 and was closed to giving up, since my camera (Panasonic DMC-FZ50) was listed on gphoto.com as supported device and gtkam recognized it (almost correctly as FZ20 - but OK...) - but connection via PTP just resulted in an "PTP I/O-Error". Debugging with --debug and --debug-logfile also just listed an "unknown error". I could not connect to the camera or even view/download files. Finally I installed gphoto2 from the ports, since I hoped to get more help or information from a command line tool (proved to be a good strategy while trying to get my handheld to work under FBSD) and then (accidently) started gphoto2 as root - and it flawlessly connected to the camera and downloaded the pictures. Since mounting the camera as da* device (usb mass storage) worked perfectly (which would have been my fallback solution, anyway), I could not explain this behaviour to me. It took me quite a while to guess that obviously when connecting via PTP, an ugen* device is used and not the usual da* device for USB connections. Adding add path 'ugen*' 0660 group operator to /etc/devfs.rules (as done before for USB sticks) and restarting devfs and devd via the /etc/rc.d/dev* scripts finally solved the problem and now also non-root users are able to connect to the camera via PTP. So I suggest adding a post-install notice in the install routine for FBSD that makes the user aware of this step. I have not found this requirement documented elsewhere... Greetz and thanks for maintaining gtkam, Sven. ___ 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: p5-xmltv - old?
On Mon, November 16, 2009 6:20 pm, Torfinn Ingolfsen wrote: > Hi, > > On Sun, Nov 15, 2009 at 8:10 PM, Bernhard Froehlich > wrote: > >> Builds fine in my 7-stable/i386 tinderbox. I've checked which ports are >> depending on p5-xmltv [1] and checked if that update could affect them. >> >> deskutils/ontv: NOTOK using tv_grab_be >> misc/freeguide: OK using tv_cat >> multimedia/freevo: OK using tv_cat >> multimedia/mythtv: OK using tv_check >> multimedia/tv_grab_au: OK using tv_check >> >> The only one that definitely needs fixing is ontv. The others look good. >> > > And that one (ontv) has gnome@ as the maintainer. > How should this be handled; should I send a mail to the gnome list first, > before sending in the PR? > Or should I just send the PR and then send a mail telling them that the > ontv port will / might be affected? Both should be valid but the former is probably a bit faster. At least tell someone of the gnome@ team about it. I've seen that the ontv version is already quite outdated so it probably makes sense to update it to the latest version when you're at it. So go ahead and contact the gnome@ people - irc is usually the fastest. -- Bernhard Fröhlich 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"
Re: p5-xmltv - old?
Hi, On Sun, Nov 15, 2009 at 8:10 PM, Bernhard Froehlich wrote: > Builds fine in my 7-stable/i386 tinderbox. I've checked which ports are > depending on p5-xmltv [1] and checked if that update could affect them. > > deskutils/ontv: NOTOK using tv_grab_be > misc/freeguide: OK using tv_cat > multimedia/freevo: OK using tv_cat > multimedia/mythtv: OK using tv_check > multimedia/tv_grab_au: OK using tv_check > > The only one that definitely needs fixing is ontv. The others look good. > And that one (ontv) has gnome@ as the maintainer. How should this be handled; should I send a mail to the gnome list first, before sending in the PR? Or should I just send the PR and then send a mail telling them that the ontv port will / might be affected? -- 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"
Re: RFC: svn for make fetch
>> I was hoping to get a bit more of a response to a recent posting of >> mine with regard to using svn to fetch files for ports >> My proposal: >> http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html >> A summary of what has been going on: >> http://wiki.freebsd.org/EitanAdler/ports-svn > >This was discussed many times before, and this is a bad idea. >- No checksums -> security issue >- No distfile caching/mirroring -> excess traffic consumption and > horrible availability >and I hope you're not even thinking of fetching from VCS without >specifying exact revision. > >Some standard way of generating distfiles from VCS may be nice though, >if it goes into separate mk-file and supports all major VCS. I also think this is a bad idea, even as a separate mk-file, for many of the same reasons. But it could be useful as a script in ports/Tools. ___ 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: remove BUILD_DEPENDS automatically after install
Sandra Kachelmann wrote: > (portmaster author cc:ed) > > On Mon, Nov 16, 2009 at 1:06 AM, Erik Trulsson wrote: >> On Sun, Nov 15, 2009 at 11:44:04PM +0100, Sandra Kachelmann wrote: >>> Is there a reason why BUILD_DEPENDS aren't being removed after a port >>> has been installed and if no other installed port depends on it? >> How do you know that the user does not want that port installed? >> And what if the user will install 20 other ports afterwards - all of which >> is that same port as a BUILD_DEPENDS - should that port be >> installed/deinstalled each and every time? > > It would be nice if this was configurable. Maybe it could be even > integrated into portupgrade or portmaster. If such a port is installed > directly it could get a package entry DIRECT_INSTALLED=yes in > /var/db/pkg/.. or something (there is probably a better way to do > this). If you installed from packages, they'd never get installed at all. portmaster and portupgrade both have ports tree based package support, pkg_upgrade (sysutils/bsdadminscripts) has index based package support and there's, in my opinion, rarely a reason to build your own packages, though I'm guilty of doing that, too. At least on one of my machines. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: remove BUILD_DEPENDS automatically after install
>> On Sun, Nov 15, 2009 at 11:44:04PM +0100, Sandra Kachelmann wrote:
>>> Is there a reason why BUILD_DEPENDS aren't being removed after a port
>>> has been installed and if no other installed port depends on it?
>>
>> How do you know that the user does not want that port installed?
>> And what if the user will install 20 other ports afterwards - all of which
>> is that same port as a BUILD_DEPENDS - should that port be
>> installed/deinstalled each and every time?
>
>It would be nice if this was configurable. Maybe it could be even
>integrated into portupgrade or portmaster. If such a port is installed
>directly it could get a package entry DIRECT_INSTALLED=yes in
>/var/db/pkg/.. or something (there is probably a better way to do
>this).
How are you going to account for those ports that, while installed as
dependencies, the user nevertheless wants to keep for their own sake?
Or those that are installed individually by a user, perhaps to fix a
problem, but are not really wanted after all builds are done? I think
that this kind of bookkeeping should be done by users and
administrators, and should not be cluttering up the ports and package
infrastructure. If you really want it there, you can make your own
local modifications.
>
>> (Personally I would be *very* annoyed if, for example, libtool or
>> automake/autoconf would be reinstalled every time I installed a port which
>> had one of them as a build-time dependency. There are *lots* of ports which
>> have one of them in BUILD_DEPENDS, but few if any that has them as
>> RUN_DEPENDS.)
>
>Even nicer if execptions would be configurable. There are loads of
>ports that install BUILD_DEPENDS that are never used again. cvsup for
>instance pulls in a gigantic tree of esoteric ports I can't even
>pronounce. Sure I could install the package, take cvsup-without-gui or
>even use portsnap but this is not the point here.
I'm not sure what you mean by "exceptions" -- but if you are not
willing to consider dependencies and configure ports, then you really
ought to be using packages, and that is relevant to this discussion.
There are some ports that can help you manage this kind of cleanup --
for example, you could run "portmaster -s", and then run "portmaster
-l", and remove those ports listed as leaf or root ports that you no
longer want. Or you could add entries to AFTERINSTALL in pkgtools.conf
to remove build dependencies when using portupgrade. But it is
difficult to completely automate a removal, in a generic way that
would satisfy all administrators and users, so some interaction or at
least an initial configuration will be required.
Here is a shell script that will emit a list of installed ports that
are needed to build other installed ports, but are not needed by any
other ports at runtime, according to a ports tree. You could run it
and then either pipe it's output directly to:
| xargs -I % make -C ${PORTSDIR:-/usr/ports}% deinstall
, or first filter the output to remove any ports that you want to keep:
#!/bin/sh
#findbuildonlydeps.sh
_portsdir=${PORTSDIR:-/usr/ports}
_scriptname=`basename $0`
_listbuildreqs=`mktemp -t ${_scriptname}` || \
echo "cannot create ${_listbuildreqs}"
_listrunreqs=`mktemp -t ${_scriptname}` || \
echo "cannot create ${_listrunreqs}"
for _pkgorigin in `pkg_info -qoa` ; do
for _buildreq in `make -C ${_portsdir}/${_pkgorigin} \
-V FETCH_DEPENDS -V EXTRACT_DEPENDS \
-V PATCH_DEPENDS -V BUILD_DEPENDS` ; do
echo ${_buildreq##*${_portsdir}} >> ${_listbuildreqs}
done
for _runreq in `make -C ${_portsdir}/${_pkgorigin} \
-V RUN_DEPENDS -V LIB_DEPENDS` ; do
echo ${_runreq##*${_portsdir}} >> ${_listrunreqs}
done
done
sort -u ${_listbuildreqs} > ${_listbuildreqs}_sorted
sort -u ${_listrunreqs} > ${_listrunreqs}_sorted
comm -23 ${_listbuildreqs}_sorted ${_listrunreqs}_sorted
rm ${_listbuildreqs} ${_listbuildreqs}_sorted \
${_listrunreqs} ${_listrunreqs}_sorted
___
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: sysutils/libcdio provides no cdio_paranoia.0 for ports/devel/gvfs
On Mon, 2009-11-16 at 10:51 +0100, Tılman Linneweh wrote: > Hello Julian! > > (CC: devel/gvfs maintainer added) > > Thanks for reporting this issue. > > On Nov 15, 2009, at 22:51 , Julian H. Stacey wrote: > > int would be welcome please with sysutils/libcdio, Paranoia stuff seems > > broken, but I'm not clear what's intended, hence mail rather than a send-pr. > > > > ===> gvfs-1.2.1 depends on shared library: cdio_paranoia.0 - not found > > ===>Verifying install for cdio_paranoia.0 in \ > > /usr/ports/sysutils/libcdio > > ===> Returning to build of gvfs-1.2.1 > > Error: shared library "cdio_paranoia.0" does not exist > > /usr/ports/devel/gvfs ; make > > ===> gvfs-1.2.1 depends on shared library: cdio_paranoia.0 - not found > > ===>Verifying install for cdio_paranoia.0 in \ > > /usr/ports/sysutils/libcdio > > ===> Returning to build of gvfs-1.2.1 > > Error: shared library "cdio_paranoia.0" does not exist > > There are two easy possible solutions. > a) make gvfs depend on libcdio.so instead of the non-default cdio_paranoia.0 > library > b) Change libcdio to install cdio_paranoia.0 by default. > > Question to gnome@ - Does gvfs really need the cdio_paranoia library, or is > this just a bug > in the port Makefile and it is ok with the libcdio library? a) The configure script of the gvfs port checks for cdio_paranoia library. It needs it for the cdda backend. b) libcdio already got a option for paranoia support and it is default to on. Julian you can do two things now. Either you disable the cdda backend in gvfs with the WITH_CDDA option. Or build libcdio with paranoia support. -Koop > regards > arved___ > 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: Getting MASTER_SITES for sourceforge ports more easily
Folks, Thank you for clarifications. Fetching just works if MASTER_SITES are SF/something. The correct URI may be viewed just using the browser. I've started downloading a file from SF, then paused the download, examined the actual URI the file is downloaded from and verified that URIs generated by Makefiles for my ports are correct. Alexander Churanov, maintainer of devel/boost-* ___ 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: RFC: svn for make fetch
* Eitan Adler (eitanadlerl...@gmail.com) wrote: > I was hoping to get a bit more of a response to a recent posting of > mine with regard to using svn to fetch files for ports > My proposal: > http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html > A summary of what has been going on: > http://wiki.freebsd.org/EitanAdler/ports-svn This was discussed many times before, and this is a bad idea. - No checksums -> security issue - No distfile caching/mirroring -> excess traffic consumption and horrible availability and I hope you're not even thinking of fetching from VCS without specifying exact revision. Some standard way of generating distfiles from VCS may be nice though, if it goes into separate mk-file and supports all major VCS. -- 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: remove BUILD_DEPENDS automatically after install
(portmaster author cc:ed) On Mon, Nov 16, 2009 at 1:06 AM, Erik Trulsson wrote: > On Sun, Nov 15, 2009 at 11:44:04PM +0100, Sandra Kachelmann wrote: >> Is there a reason why BUILD_DEPENDS aren't being removed after a port >> has been installed and if no other installed port depends on it? > > How do you know that the user does not want that port installed? > And what if the user will install 20 other ports afterwards - all of which > is that same port as a BUILD_DEPENDS - should that port be > installed/deinstalled each and every time? It would be nice if this was configurable. Maybe it could be even integrated into portupgrade or portmaster. If such a port is installed directly it could get a package entry DIRECT_INSTALLED=yes in /var/db/pkg/.. or something (there is probably a better way to do this). > (Personally I would be *very* annoyed if, for example, libtool or > automake/autoconf would be reinstalled every time I installed a port which > had one of them as a build-time dependency. There are *lots* of ports which > have one of them in BUILD_DEPENDS, but few if any that has them as > RUN_DEPENDS.) Even nicer if execptions would be configurable. There are loads of ports that install BUILD_DEPENDS that are never used again. cvsup for instance pulls in a gigantic tree of esoteric ports I can't even pronounce. Sure I could install the package, take cvsup-without-gui or even use portsnap but this is not the point here. Sandra ___ 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: RFC: svn for make fetch
Peter Jeremy wrote:
On 2009-Nov-14 15:46:27 +, Thomas Sandford
wrote:
Wesley Shields wrote:
Sure, but it doesn't belong in bsd.*.mk. Turn it into a script and
submit it as a regular port.
...
Surely the whole value/purpose of the ports build infrastructure is to
present a consistent way of doing things rather than different
maintainers doing their own thing and solving problems in different, and
quite possibly sub-optimal ways and/or bloating multiple individual port
Makefiles with what could be kept in a single bsd.*.mk file.
If it affected several hundred ports and/or was visible to the end
user then this might be justification for embedding it into bsd.*.mk.
The ports build infrastructure is already quite large (>20K LOC) and
difficult to follow. The overheads associated with loading bsd.*.mk
files also makes operations like "make index" very time-consuming.
IMHO, bloating it further to marginally simplify life for the
maintainers of ~15 ports is not a good tradeoff.
Wesley's suggestion above sounds like the best solution.
And if the file were (say) bsd.vcs.mk and were pulled in only if one of
USE_SVNFETCH
USE_CVSFETCH
USE_GITFETCH
etc were defined then the impact of the bloat on other ports is minimal.
If you still want to go this way, I'd suggest writing a stand-alone
bsd.vcs.mk that can be .include'd by the port when it needs the
functionality.
Personally I think the performance difference between
.ifdef USE_SVNFETCH
.include "${PORTSDIR}/Mk/bsd.vcs.mk"
.endif
in bsd.port.mk
and only explicitly including it in the ports that use it is marginal,
but I could certainly live with this as a compromise.
--
Thomas Sandford
___
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"
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o ports/140587[MAINTAINER] sysutils/samesame update to version 1.6 o ports/140557ports shells/44bsd-csh ESC file completion and ^D (vie f ports/140555[PATCH] add mirrors to x11-wm/hackedbox f ports/140546The execution result of sysutils/scprotect is inapposi f ports/140525[panic] VMware: Kernel panic while upgrading from 7.2 o ports/140504Add new module and multithreaded support to lang/clisp o ports/140489[NEW PORT] databases/mongodb-devel: High-performance, f ports/140471security/nessus-libnasl fails to compile f ports/140470security/nessus-libraries fails to compile f ports/140466databases/rrdtool update to 1.4.1 o ports/140450shells/scponly: chrooted scp-shell doesn't work f ports/140449ports/security/nmap needs utoconf s ports/140413databases/slony1: Slony1-1.2.16 need upgrade to 1.2.17 o ports/140399Update port: security/webfwlog Add needed patch and ot f ports/140379net-im/pidgin-msn-pecan won't compile o ports/140365[patch] databases/firebird20-client coredumps o ports/140348New port: www/mod_auth_cas Apache 2.0/2.2 compliant mo f ports/140347security/dirmngr needs updated BUILD_DEPENDS requireme o ports/140322update of port www/weave f ports/140303net-mgmt/docsis can not compile filters under amd64 pl o ports/140232Resolve conflicts w/ devel/antlr & devel/pccts o ports/140177new port : textproc/glpi-plugins-DataInjection : This o ports/140176new port : textproc/glpi-plugins-AdditionalReports : T o ports/140174New port: net-mgmt/glpi-plugins-tracker-agent : Agent o ports/140168new port: net-mgmt/glpi-plugins-tracker-server, plugin o ports/140157New port: www/trac-bitten Continuous integration for T f ports/140155Update port: emulators/bsnes update to v0.54 f ports/140146[patch] www/squid: Add squid_fib option for alternate o ports/140133New port: sysutils/Plugtools Manages POSIX users f ports/140109www/validator 0.8.3_1: /usr/local/lib/perl5/site_perl/ o ports/140107[PATCH] Enhance net/nss_ldap to support FreeBSD login o ports/140084[patch] security/amavisd-milter - minor port improveme o ports/140059[MAINTAINER] security/gpa: Mark IGNORE if gpgsm is not o ports/140058[MAINTAINER] security/gpgme: Specifically disable gpgs f ports/140046[PATCH] www/phpsysinfo-dev update to 3.0-RC9 f ports/140007[repocopy] devel/gdb6 to devel/gdb66 f ports/139867mail/isoqlog catch segmentation fault under AMD64 s ports/139848add pre-caching to net-mgmt/nagios rc.d script o ports/139801[patch] port security/gorilla does not work after inst f ports/139680Is editors/emacs out-dated? f ports/139652[devel/icu] Little patch for compiling with gcc44 o ports/139629new port security/pam_memcache: a PAM module for authe o ports/139552science/paraview 2.2.4: ParaView error: InitializeTcl f ports/139460security/snortsam broken on 64 bit platforms f ports/139452[patch] krb5 support in java/openjdk6 o ports/139448[NEW PORT] japanese/asterisk16-sounds: Japanese sound o ports/139435print/cups-smb-backend: Add ability to use difference s ports/139361[FIX] net/ntop 3.3.10 don`t install needed file f ports/139348[PATCH] devel/p5-Gearman-XS: [SUMMARIZE CHANGES] o ports/139341NEW PORT: devel/aegis-devel o ports/139340New port -- x11-fonts/gentium-basic f ports/139317[PATCH] devel/p5-Gearman-XS: [SUMMARIZE CHANGES] o ports/139271[PATCH] sysutils/hpacucli does not work on the amd64 k f ports/139203sysutils/freebsd-snapshot more careful patch not depen o ports/139163[patch] textproc/flex: install info documentation s ports/139150www/bluefish request for DEVELOPMENT version f ports/139140textproc/lucene: fails to install WITH_CONTRIB f ports/139107[patch] sysutils/jfbterm: convert to bsdmake f ports/139075Please repo copy lang/squeak to lang/squeak-dev f ports/139064[PATCH] net/freeradius2: rc.d script should deal with f ports/139060devel/gearmand: Maintainer patch was missing prope
Re: sysutils/libcdio provides no cdio_paranoia.0 for ports/devel/gvfs
Hello Julian! (CC: devel/gvfs maintainer added) Thanks for reporting this issue. On Nov 15, 2009, at 22:51 , Julian H. Stacey wrote: > int would be welcome please with sysutils/libcdio, Paranoia stuff seems > broken, but I'm not clear what's intended, hence mail rather than a send-pr. > > ===> gvfs-1.2.1 depends on shared library: cdio_paranoia.0 - not found > ===>Verifying install for cdio_paranoia.0 in \ > /usr/ports/sysutils/libcdio > ===> Returning to build of gvfs-1.2.1 > Error: shared library "cdio_paranoia.0" does not exist > /usr/ports/devel/gvfs ; make > ===> gvfs-1.2.1 depends on shared library: cdio_paranoia.0 - not found > ===>Verifying install for cdio_paranoia.0 in \ > /usr/ports/sysutils/libcdio > ===> Returning to build of gvfs-1.2.1 > Error: shared library "cdio_paranoia.0" does not exist There are two easy possible solutions. a) make gvfs depend on libcdio.so instead of the non-default cdio_paranoia.0 library b) Change libcdio to install cdio_paranoia.0 by default. Question to gnome@ - Does gvfs really need the cdio_paranoia library, or is this just a bug in the port Makefile and it is ok with the libcdio library? regards arved___ 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: sysutils/libcdio provides no cdio_paranoia.0 for ports/devel/gvfs
Sun, Nov 15, 2009 at 10:51:55PM +0100, Julian H. Stacey wrote:
> A hint would be welcome please with sysutils/libcdio, Paranoia stuff seems
> broken, but I'm not clear what's intended, hence mail rather than a send-pr.
>
> uname -a
> FreeBSD laps.js.berklix.net 7.2-RELEASE FreeBSD 7.2-RELEASE #2: \
> Wed Sep 9 11:33:57 CEST 2009 \
> j...@laps.no.net:/usr/src/sys/i386/compile/LAPS.small i386
>
> cd /usr/ports/net-mgmt/etherape ; make
> ===> gvfs-1.2.1 depends on shared library: cdio_paranoia.0 - not found
> ===>Verifying install for cdio_paranoia.0 in \
> /usr/ports/sysutils/libcdio
> ===> Returning to build of gvfs-1.2.1
> Error: shared library "cdio_paranoia.0" does not exist
Do you have /usr/ports/sysutils/libcdio/work? If yes, remove it
and try the build once again.
Do you really have nothing between "Verifying install for cdio_paranoia.0"
and "Returning to build of gvfs"? Not even a try to build libcdio port?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
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"
