NetBSD source update | 1 Apr 2011 03:05
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/comms/estic/Makefile
P pkgsrc/cross/mingw-gcc/Makefile
P pkgsrc/devel/atf/Makefile
P pkgsrc/devel/atf/PLIST
U pkgsrc/devel/atf/distinfo
P pkgsrc/devel/boost-jam/bjam.mk
P pkgsrc/doc/CHANGES-2011
P pkgsrc/geography/gdal-lib/distinfo
U pkgsrc/geography/gdal-lib/patches/patch-CVE-2011-1167
P pkgsrc/geography/qlandkartegt/distinfo
U pkgsrc/geography/qlandkartegt/patches/patch-ab
U pkgsrc/geography/qlandkartegt/patches/patch-ac
P pkgsrc/graphics/cairo/buildlink3.mk
P pkgsrc/graphics/dxsamples/Makefile
P pkgsrc/graphics/dxsamples/distinfo
U pkgsrc/graphics/dxsamples/patches/patch-programs_2D__DATA_Makefile.in
U pkgsrc/graphics/dxsamples/patches/patch-programs_3D__DATA_Makefile.in
U pkgsrc/graphics/dxsamples/patches/patch-programs_ANNOTATION_Makefile.in
U pkgsrc/graphics/dxsamples/patches/patch-programs_CATEGORICAL_Makefile.in
U pkgsrc/graphics/dxsamples/patches/patch-programs_COLORMAP__EDITOR_Makefile.in
U pkgsrc/graphics/dxsamples/patches/patch-programs_COMPUTE_Makefile.in
U pkgsrc/graphics/dxsamples/patches/patch-programs_DATA__DRIVEN__INTERACTORS_Makefile.in
U pkgsrc/graphics/dxsamples/patches/patch-programs_DEBUGGING_Makefile.in
U pkgsrc/graphics/dxsamples/patches/patch-programs_DISTRIBUTED__PROCESSING_Makefile.in
U pkgsrc/graphics/dxsamples/patches/patch-programs_IMAGE__PROCESSING_Makefile.in
(Continue reading)

Hauke Fath | 1 Apr 2011 14:11
Picon

A late png update fallout - xemacs 21.5.27

Building editors/xemacs-current on darwin 10.7.3 fails with

[...]
In file included from faces.h:27,
                 from glyphs-eimage.c:47:
charset.h: In function 'charset_by_attributes':
charset.h:342: warning: declaration of 'final' shadows a global declaration
specifier.h:581: warning: shadowed declaration is here
glyphs-eimage.c: In function 'png_instantiate':
glyphs-eimage.c:951: error: dereferencing pointer to incomplete type
glyphs-eimage.c:952: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1004: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1007: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1008: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1011: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1014: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1017: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1019: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1043: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1050: error: dereferencing pointer to incomplete type
glyphs-eimage.c:1051: error: dereferencing pointer to incomplete type
*** Error code 1

	hauke

--

-- 
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut fŸr Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-3281
(Continue reading)

Thomas Klausner | 1 Apr 2011 15:01
Picon

Re: A late png update fallout - xemacs 21.5.27

On Fri, Apr 01, 2011 at 02:11:44PM +0200, Hauke Fath wrote:
> Building editors/xemacs-current on darwin 10.7.3 fails with
> 
> [...]
> glyphs-eimage.c: In function 'png_instantiate':
> glyphs-eimage.c:951: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:952: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1004: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1007: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1008: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1011: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1014: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1017: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1019: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1043: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1050: error: dereferencing pointer to incomplete type
> glyphs-eimage.c:1051: error: dereferencing pointer to incomplete type
> *** Error code 1

I fixed these. I couldn't package it though, since it dumped core
later. Please let me know if you have further png trouble with it.
 Thomas

Hauke Fath | 1 Apr 2011 15:50
Picon

Re: A late png update fallout - xemacs 21.5.27

At 15:01 Uhr +0200 01.04.2011, Thomas Klausner wrote:
>I fixed these. I couldn't package it though, since it dumped core
>later. Please let me know if you have further png trouble with it.

It comples and packages fine now. Non-X mode works fine, in X mode "xemacs
-vanilla" comes up with a lisp error ("Symbol's function definition is
void: constrain-to-field"), but that's obviously not png related.

Thanks!

	hauke

--

-- 
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-3281

Greg Troxel | 1 Apr 2011 16:11
Picon

Re: [HEADSUP] Removing vulnerable packages


1) I object to an automatic removal process just because of a
vulnerability entry.  A number of vulnerabilities affect only some
usages.

Broad removal is way too heavy handed, and I fail to see how that is
connected with the goal of making pkgsrc useful for pkgsrc users.
pkgsrc lets people build and manage code, and there's a separate issue
of deciding whether to use it.

pkgsrc doesn't have a duty of care about vulnerabilities, and I think
it's important not to take that on.

2) Some of those packages are in the category of "no one in their right
mind should be using them".  Proposing to delete those seems fine, but
the justification is "no one cares or should care" and the vulnerability
issue should be secondary.

3) Specific comments

  lmbench: I use this occasionally.  The problem is limited to untrusted
  local users gaining the permissions of the user running lmbench.  For
  many environments this is not a big deal.  (IMHO, running a system
  with untrustworthy local users is unsound, regardless of known
  issues.)

  snort: This should stay, even if not fixed yet; it's lame for us not
  to have it.  Needs update to 2.9.0.4.  It looks pretty easy and I'll
  give it a try.

(Continue reading)

Thomas Klausner | 1 Apr 2011 16:56
Picon

Re: [HEADSUP] Removing vulnerable packages

I think you misunderstood my intention.
I selected packages which have security issues for over 15 months
(probably much longer in some cases) _and_ which weren't update in the
same timeframe. This is in my eyes a good indicator of packages in
which noone is seriously interested and for which an upstream might
not even exist any longer.

There is no point in keeping such packages in pkgsrc, since we're not
maintaining them.

If someone is still using them, they have ample time to speak up, and
I'm not going to remove those packages, even if they stay unfixed.

On the other hand, I already fixed some of them...

>   lmbench: I use this occasionally.  The problem is limited to untrusted
>   local users gaining the permissions of the user running lmbench.  For
>   many environments this is not a big deal.  (IMHO, running a system
>   with untrustworthy local users is unsound, regardless of known
>   issues.)
> 
>   snort: This should stay, even if not fixed yet; it's lame for us not
>   to have it.  Needs update to 2.9.0.4.  It looks pretty easy and I'll
>   give it a try.
> 
>   gdb: this is to provide gdb for platforms other than NetBSD, which
>   don't already have it native?  It seems like there's little call for
>   this and thus ok to remove, but perhaps 

I'll leave these alone.
(Continue reading)

Greg Troxel | 1 Apr 2011 17:24
Picon

Re: [HEADSUP] Removing vulnerable packages


Thomas Klausner <wiz <at> NetBSD.org> writes:

> I think you misunderstood my intention.
> I selected packages which have security issues for over 15 months
> (probably much longer in some cases) _and_ which weren't update in the
> same timeframe. This is in my eyes a good indicator of packages in
> which noone is seriously interested and for which an upstream might
> not even exist any longer.
>
> There is no point in keeping such packages in pkgsrc, since we're not
> maintaining them.

OK, that makes sense, but the notion of "these packages are obviously
ancient and no one should be using them" did not come through to me in
your message.  It's the "vulnerable and not updated recently => presumed
should be removed" logic that I object to.  

>>   lmbench: I use this occasionally.  The problem is limited to untrusted
>>   local users gaining the permissions of the user running lmbench.  For
>>   many environments this is not a big deal.  (IMHO, running a system
>>   with untrustworthy local users is unsound, regardless of known
>>   issues.)
>> 
>>   snort: This should stay, even if not fixed yet; it's lame for us not
>>   to have it.  Needs update to 2.9.0.4.  It looks pretty easy and I'll
>>   give it a try.
>> 
>>   gdb: this is to provide gdb for platforms other than NetBSD, which
>>   don't already have it native?  It seems like there's little call for
(Continue reading)

Thomas Klausner | 1 Apr 2011 17:33
Picon

Re: [HEADSUP] Removing vulnerable packages

On Fri, Apr 01, 2011 at 11:24:10AM -0400, Greg Troxel wrote:
> Thomas Klausner <wiz <at> NetBSD.org> writes:
> 
> > I think you misunderstood my intention.
> > I selected packages which have security issues for over 15 months
> > (probably much longer in some cases) _and_ which weren't update in the
> > same timeframe. This is in my eyes a good indicator of packages in
> > which noone is seriously interested and for which an upstream might
> > not even exist any longer.
> >
> > There is no point in keeping such packages in pkgsrc, since we're not
> > maintaining them.
> 
> OK, that makes sense, but the notion of "these packages are obviously
> ancient and no one should be using them" did not come through to me in
> your message.  It's the "vulnerable and not updated recently => presumed
> should be removed" logic that I object to.  

Sorry I didn't make myself clearer in the first email.

> I didn't mean to speak up for the gdb package.  I don't understand it's
> purpose, as the in-tree gdb seems better for NetBSD.

Ok. Perhaps as a more modern gdb for older NetBSD releases, but
without a maintainer, that won't work.
 Thomas

Edgar Fuß | 1 Apr 2011 22:44
Picon
Favicon

Re: undefined reference to `pqueue_size', net/freeradius not building rlm_eap_tls

Am 01.04.2011 um 19:52 schrieb Edgar Fuß:

> Supposedly after applyin[g] the fix fo[r] SA2010-011, net/freeradius refuses to build most modules due
to OpenSSL not found.
There seems to be an error in SA2010-011 in telling you to update crypto/dist/openssl/ssl only. If I update
all of crypto/dist/openssl, everything woks fine.
NetBSD source update | 2 Apr 2011 03:56
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/audio/padevchooser/Makefile
P pkgsrc/audio/pulseaudio/options.mk
P pkgsrc/converters/bibtex2html/Makefile
P pkgsrc/converters/bibtex2html/PLIST
U pkgsrc/converters/bibtex2html/distinfo
U pkgsrc/converters/bibtex2html/patches/patch-Makefile.in
P pkgsrc/databases/bdb-xml/Makefile
P pkgsrc/devel/Makefile
P pkgsrc/devel/monotone/Makefile
P pkgsrc/devel/monotone/PLIST
U pkgsrc/devel/monotone/distinfo
cvs update: pkgsrc/devel/monotone-el/DESCR is no longer in the repository
cvs update: pkgsrc/devel/monotone-el/Makefile is no longer in the repository
cvs update: pkgsrc/devel/monotone-el/PLIST is no longer in the repository
cvs update: pkgsrc/devel/monotone-el/distinfo is no longer in the repository
P pkgsrc/devel/monotone-server/Makefile
P pkgsrc/devel/ncurses/Makefile
P pkgsrc/devel/popt/distinfo
U pkgsrc/devel/popt/patches/patch-lookup3.c
U pkgsrc/devel/popt/patches/patch-poptint.h
P pkgsrc/devel/ruby-stream/distinfo
P pkgsrc/devel/ruby-stream/patches/patch-ab
P pkgsrc/doc/CHANGES-2011
P pkgsrc/doc/TODO
P pkgsrc/editors/joe/Makefile
(Continue reading)


Gmane