Re: pkg_add can't find target depend package during bulk make package
< snip > >> >> thanks for the references. viq pointed me towards dpb earlier today, I >> still need to read into how it functions. My only outstanding question >> is if it accepts a list of packages to build, or simply builds >> everything. > > It can accept a SUBDIRLIST, see the comments in the file itself. > for completeness, the root of the original issue - pkg_add not being able to install the package - was due to the packages being 0 bytes in size. I am now trying to figure out *why* they were broken [1], which seems to be connected to either symlinking /usr/ports or building ports inside a chroot environment. regards, ~Jason [1] http://marc.info/?l=openbsd-ports&m=122809247327274&w=4
usr/ports as a symlink?
Ports, I am running into some odd behavior when building ports, whereby some ports build fine, while others result in 0 byte packages in my local repository. I believe the problem ports are ones that have packages available on the ftp mirrors as well (retrieved using FETCH_PACKAGES). As a problem, this will then usually surface when attempting to pkg_add the 0 byte package, specifically when the port is needed as a build dependency of a port that I am installing. More information about the problem where this surfaced can be found in a previous post: [1] In my testing, the 0 byte package issue results in two of three cases, either: - /usr/ports is a symlink to another directory (which I have heard is supposed to work, maybe this is not the case) - or when building ports from inside a chroot environment. Elderley.net has an ssh-chroot setup for a special ports user, I don't know if the two chroot's are different. (the third case is building ports with a standard /usr/ports, no symlink, no chroot) so my question: have other folks run into the 0 byte package behavior before, or are there others with /usr/ports as a symlink but without any other problems? I understand that I can remove the FETCH_PACKAGES flag and this will circumvent the problem, but circumvention isn't resolution; I am curious if I am doing something wrong, of if something really is broken. thanks for the time, ~Jason [1] http://marc.info/?l=openbsd-ports&m=122672174517068&w=4
Re: UPDATE : tntnet, cxxtools; RESUBMIT : tntdb
Here is a resubmit of all three of the upgrades for tntnet, cxxtools, and tntdb. Vijay Ramesh [EMAIL PROTECTED] Vijay Ramesh wrote: Sorry, that was acctually a mistake. I got the wrong files. I'll resend the proper ones soon. Vijay Ramesh [EMAIL PROTECTED] Stuart Henderson wrote: On 2008/11/17 03:13, Vijay Ramesh wrote: - -MODULES+=gcc3 -MODGCC3_ARCHES= sparc -MODGCC3_LANGS=c++ why this? Common subdirectories: cxxtools.orig/CVS and cxxtools/CVS diff -u cxxtools.orig/Makefile cxxtools/Makefile --- cxxtools.orig/Makefile Tue May 27 16:48:37 2008 +++ cxxtools/Makefile Sun Nov 16 18:44:11 2008 @@ -2,7 +2,7 @@ COMMENT= various reusable C++-components -DISTNAME= cxxtools-1.4.7 +DISTNAME= cxxtools-1.4.8 SHARED_LIBS += cxxtools 2.0 # .5.0 CATEGORIES=devel @@ -20,10 +20,6 @@ MASTER_SITES= http://www.tntnet.org/download/ MODULES= converters/libiconv - -MODULES+= gcc3 -MODGCC3_ARCHES=sparc -MODGCC3_LANGS= c++ USE_LIBTOOL= Yes diff -u cxxtools.orig/distinfo cxxtools/distinfo --- cxxtools.orig/distinfo Tue May 27 16:48:37 2008 +++ cxxtools/distinfo Sun Nov 16 18:22:45 2008 @@ -1,5 +1,5 @@ -MD5 (cxxtools-1.4.7.tar.gz) = jP6XzC1U9W7ChnQ56MvHJw== -RMD160 (cxxtools-1.4.7.tar.gz) = p84TinDGIjPs1injb3XiEtushBQ= -SHA1 (cxxtools-1.4.7.tar.gz) = gPtlSm4NDrbzHuMM0x+MX+Io2V0= -SHA256 (cxxtools-1.4.7.tar.gz) = Rqjr7xpZuPOAtDksihDzGmFoZG52O4CPRgDcy/wReAA= -SIZE (cxxtools-1.4.7.tar.gz) = 444536 +MD5 (cxxtools-1.4.8.tar.gz) = Fs6SqDvrkl+lE4/JpS1Vrw== +RMD160 (cxxtools-1.4.8.tar.gz) = hC8YDL+hW0ojxPfNciP6wJCy+gY= +SHA1 (cxxtools-1.4.8.tar.gz) = olz18uHYxcfM+TM9gD6Ho60Jwjs= +SHA256 (cxxtools-1.4.8.tar.gz) = lUdtzp9HyHtGgGsHLSMn0iHlCxUCrURBMHTXD8CEveE= +SIZE (cxxtools-1.4.8.tar.gz) = 451807 Only in cxxtools.orig: patches Common subdirectories: cxxtools.orig/pkg and cxxtools/pkg tntdb.tar.gz Description: application/gzip Common subdirectories: tntnet.orig/CVS and tntnet/CVS diff -u tntnet.orig/Makefile tntnet/Makefile --- tntnet.orig/MakefileTue May 27 16:49:31 2008 +++ tntnet/Makefile Sun Nov 16 18:21:32 2008 @@ -2,7 +2,7 @@ COMMENT= modular webapplication server for C++ -DISTNAME= tntnet-1.6.2 +DISTNAME= tntnet-1.6.3 CATEGORIES=www devel HOMEPAGE= http://www.tntnet.org/ diff -u tntnet.orig/distinfo tntnet/distinfo --- tntnet.orig/distinfoTue May 27 16:49:31 2008 +++ tntnet/distinfo Sun Nov 16 18:53:59 2008 @@ -1,5 +1,5 @@ -MD5 (tntnet-1.6.2.tar.gz) = LM7evjvpNe1wd577R84lTA== -RMD160 (tntnet-1.6.2.tar.gz) = qqo96yt23ACCyPZIdvAoBzi4XKo= -SHA1 (tntnet-1.6.2.tar.gz) = K4wSJITe+1FRSILUlh8lAqE4j+0= -SHA256 (tntnet-1.6.2.tar.gz) = PGEPxd6auwiIwD+2EOtfvj/SguW3foejznpErRLaaIQ= -SIZE (tntnet-1.6.2.tar.gz) = 1947826 +MD5 (tntnet-1.6.3.tar.gz) = jbO/zEsywe75KpaF/kqWnQ== +RMD160 (tntnet-1.6.3.tar.gz) = MhtA28sb/ZsbDmkTDCucFBEG/iU= +SHA1 (tntnet-1.6.3.tar.gz) = 3EzwtPtLCmKoBvtbau91zbgS324= +SHA256 (tntnet-1.6.3.tar.gz) = HBZUfk/mwH+P4bnS7rdQyyBhAy8xiA+T8ggLBJ1Uo6Q= +SIZE (tntnet-1.6.3.tar.gz) = 1952122 Common subdirectories: tntnet.orig/patches and tntnet/patches Common subdirectories: tntnet.orig/pkg and tntnet/pkg
Re: UPDATE: archivers/p7zip
On 2008/11/30 16:26, Josh Grosse wrote: > By maintainer. No regressions on i386. or sparc64 or armish.
Re: security/hatchet broken???
On Fri, Nov 28, 2008 at 06:59:34PM +, Sevan / Venture37 wrote:
> giovanni wrote:
>> maybe this is the fix...
>>
>> --- hatchet.origFri Nov 7 08:23:37 2008
>> +++ hatchet Fri Nov 28 12:57:35 2008
>> @@ -214,7 +214,7 @@
>> sub insert_table {
>> my ($date, $points, $rulenum, $action, $interface, $src_host,
>> $src_port, $dst_host, $dst_port, $proto) = @_;
>> $date =~ /^(\w+) (\d+) (\d+)\:(\d+)\:(\d+)$/;
>> - my ($month, $mday, $hour, $min, $sec, $year) = ($1, $2, $3,
>> $4, $5, [split(/ /,localtime)]->[5]);
>> + my ($month, $mday, $hour, $min, $sec, $year) = ($1, $2, $3,
>> $4, $5, [localtime]->[5]);
>> my %months = qw( Jan 0 Feb 1 Mar 2 Apr 3 May 4 Jun 5 Jul 6 Aug
>> 7 Sep 8 Oct 9 Nov 10 Dec 11 );
>> my $epoch = timelocal_nocheck($sec, $min, $hour, $mday,
>> $months{$month}, $year);
>> unless ($existing->{"$epoch $points"}) {
>
> Perfect, that did the trick nicely
> Thank you very much! :)
I've released 0.9.2 which includes this fix, and updated the port as
well.
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/
Re: texmaker-1.8
Why do you manually do the install (do-install) target in non-standard locations (for the icons), while the included install target does this perfectly? Kind Regards Thomas On Sun, Nov 30, 2008 at 2:59 PM, Alexandr Shadchin <[EMAIL PROTECTED]> wrote: > Hi, > > On Sun, 30 Nov 2008 00:30:15 +0500, Thomas Delaet <[EMAIL PROTECTED]> wrote: > >> Hi Alexandr (and ports@) >> >> Some time ago, I submitted an update to my texmaker port to 1.7.1. I >> see you used the old port as a basis. For example, the WANTLIB and >> LIB_DEPENDS are not updated. >> >> I updated my patch also to 1.8. In attach. >> >> Kind Regards >> >> Thomas >> > > > I corrected your patch. In attach. > > -- > Best Regards, > Alexandr Shadchin -- Thomas
Re: update: -tools and -contrib subpackages for subversion-1.5.4
On Sun, Nov 30, 2008 at 05:19:22PM +0100, Steven Mestdagh wrote: > Stefan Sperling [2008-11-30, 15:19:38]: > > Hello, > > > > the diff below splits extra and user-contributed scripts and tools out > > of the -main package into separate -tools and -contrib packages. > ... > > The stuff in -tools is maintained by the Subversion project itself, > > and has the same copyright holder and license. > > First question, is it necessary to package this separately from -main ? It's generally not a good guideline for openbsd packages. We frown heavily on added complexity. The only cases where subpackages make sense for us are: - big extra dependencies where one tiny piece - licence issues - big size issues. If it's just a few small tools or contrib scripts, it really doesn't matter.
UPDATE: archivers/p7zip
By maintainer. No regressions on i386.
Applicable changes:
LZMA supported for .zip archives.
Improved password prompting for encrypted archives.
UDF, XAR, DMG/HFS archives now supported for unpack.
The -t switch now usable with list and extract commands.
Timestamp bug fix for .zip and .rar archives.
Other changes include linux or windows related fixes, and the addition
of a GUI version (7zG), in the source but not part of the standard build.
I have not bothered to include it, as it is experimintal and requires
manual configuration and install.
Index: Makefile
===
RCS file: /cvs/ports/archivers/p7zip/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile10 Jun 2008 03:24:37 - 1.8
+++ Makefile30 Nov 2008 19:56:52 -
@@ -5,7 +5,7 @@
COMMENT-main= file archiver with high compression ratio
COMMENT-rar= rar modules for p7zip
-V= 4.58
+V= 4.61
DISTNAME= p7zip_${V}_src_all
PKGNAME= p7zip-${V}
PKGNAME-main= p7zip-${V}
Index: distinfo
===
RCS file: /cvs/ports/archivers/p7zip/distinfo,v
retrieving revision 1.7
diff -u -r1.7 distinfo
--- distinfo10 Jun 2008 03:24:37 - 1.7
+++ distinfo30 Nov 2008 19:57:19 -
@@ -1,5 +1,5 @@
-MD5 (p7zip_4.58_src_all.tar.bz2) = MVsYQQLBfElW9TIY2XMiLQ==
-RMD160 (p7zip_4.58_src_all.tar.bz2) = LDGrZXJ13AHS0jxd4jJ9XuRvToo=
-SHA1 (p7zip_4.58_src_all.tar.bz2) = dSW7sS7JQYbp5A02FM39X29jyrY=
-SHA256 (p7zip_4.58_src_all.tar.bz2) =
UjkVWbd4LSutRbeDV56pgl8oZwum8jT9DZJIrz6Cvt0=
-SIZE (p7zip_4.58_src_all.tar.bz2) = 1948207
+MD5 (p7zip_4.61_src_all.tar.bz2) = oBQIrE70licP+TbbITCbkg==
+RMD160 (p7zip_4.61_src_all.tar.bz2) = 9AEGdjSYejfELbRXIzagnZgI/YQ=
+SHA1 (p7zip_4.61_src_all.tar.bz2) = NyI/8fEt07oNP5W1Mb+9Afl0dT8=
+SHA256 (p7zip_4.61_src_all.tar.bz2) =
zMMJxkEbPputxz8sPhwEadMz0JoeowSBxKa+B4Lb4GE=
+SIZE (p7zip_4.61_src_all.tar.bz2) = 2483533
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/archivers/p7zip/pkg/PLIST-main,v
retrieving revision 1.5
diff -u -r1.5 PLIST-main
--- pkg/PLIST-main 16 Dec 2007 11:22:29 - 1.5
+++ pkg/PLIST-main 30 Nov 2008 21:18:06 -
@@ -3,11 +3,11 @@
bin/7za
bin/7zr
lib/p7zip/
-lib/p7zip/7z
[EMAIL PROTECTED] lib/p7zip/7z
lib/p7zip/7z.so
-lib/p7zip/7zCon.sfx
-lib/p7zip/7za
-lib/p7zip/7zr
[EMAIL PROTECTED] lib/p7zip/7zCon.sfx
[EMAIL PROTECTED] lib/p7zip/7za
[EMAIL PROTECTED] lib/p7zip/7zr
lib/p7zip/Codecs/
@man man/man1/7z.1
@man man/man1/7za.1
Re: UPDATE: graphics/GraphicsMagick
On Sun, Nov 30, 2008 at 09:10:16PM +0100, LÉVAI Dániel wrote: > > No. All you need is a global > > > > BUILD_DEPENDS= :ghostscript-*:print/ghostscript/gnu > > > > regardless of no_x11 or not. The whole purpose of this dependency > > is to always get the same delegates.mgk that uses pnmraw for > > gs-color. > But the whole point of the no_gs FLAVOR was that if one doesn't need > ghostscript, then don't install it with GM (ie. don't make gs mandatory > for GM). With your proposal, gs would always get installed, no matter > what... No, it wouldn't. It's just a BUILD dependency. People can install GraphicsMagick without having to install ghostscript, and you can pkg_delete ghostscript after building GraphicsMagick. > And it's no use either to put that BUILD_DEPENDS only outside > FLAVOR:no_x11, because if one already has a no_x11 FLAVORed ghostscript > installed, then building an x11 enabled GraphicsMagick would want to > install an x11 enabled ghostscript, which is certainly not what the > user wanted in the first place. No, having any flavor of ghostscript installed is enough to satisfy the BUILD_DEPENDS. > So with the no_gs FLAVOR added, one > could build an x11 enabled GM, and can also have a no_x11 FLAVORed > ghostscript side-by-side. > Besides, one could of course build an x11 and gs free GM too, with > FLAVOR="no_gs no_x11". Repeating myself: when building GraphicsMagick, with or without your no_gs flavor, and with or without ghostscript installed, the *only* difference on the installed files is delegates.mgk, and it looks like this: --- /usr/local/lib/GraphicsMagick/config/delegates.mgk Sun Nov 30 12:03:18 2008 +++ delegates.mgk Sun Nov 30 11:51:56 2008 @@ -83,7 +83,7 @@ - + The difference between a GraphicsMagick package with FLAVOR=no_gs and without it would be nothing except the latter would have a run dependency on ghostscript. And since there's no need for a run dependency at all, there would be absolutely no difference. If you don't believe me, do what I did: - run make fake on GraphicsMagick with and without FLAVOR=no_gs. - save or rename the WRKDIRs. - temporarily move ghostscript out of scope, or pkg_delete it and comment the BUILD_ and RUN_DEPENDS from GraphicsMagick. - again run make fake on GraphicsMagick with and without FLAVOR=no_gs. - compare the contents of the saved and new WRKDIRs against each other. Ciao, Kili
Re: UPDATE: graphics/GraphicsMagick
On Sunday 30 November 2008 19.22.22 Matthias Kilian wrote: > On Sun, Nov 30, 2008 at 02:18:26PM +0100, LÉVAI Dániel wrote: > > > After a closer look at configure.ac and at the source trees after > > > make configure (with ghostscript installed and uninstalled), I > > > think you really don't need the no_gs flavor. The only relevant > > > part that of GraphicsMagick that will be different is > > > delegates.mgk, and it only differs in what ghostscript device > > > will be used for the gs-color delegate (pnmraw vs. ppmraw). > > > > > > So you can omit the no_gs flavor and drop the RUN_DEPENDS on > > > ghostscript (but not the BUILD_DEPENDS). > > > > You mean to leave the BUILD_DEPENDS only if we are not building a > > no_x11 FLAVOR, I presume? > > No. All you need is a global > > BUILD_DEPENDS= :ghostscript-*:print/ghostscript/gnu > > regardless of no_x11 or not. The whole purpose of this dependency > is to always get the same delegates.mgk that uses pnmraw for > gs-color. But the whole point of the no_gs FLAVOR was that if one doesn't need ghostscript, then don't install it with GM (ie. don't make gs mandatory for GM). With your proposal, gs would always get installed, no matter what... And it's no use either to put that BUILD_DEPENDS only outside FLAVOR:no_x11, because if one already has a no_x11 FLAVORed ghostscript installed, then building an x11 enabled GraphicsMagick would want to install an x11 enabled ghostscript, which is certainly not what the user wanted in the first place. So with the no_gs FLAVOR added, one could build an x11 enabled GM, and can also have a no_x11 FLAVORed ghostscript side-by-side. Besides, one could of course build an x11 and gs free GM too, with FLAVOR="no_gs no_x11". Hope I'm making sense, and please correct me if I'm wrong! Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
On Sun, Nov 30, 2008 at 02:18:26PM +0100, LÉVAI Dániel wrote: > > After a closer look at configure.ac and at the source trees after > > make configure (with ghostscript installed and uninstalled), I think > > you really don't need the no_gs flavor. The only relevant part that > > of GraphicsMagick that will be different is delegates.mgk, and it > > only differs in what ghostscript device will be used for the gs-color > > delegate (pnmraw vs. ppmraw). > > > > So you can omit the no_gs flavor and drop the RUN_DEPENDS on > > ghostscript (but not the BUILD_DEPENDS). > You mean to leave the BUILD_DEPENDS only if we are not building a no_x11 > FLAVOR, I presume? No. All you need is a global BUILD_DEPENDS= :ghostscript-*:print/ghostscript/gnu regardless of no_x11 or not. The whole purpose of this dependency is to always get the same delegates.mgk that uses pnmraw for gs-color. Ciao, Kili
Re: UPDATE: graphics/gimp
On Mon, Nov 24, 2008 at 02:49:23PM +0100, Giovanni Bechis wrote: > Trivial update to latest version, some bugs fixed. > Tested @amd64. Looks fine. Objections from anyone? Ciao, Kili
Re: update: -tools and -contrib subpackages for subversion-1.5.4
On Sun, Nov 30, 2008 at 05:19:22PM +0100, Steven Mestdagh wrote:
> Stefan Sperling [2008-11-30, 15:19:38]:
> > Hello,
> >
> > the diff below splits extra and user-contributed scripts and tools out
> > of the -main package into separate -tools and -contrib packages.
> ...
> > The stuff in -tools is maintained by the Subversion project itself,
> > and has the same copyright holder and license.
>
> First question, is it necessary to package this separately from -main ?
Not absolutely, but I thought not everyone might want these files
on their disks.
> > The stuff in -contrib may have different licenses and copyright holders
> > than Subversion proper.
>
> Have you checked whether those licenses allow us to redistribute it?
Not myself, but I'd be very surprised if the Subversion project
didn't check the license for sanity before including any of this.
I can go through them though, just to make sure.
> > One quirk:
> > The -tools subpackages has redundant libs, which show up during
> > 'make lib-depends-check:
> >
> > /usr/ports/packages/i386/all/subversion-tools-1.5.4.tgz:
> > Extra: svn_client-1.1
> > Extra: svn_diff-1.1
> > Extra: svn_ra-1.1
> > Extra: svn_ra_local-1.1
> > Extra: svn_ra_neon-1.1
> > Extra: svn_ra_svn-1.1
> > Extra: svn_wc-1.1
> >
> > Without those extra deps, it does not properly depend on the -main package,
> > and trying to install it without having the -main package installed
> > fails like this:
> >
> > /usr/ports/packages/i386/al
> > $ env SUBPACKAGE=-tools make install
> > ===> Verifying specs: svn_delta-1.>=1.1 svn_fs-1.>=1.1 svn_fs_base-1.>=1.1
> > svn_fs_fs-1.>=1.1 svn_fs_util-1.>=1.1 svn_repos-1.>=1.1 svn_subr-1.>=1.1
> > expat db z apr-1 aprutil-1 c iconv intl
> > Missing library for svn_delta-1.>=1.1
> > Missing library for svn_fs-1.>=1.1
> > Missing library for svn_fs_base-1.>=1.1
> > Missing library for svn_fs_fs-1.>=1.1
> > Missing library for svn_fs_util-1.>=1.1
> > Missing library for svn_repos-1.>=1.1
> > Missing library for svn_subr-1.>=1.1
> > Fatal error
> > *** Error code 1
> >
> > I'd expect the dependency handling to work without the extra libs,
> > but this does not seem to be the case... no idea where the problem is.
>
> do the tools require the libraries or not? if they do, then you will need
> the main package to be installed.
Yes, the -contrib and -tools should depend on the main package.
The problem is that this depedency doesn't work for the -tools package
if I strip down library dependencies according to lib-depends-check.
The tools package has to depend on more libraries than it striclty
needs for the dependency on -main to work. I don't know why.
> > To reproduce, change these lines in the Makefile:
> >
> > . for _lib in ${SVN_LIBS}
> > LIB_DEPENDS-tools+= ${_lib}.>=${SO_VERSION}:${PKGNAME}:${BUILD_PKGPATH}
> > . endfor
> >
> > to this:
> >
> > . for _lib in svn_delta-1 svn_fs-1 svn_fs_base-1 svn_fs_fs-1 \
> > svn_fs_util-1 svn_repos-1 svn_subr-1
> > LIB_DEPENDS-tools+= ${_lib}.>=${SO_VERSION}:${PKGNAME}:${BUILD_PKGPATH}
> > . endfor
> >
> > This change causes lib-depends check to be happy, but the dependency
> > of -tools on -main to fail.
>
> haven't tried it, but maybe try devel/subversion,-main instead of
> just BUILD_PKGPATH?
jasper@ told me (in person at OpenCON) that I could use BUILD_PKGPATH
instead of the explicitly specifying devel/subversion,main.
I'll try to see if it makes a difference though.
> > -PSEUDO_FLAVORS=no_bindings no_ap2
> > +PSEUDO_FLAVORS=no_bindings no_ap2 no_contrib no_tools
>
> I don't think this requires extra pseudo flavors? It doesn't seem to pull in
> a great load of extra dependencies at build time.
OK, I can make the packages build by default.
I'll post an update later, right now I need to pack up and travel
homewards from opencon :(
Thanks,
Stefan
Re: update: -tools and -contrib subpackages for subversion-1.5.4
Stefan Sperling [2008-11-30, 15:19:38]:
> Hello,
>
> the diff below splits extra and user-contributed scripts and tools out
> of the -main package into separate -tools and -contrib packages.
...
> The stuff in -tools is maintained by the Subversion project itself,
> and has the same copyright holder and license.
First question, is it necessary to package this separately from -main ?
> The stuff in -contrib may have different licenses and copyright holders
> than Subversion proper.
Have you checked whether those licenses allow us to redistribute it?
> One quirk:
> The -tools subpackages has redundant libs, which show up during
> 'make lib-depends-check:
>
> /usr/ports/packages/i386/all/subversion-tools-1.5.4.tgz:
> Extra: svn_client-1.1
> Extra: svn_diff-1.1
> Extra: svn_ra-1.1
> Extra: svn_ra_local-1.1
> Extra: svn_ra_neon-1.1
> Extra: svn_ra_svn-1.1
> Extra: svn_wc-1.1
>
> Without those extra deps, it does not properly depend on the -main package,
> and trying to install it without having the -main package installed
> fails like this:
>
> /usr/ports/packages/i386/al
> $ env SUBPACKAGE=-tools make install
> ===> Verifying specs: svn_delta-1.>=1.1 svn_fs-1.>=1.1 svn_fs_base-1.>=1.1
> svn_fs_fs-1.>=1.1 svn_fs_util-1.>=1.1 svn_repos-1.>=1.1 svn_subr-1.>=1.1
> expat db z apr-1 aprutil-1 c iconv intl
> Missing library for svn_delta-1.>=1.1
> Missing library for svn_fs-1.>=1.1
> Missing library for svn_fs_base-1.>=1.1
> Missing library for svn_fs_fs-1.>=1.1
> Missing library for svn_fs_util-1.>=1.1
> Missing library for svn_repos-1.>=1.1
> Missing library for svn_subr-1.>=1.1
> Fatal error
> *** Error code 1
>
> I'd expect the dependency handling to work without the extra libs,
> but this does not seem to be the case... no idea where the problem is.
do the tools require the libraries or not? if they do, then you will need
the main package to be installed.
> To reproduce, change these lines in the Makefile:
>
> . for _lib in ${SVN_LIBS}
> LIB_DEPENDS-tools+= ${_lib}.>=${SO_VERSION}:${PKGNAME}:${BUILD_PKGPATH}
> . endfor
>
> to this:
>
> . for _lib in svn_delta-1 svn_fs-1 svn_fs_base-1 svn_fs_fs-1 \
> svn_fs_util-1 svn_repos-1 svn_subr-1
> LIB_DEPENDS-tools+= ${_lib}.>=${SO_VERSION}:${PKGNAME}:${BUILD_PKGPATH}
> . endfor
>
> This change causes lib-depends check to be happy, but the dependency
> of -tools on -main to fail.
haven't tried it, but maybe try devel/subversion,-main instead of
just BUILD_PKGPATH?
> -PSEUDO_FLAVORS= no_bindings no_ap2
> +PSEUDO_FLAVORS= no_bindings no_ap2 no_contrib no_tools
I don't think this requires extra pseudo flavors? It doesn't seem to pull in
a great load of extra dependencies at build time.
update: -tools and -contrib subpackages for subversion-1.5.4
Hello,
the diff below splits extra and user-contributed scripts and tools out
of the -main package into separate -tools and -contrib packages.
It also adds many nuggets from the contrib/ and tools/ directories
in the Subversion source tree that weren't previously packaged on OpenBSD.
So instead of hunting down these scripts in the Subversion source
tarball, you can now install the -contrib and -tools packages.
Highlights include:
* two Subversion plugins for emacs
* svnmucc (combine a list of mv, cp and rm commands on URLs into
a single commit)
* the svn_load_dirs.pl script referenced in the svn book as the way to
handle vendor branches
* mod_dontdothat (source code for an additional apache module allowing
admins to block reguests such as "list the entire log for all
revisions of all directories in this repository" -- not compiled
yet, I'll have to figure out how to compile stuff with aspx for
apache2, see mod_dontdothat/README for compilation instructions)
There are also countless possibly useful examples scripts for both the
server- and client-side.
The stuff in -tools is maintained by the Subversion project itself,
and has the same copyright holder and license.
The stuff in -contrib may have different licenses and copyright holders
than Subversion proper.
One quirk:
The -tools subpackages has redundant libs, which show up during
'make lib-depends-check:
/usr/ports/packages/i386/all/subversion-tools-1.5.4.tgz:
Extra: svn_client-1.1
Extra: svn_diff-1.1
Extra: svn_ra-1.1
Extra: svn_ra_local-1.1
Extra: svn_ra_neon-1.1
Extra: svn_ra_svn-1.1
Extra: svn_wc-1.1
Without those extra deps, it does not properly depend on the -main package,
and trying to install it without having the -main package installed
fails like this:
/usr/ports/packages/i386/al
$ env SUBPACKAGE=-tools make install
===> Verifying specs: svn_delta-1.>=1.1 svn_fs-1.>=1.1 svn_fs_base-1.>=1.1
svn_fs_fs-1.>=1.1 svn_fs_util-1.>=1.1 svn_repos-1.>=1.1 svn_subr-1.>=1.1 expat
db z apr-1 aprutil-1 c iconv intl
Missing library for svn_delta-1.>=1.1
Missing library for svn_fs-1.>=1.1
Missing library for svn_fs_base-1.>=1.1
Missing library for svn_fs_fs-1.>=1.1
Missing library for svn_fs_util-1.>=1.1
Missing library for svn_repos-1.>=1.1
Missing library for svn_subr-1.>=1.1
Fatal error
*** Error code 1
I'd expect the dependency handling to work without the extra libs,
but this does not seem to be the case... no idea where the problem is.
To reproduce, change these lines in the Makefile:
. for _lib in ${SVN_LIBS}
LIB_DEPENDS-tools+= ${_lib}.>=${SO_VERSION}:${PKGNAME}:${BUILD_PKGPATH}
. endfor
to this:
. for _lib in svn_delta-1 svn_fs-1 svn_fs_base-1 svn_fs_fs-1 \
svn_fs_util-1 svn_repos-1 svn_subr-1
LIB_DEPENDS-tools+= ${_lib}.>=${SO_VERSION}:${PKGNAME}:${BUILD_PKGPATH}
. endfor
This change causes lib-depends check to be happy, but the dependency
of -tools on -main to fail.
Thanks,
Stefan
Index: Makefile
===
RCS file: /cvs/ports/devel/subversion/Makefile,v
retrieving revision 1.52
diff -u -p -r1.52 Makefile
--- Makefile18 Nov 2008 23:08:01 - 1.52
+++ Makefile30 Nov 2008 14:18:22 -
@@ -5,15 +5,19 @@ COMMENT-perl= perl interface to subversi
COMMENT-python=python interface to subversion
COMMENT-ruby= ruby interface to subversion
COMMENT-ap2= apache2 subversion modules
+COMMENT-contrib= user-contributed utilities for subversion
+COMMENT-tools= extra utilities for subversion
VERSION= 1.5.4
DISTNAME= subversion-${VERSION}
PKGNAME= ${DISTNAME}
-PKGNAME-main= ${DISTNAME}p0
+PKGNAME-main= ${DISTNAME}p1
PKGNAME-perl= p5-SVN-${VERSION}
PKGNAME-python=py-subversion-${VERSION}p0
PKGNAME-ruby= ruby-subversion-${VERSION}p0
PKGNAME-ap2= ap2-subversion-${VERSION}p0
+PKGNAME-contrib= subversion-contrib-${VERSION}
+PKGNAME-tools= subversion-tools-${VERSION}
SO_VERSION=1.1
SVN_LIBS= svn_client-1 svn_delta-1 svn_diff-1 svn_fs-1 \
@@ -37,7 +41,7 @@ PERMIT_DISTFILES_FTP= Yes
MASTER_SITES= ${HOMEPAGE}/tarballs/
-PSEUDO_FLAVORS=no_bindings no_ap2
+PSEUDO_FLAVORS=no_bindings no_ap2 no_contrib no_tools
FLAVOR?=
MODULES= devel/gettext lang/python
@@ -55,19 +59,48 @@ WANTLIB-main= ${WANTLIB} c crypto iconv
asn1 gssapi krb5
RUN_DEPENDS-main= ${MODGETTEXT_RUN_DEPENDS}
+.if !${FLAVOR:L:Mno_contrib}
+MULTI_PACKAGES+= -contrib
+RUN_DEPENDS-contrib= ::shells/bash :${PKGNAME}:${BUILD_PKGPATH}
+WANTLIB-contrib= ${WANTLIB} apr-1 aprutil-1 asn1 c crypto gssapi \
+ iconv intl krb5 neon sasl2 ssl
+. for _lib in ${SVN_LIBS}
+LIB_DEPENDS-contrib+= ${_lib}.>=${SO_VERSION}:${PKGNAME}:${BUILD_PKGPATH}
+. endfor
+.endif
+
+.if !${FLAVOR:L:Mno_tools}
+MULTI_PACKAGES+= -tools
+RUN_DEPENDS-tools= :${PKGNAME}:${BUIL
Re: texmaker-1.8
Hi, On Sun, 30 Nov 2008 00:30:15 +0500, Thomas Delaet <[EMAIL PROTECTED]> wrote: Hi Alexandr (and ports@) Some time ago, I submitted an update to my texmaker port to 1.7.1. I see you used the old port as a basis. For example, the WANTLIB and LIB_DEPENDS are not updated. I updated my patch also to 1.8. In attach. Kind Regards Thomas I corrected your patch. In attach. -- Best Regards, Alexandr Shadchin texmaker.tar.gz Description: GNU Zip compressed data
Re: UPDATE: graphics/GraphicsMagick
On Sunday 30 November 2008 12.59.51 Matthias Kilian wrote: > On Sun, Nov 30, 2008 at 11:30:06AM +0100, LÉVAI Dániel wrote: > > > > Then the port now is broken, because no matter what, > > > > GraphicsMagick picks up ghostscript. So keeping "CONFIGURE_ARGS > > > > += > > > > --without-gslib" only matters if we also remove the > > > > BUILD_DEPENDS+= > > > > > > > > :ghostscript-*:print/ghostscript/gnu[,no_x11] RUN_DEPENDS+= > > > > : > > > > :ghostscript-*:print/ghostscript/gnu[,no_x11] lines. > > > > > > No, --without-gslib just ensures that GraphicsMagick isn't linked > > > against libgs, even if libgs is available. It does *not* stop > > > GraphicsMagick from using the ghostscript binary at runtime (for > > > whatever purpose; I didn't yet have the time to look at > > > GraphicsMagick). > > > > Aha! I can see clearly now :) In the spirit of that, it's a new > > patch: > > > > http://leva.ecentrum.hu/patches/GraphicsMagick_1.2.6+no_gs.diff > > After a closer look at configure.ac and at the source trees after > make configure (with ghostscript installed and uninstalled), I think > you really don't need the no_gs flavor. The only relevant part that > of GraphicsMagick that will be different is delegates.mgk, and it > only differs in what ghostscript device will be used for the gs-color > delegate (pnmraw vs. ppmraw). > > So you can omit the no_gs flavor and drop the RUN_DEPENDS on > ghostscript (but not the BUILD_DEPENDS). You mean to leave the BUILD_DEPENDS only if we are not building a no_x11 FLAVOR, I presume? Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
On Sun, Nov 30, 2008 at 11:30:06AM +0100, LÉVAI Dániel wrote: > > > Then the port now is broken, because no matter what, GraphicsMagick > > > picks up ghostscript. So keeping "CONFIGURE_ARGS += > > > --without-gslib" only matters if we also remove the > > > BUILD_DEPENDS+= > > > :ghostscript-*:print/ghostscript/gnu[,no_x11] RUN_DEPENDS+= > > > :ghostscript-*:print/ghostscript/gnu[,no_x11] lines. > > > > No, --without-gslib just ensures that GraphicsMagick isn't linked > > against libgs, even if libgs is available. It does *not* stop > > GraphicsMagick from using the ghostscript binary at runtime (for > > whatever purpose; I didn't yet have the time to look at > > GraphicsMagick). > > > Aha! I can see clearly now :) In the spirit of that, it's a new patch: > > http://leva.ecentrum.hu/patches/GraphicsMagick_1.2.6+no_gs.diff After a closer look at configure.ac and at the source trees after make configure (with ghostscript installed and uninstalled), I think you really don't need the no_gs flavor. The only relevant part that of GraphicsMagick that will be different is delegates.mgk, and it only differs in what ghostscript device will be used for the gs-color delegate (pnmraw vs. ppmraw). So you can omit the no_gs flavor and drop the RUN_DEPENDS on ghostscript (but not the BUILD_DEPENDS). Then you'll just get an error message whenever ghostscript isn't installed and GraphicsMagick needs a gs-* delegate: $ gm display tiger.eps sh: gs: not found gm display: "gs" -q -dBATCH -dMaxBitmap=5000 -dNOPAUSE -sDEVICE=pnmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -g661x682 -r86.4681x86.4106 "-sOutputFile=/tmp/gmLXBB5a" -- "/tmp/gmD" -c quit. sh: gs: not found gm display: "gs" -q -dBATCH -dMaxBitmap=5000 -dNOPAUSE -sDEVICE=pnmraw -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -g661x682 -r86.4681x86.4106 "-sOutputFile=/tmp/gmLXBB5a" -- "/tmp/gmD" -c quit. gm display: DPS library is not available (tiger.eps). Ciao, Kili -- Now I remember why I don't remember the last time I finished a bottle of this shit. -- Mike Erdely, about Gulden Draak
NEW: audio/wavpack
Hi, DESCR: WavPack is a completely open audio compression format providing lossless, high-quality lossy, and a unique hybrid compression mode. The compression ratio depends on the source material, but generally is between 30% and 70%. The hybrid mode provides all the advantages of lossless compression with an additional bonus. Instead of creating a single file, this mode creates both a relatively small, high-quality lossy file that can be used all by itself, and a "correction" file that (when combined with the lossy file) provides full lossless restoration. For some users this means never having to choose between lossless and lossy compression. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ wavpack.tar.gz Description: GNU Zip compressed data
Re: UPDATE: graphics/GraphicsMagick
On Sunday 30 November 2008 11.08.25 Matthias Kilian wrote: > On Sun, Nov 30, 2008 at 09:35:17AM +0100, LÉVAI Dániel wrote: > > > FYI: only the gtk flavor of ghostscript contains libgs, so a > > > GraphicsMagick flavor depending on libgs (i.e. --with-gslib) > > > would have to explicitely depend on ghostscript's gtk flavor. > > > > > > So, please just keep the CONFIGURE_ARGS += --without-gslib in > > > GraphicsMagick. > > > > Then the port now is broken, because no matter what, GraphicsMagick > > picks up ghostscript. So keeping "CONFIGURE_ARGS += > > --without-gslib" only matters if we also remove the > > BUILD_DEPENDS+= > > :ghostscript-*:print/ghostscript/gnu[,no_x11] RUN_DEPENDS+= > > :ghostscript-*:print/ghostscript/gnu[,no_x11] lines. > > No, --without-gslib just ensures that GraphicsMagick isn't linked > against libgs, even if libgs is available. It does *not* stop > GraphicsMagick from using the ghostscript binary at runtime (for > whatever purpose; I didn't yet have the time to look at > GraphicsMagick). > Aha! I can see clearly now :) In the spirit of that, it's a new patch: http://leva.ecentrum.hu/patches/GraphicsMagick_1.2.6+no_gs.diff Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: UPDATE: graphics/GraphicsMagick
On Sun, Nov 30, 2008 at 09:35:17AM +0100, LÉVAI Dániel wrote: > > FYI: only the gtk flavor of ghostscript contains libgs, so a > > GraphicsMagick flavor depending on libgs (i.e. --with-gslib) would > > have to explicitely depend on ghostscript's gtk flavor. > > > > So, please just keep the CONFIGURE_ARGS += --without-gslib in > > GraphicsMagick. > > > Then the port now is broken, because no matter what, GraphicsMagick > picks up ghostscript. So keeping "CONFIGURE_ARGS += --without-gslib" > only matters if we also remove the > BUILD_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] > RUN_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] > lines. No, --without-gslib just ensures that GraphicsMagick isn't linked against libgs, even if libgs is available. It does *not* stop GraphicsMagick from using the ghostscript binary at runtime (for whatever purpose; I didn't yet have the time to look at GraphicsMagick). Ciao, Kil
Re: UPDATE: graphics/GraphicsMagick
On Saturday 29 November 2008 22.36.56 Matthias Kilian wrote: > On Sat, Nov 29, 2008 at 10:08:12AM -0500, Okan Demirmen wrote: > > Oh, and I see that GraphicsMagick doesn't recommend gslib, so maybe > > we should just disable that by default instead of making it a > > FLAVOR; > > FYI: only the gtk flavor of ghostscript contains libgs, so a > GraphicsMagick flavor depending on libgs (i.e. --with-gslib) would > have to explicitely depend on ghostscript's gtk flavor. > > So, please just keep the CONFIGURE_ARGS += --without-gslib in > GraphicsMagick. > Then the port now is broken, because no matter what, GraphicsMagick picks up ghostscript. So keeping "CONFIGURE_ARGS += --without-gslib" only matters if we also remove the BUILD_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] RUN_DEPENDS+= :ghostscript-*:print/ghostscript/gnu[,no_x11] lines. Daniel -- LEVAI Daniel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
