Damn it! pkgsrc stupidity again

Let's see if there's even a MODICUM of common sense in this scheme. First, 
everyone and their dog has said that it'd be nice if "make update" doesn't 
delete the package BEFORE trying to build the new one. Whatever - nobody's 
gotten around to fixing that.

However, why does "make update" delete a package BEFORE reporting the 
relevant package as insecure?

This isn't user friendly. It isn't even admin friendly!

John Klos

Re: Damn it! pkgsrc stupidity again

On Tue, Oct 31, 2006 at 04:30:20PM -0800, John Klos wrote:
> 
> However, why does "make update" delete a package BEFORE reporting the 
> relevant package as insecure?

Because it is checking the new package when building it.

> This isn't user friendly. It isn't even admin friendly!

	-is

--

-- 
seal your e-mail: http://www.gnupg.org/

pkg_install and mk/ patch for user-destdir support

Hi all,

during the work of getting the packages I use fully user-destdir save,
I've stumpled over a bug in pkg_install. The first patch tries to fix
that, but I'd like to have another opinion as the code is quite messy
and full of side effects. The problem is that without the patch pushout
will be called with NULL when a rename failed and when any
 <at> chmod/ <at> chown/ <at> chgrp is active, path names relative to PREFIX end up as
arguments for programs called with cwd /.

The second patch adds package-install, which behaves like package for
normal packages and like bin-install with forced rebuild for those
supporting DESTDIR. It is intended esp. as dependency target in
combination with bin-install.

Joerg

Index: add/extract.c
===================================================================
RCS file: /repo/netbsd/src/usr.sbin/pkg_install/add/extract.c,v
retrieving revision 1.38
diff -u -r1.38 extract.c
--- add/extract.c	11 May 2006 23:50:15 -0000	1.38
+++ add/extract.c	1 Nov 2006 00:16:11 -0000
 <at>  <at>  -243,7 +243,8  <at>  <at> 
 				} else {
 					/* rename failed, try copying with a big tar command */
 					if (last_chdir != Directory) {
-						pushout(last_chdir);

multimedia/vlc link problems on -current (4.99.3)

Before I file a PR, I thought I'd ask if someone already has a fix for this
problem.  Or do I have the wrong C++ libraries installed?

gmake[2]: Entering directory `/home/phil/netbsd/pkgsrc/multimedia/vlc/work/vlc-0.8.5'
...
c++ -Wsign-compare -Wsign-compare -Wall -O2 -I/home/phil/netbsd/pkgsrc/multimedia/vlc/work/.buildlink/include
-I/home/phil/netbsd/pkgsrc/multimedia/vlc/work/.buildlink/include/faad2 -I/home/phil/netbsd/pkgsrc/multimedia
/vlc/work/.buildlink/include/SDL -DGLX_GLXEXT_LEGACY -I/home/phil/netbsd/pkgsrc/multimedia/vlc/work/.buildlink
/include/freetype2 -pthread -pipe -Wl,-R/usr/pkg/xorg/lib -Wl,-R/usr/pkg/lib -o vlc vlc-vlc.o
-pthread  
-L/home/phil/netbsd/pkgsrc/multimedia/vlc/work/.x11-buildlink/lib -L/home/phil/netbsd/pkgsrc/multimedia/vlc/work
/.buildlink/lib src/libvlc.a ./modules/misc/memcpy/libmemcpymmx.a
./modules/video_chroma/libi420_rgb_mmx.a 
./modules/video_chroma/libi422_yuy2_mmx.a ./modules/video_chroma/libi420_ymga_mmx.a ./modules/video_chroma/
libi420_yuy2_mmx.a ./modules/misc/memcpy/libmemcpymmxext.a
./modules/misc/memcpy/libmemcpy3dn.a ./modules/
demux/libmkv.a ./modules/codec/ffmpeg/libffmpeg.a
./modules/stream_out/libstream_out_switcher.a -lrt -lintl 
-lmatroska -lebml -L/home/phil/netbsd/pkgsrc/multimedia/vlc/work/.buildlink /lib/libavcodec
/usr/pkg/lib/libavcodec.a -lz -lm
/home/phil/netbsd/pkgsrc/multimedia/vlc/work/.x11-buildlink/lib/libmatroska.a(KaxBlock.o):
In function `libmatroska::KaxInternalBlo
ck::~KaxInternalBlock()':
KaxBlock.cpp:(.text+0x1ed): undefined reference to `std::__default_alloc_template<true,
0>::deallocate(void*, unsigned int)'
KaxBlock.cpp:(.text+0x211): undefined reference to `std::__default_alloc_template<true,
0>::deallocate(void*, unsigned int)'
KaxBlock.cpp:(.text+0x255): undefined reference to `std::__default_alloc_template<true,
0>::deallocate(void*, unsigned int)'
KaxBlock.cpp:(.text+0x269): undefined reference to `std::__default_alloc_template<true,

daily pkgsrc CVS update output

Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
? pkgsrc/crontab
? pkgsrc/net/wget/work
P pkgsrc/databases/Makefile
cvs update: pkgsrc/databases/xmysql/DESCR is no longer in the repository
cvs update: pkgsrc/databases/xmysql/Makefile is no longer in the repository
cvs update: pkgsrc/databases/xmysql/PLIST is no longer in the repository
cvs update: pkgsrc/databases/xmysql/distinfo is no longer in the repository
cvs update: pkgsrc/databases/xmysql/patches/patch-aa is no longer in the repository
P pkgsrc/doc/CHANGES-2006
P pkgsrc/net/rp-pppoe/Makefile
P pkgsrc/net/rp-pppoe/PLIST
P pkgsrc/net/rp-pppoe/distinfo
P pkgsrc/net/rp-pppoe/patches/patch-aa
P pkgsrc/net/rp-pppoe/patches/patch-ab
cvs update: pkgsrc/net/rp-pppoe/patches/patch-ac is no longer in the repository
cvs update: pkgsrc/net/rp-pppoe/patches/patch-ad is no longer in the repository
cvs update: pkgsrc/net/rp-pppoe/patches/patch-ae is no longer in the repository
P pkgsrc/net/rp-pppoe/patches/patch-af
U pkgsrc/net/rp-pppoe/patches/patch-ah
U pkgsrc/net/rp-pppoe/patches/patch-ai
P pkgsrc/sysutils/memtestplus/MESSAGE
P pkgsrc/sysutils/memtestplus/Makefile
P pkgsrc/sysutils/memtestplus/PLIST
P pkgsrc/sysutils/memtestplus/distinfo
U pkgsrc/sysutils/memtestplus/patches/patch-ac

Re: Damn it! pkgsrc stupidity again

On Wed, 1 Nov 2006, David Maxwell wrote:

> On Wed, Nov 01, 2006 at 07:47:19AM +0100, Ignatios Souvatzis wrote:
> > On Tue, Oct 31, 2006 at 04:30:20PM -0800, John Klos wrote:
> > >
> > > However, why does "make update" delete a package BEFORE reporting the
> > > relevant package as insecure?
> >
> > Because it is checking the new package when building it.
>
> It's certainly less convienient. It probably hasn't shown up as an issue
> since vulnerable packages are relatively rare at any point in time.
>
> A simple answer would be to check a second time, before the pkg_delete.
> Yes, that means it will be done twice, but I don't think the update case
> needs to be that micro-optimized.

I've been burned a few times with the delete-before-check thing.  The
extra time it takes to check for vulnerability is trivial, especially
considering the time it would take to fiddle around and put back the old
version.

--

-- 
David Griffith
dgriffi <at> cs.csubak.edu

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 in e-mail?

BUILDLINK_PASSTHRU_RPATHDIRS

I am having trouble building a package that contains shared libraries
that refer to other shared libraries.  The entire issue has to do with
the setting of the RPATH in the shared object.  Even though I patch
the package Makefile to use 'c++ -Wl,-rpath,XXX/lib' the appropriate
-rpath argument does not show up in the ld command line.  It seems
clear to me from the .work.log that the wrappers are removing the
argument.

However, even when I set

	 BUILDLINK_PASSTHRU_RPATHDIRS+=XXX/lib

in the package Makefile, the wrappers still seem to remove the -rpath
argument.

Clearly, I don't really understand how the wrappers are working.
What am I missing and how can I fix the package to allow modification
of the RPATH?

Thanks for your help.

Cheers,
Brook

Re: Damn it! pkgsrc stupidity again

David Griffith wrote:
> I've been burned a few times with the delete-before-check thing.  The
> extra time it takes to check for vulnerability is trivial, especially
> considering the time it would take to fiddle around and put back the old
> version.

Doesn't this check have to be recursive?

--

-- 
Christian