NetBSD source update | 1 Jul 09:12 2006
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/archivers/gzip/Makefile
P pkgsrc/audio/amarok/Makefile
P pkgsrc/audio/xmp/distinfo
U pkgsrc/audio/xmp/patches/patch-ak
U pkgsrc/audio/xmp/patches/patch-al
U pkgsrc/audio/xmp/patches/patch-am
U pkgsrc/audio/xmp/patches/patch-an
P pkgsrc/benchmarks/lmbench/Makefile
P pkgsrc/cad/tnt-mmtl/Makefile
P pkgsrc/chat/cgiirc/Makefile
P pkgsrc/chat/dircproxy-devel/distinfo
P pkgsrc/chat/dircproxy-devel/patches/patch-ac
U pkgsrc/chat/dircproxy-devel/patches/patch-ae
U pkgsrc/chat/dircproxy-devel/patches/patch-af
P pkgsrc/chat/konversation/distinfo
U pkgsrc/chat/konversation/patches/patch-ab
P pkgsrc/comms/gnome-pilot/Makefile
P pkgsrc/cross/avr-libc/Makefile
P pkgsrc/databases/db3/distinfo
P pkgsrc/databases/db3/patches/patch-ae
P pkgsrc/devel/acme/Makefile
P pkgsrc/devel/cqual/Makefile
P pkgsrc/devel/cqual/distinfo
P pkgsrc/devel/cqual/patches/patch-bk
U pkgsrc/devel/cqual/patches/patch-cd
(Continue reading)

joerg | 1 Jul 10:27 2006
Picon

Re: C++ problem: building "pkgsrc/audio/daapd" with GCC 4.x

On Fri, Jun 30, 2006 at 10:04:11PM +0000, Matthias Scheler wrote:
> void TypeRegistry::registerVar( const Var* var ) {
>         varMap[var->name] = var;
>         container << Tag( 'mdcl' ) <<
>                 Tag( 'mcnm' ) << var->mnemonic  << end <<
>                 Tag( 'mcna' ) << var->name      << end <<
>                 Tag( 'mcty' ) << (u16)var->type << end <<
>         end;
> }

I guess: TypeRegistry is a template class and end doesn't depend on the
template parameter. Try this->end instead.

Joerg

Roland Illig | 1 Jul 12:17 2006
Picon

Tracking the state of patch files

Hi,

a time-consuming task when updating packages is to keep track of all the 
patches that have been created in pkgsrc. I've tried to record the 
situation for devel/cqual in a file called patches/status, which contains:

----
$NetBSD$

applied patch-aa 1.1
applied patch-ab 1.2
applied patch-ac 1.2
applied patch-ba 1.1
new patch-bb
new patch-bc
applied patch-bd 1.1
new patch-be
applied patch-bf 1.1
applied patch-bg 1.1
new patch-bh
applied patch-bi 1.2
# ... in src/libqual/quals.c
applied patch-bj 1.1
new patch-bk
applied patch-bl 1.1
applied patch-bm 1.1
# ... in src/libqual/location.c
new patch-ca
new patch-cb
new patch-cc
(Continue reading)

Christoph Badura | 1 Jul 12:49 2006
Picon

Re: pkg/33872 (xorg master sites are slow as molasses in january)

On Fri, Jun 30, 2006 at 12:35:12AM +0000, joerg <at> netbsd.org wrote:
> Synopsis: xorg master sites are slow as molasses in january
> 
> State-Changed-From-To: open->closed
> State-Changed-By: joerg <at> netbsd.org
> State-Changed-When: Fri, 30 Jun 2006 00:35:11 +0000
> State-Changed-Why:
> The official master site *is* xorg.freedesktop.org.
> It is a common occurance that mirrors are faster than
> the primary site.

What's that got to do with it? Projects want mirror sites to take
the load off the master site.  You should know, be cause the project
you are most involved with actively says to use their master site
only as a last resort!

If you do not trust the mirrors to supply correct distfiles why list them
in the first place?

> Think about using MASTER_SORT instead.

Maybe you should have done that.  MASTER_SORT isn't intended to be used
to move unwanted master sites to the end of the list.

In summary, you closed the PR after giving bad advice and without
actually addressing the issue.

--chris

(Continue reading)

Christoph Badura | 1 Jul 12:59 2006
Picon

Re: pkg/33873 (xorg-server installs /usr/pkg/xorg/etc/init.d/xprint)

On Fri, Jun 30, 2006 at 12:57:34AM +0000, joerg <at> netbsd.org wrote:
> Synopsis: xorg-server installs /usr/pkg/xorg/etc/init.d/xprint
> 
> State-Changed-From-To: open->closed
> State-Changed-By: joerg <at> netbsd.org
> State-Changed-When: Fri, 30 Jun 2006 00:57:33 +0000
> State-Changed-Why:
> Behaviour is correct, since the provided script is
> not using rc.subr. Feel free to provide a real rc script
> or a patch to disable it, but since the entry is correctly
> specified in the PLIST, it doesn't hurt.

No, the behaviour is not correct.  rc.d scripts should be installed
in the system directories.

The script is selfcontained and doesn't need to use rc.subr.

If you object to installing the script in the correct location because
it needs changes, that is not a reason to close the PR.

Matthias Scheler | 1 Jul 13:06 2006
Picon

Re: C++ problem: building "pkgsrc/audio/daapd" with GCC 4.x

In article <20060701082740.GB360 <at> britannica.bec.de>,
	joerg <at> britannica.bec.de writes:
>> void TypeRegistry::registerVar( const Var* var ) {
>>         varMap[var->name] = var;
>>         container << Tag( 'mdcl' ) <<
>>                 Tag( 'mcnm' ) << var->mnemonic  << end <<
>>                 Tag( 'mcna' ) << var->name      << end <<
>>                 Tag( 'mcty' ) << (u16)var->type << end <<
>>         end;
>> }
> 
> I guess: TypeRegistry is a template class ...

It is indeed.

> ... and end doesn't depend on the template parameter.

Shouldn't TypeRegistry::End work in that case? Unfortunately it doesn't.

> Try this->end instead.

That doesn't work because it's a static member:

registry.cpp: In static member function 'static void TypeRegistry::registerVar(const TypeRegistry::Var*)':
registry.cpp:134: error: 'this' is unavailable for static member functions
registry.cpp:135: error: 'this' is unavailable for static member functions
registry.cpp:136: error: 'this' is unavailable for static member functions
registry.cpp:137: error: 'this' is unavailable for static member functions

There is only one thing which is worse than fixing old C code to compile
(Continue reading)

Christoph Badura | 1 Jul 13:12 2006
Picon

Re: pkg/33874 (can't download meta-pkgs/{xorg,XFree86} distfiles without setting X11_TYPE)

On Fri, Jun 30, 2006 at 01:04:36AM +0000, joerg <at> netbsd.org wrote:
> Synopsis: can't download meta-pkgs/{xorg,XFree86} distfiles without setting X11_TYPE
> 
> State-Changed-From-To: open->closed
> State-Changed-By: joerg <at> netbsd.org
> State-Changed-When: Fri, 30 Jun 2006 01:04:34 +0000
> State-Changed-Why:
> Since xorg and xfree86 set PKG_SKIP_REASON, this is
> not a problem of xorg or xfree86. The behaviour is correct
> to avoid waste of disk space.

Eh?

limiting-factor!bad 146 % cd pkgsrc/meta-pkgs/XFree86
limiting-factor!bad 147 % make fetch
WARNING: X11_TYPE=XFree86 is mandatory.

Obviously, it is a problem of xfree86. Same happens for xorg.

And since I just told it to "waste disk space" on what grounds do you
tell me that I am not allowed to waste the disk space I paid for?

> Patching is in-general
> wouldn't work either since dependencies have to be installed
> before the patch phase.

Nonsense. The only possible dependncy that would be required is a
support patch(1), which has nothing to do with the X11_TYPE to be
installed.

(Continue reading)

Thomas Klausner | 1 Jul 14:03 2006
Picon

Re: pkg_info -Q on binary packages

On Fri, Jun 30, 2006 at 11:31:54AM +0200, Dieter Baron wrote:
>   The fix is simple.  Is it okay to commit this (together with a
> version bump) during the freeze?

Sure, please go ahead.
 Thomas

Christoph Badura | 1 Jul 14:15 2006
Picon

Re: pkg/33869: can't install meta-pkgs/{xorg,XFree86} into /usr/X11R6

On Thu, Jun 29, 2006 at 11:45:01PM +0000, joerg <at> britannica.bec.de wrote:
>  No, this is not supported at all and not supposed to work either.
>  pkgsrc stuff is not supposed to leave ${LOCALBASE} and X11BASE is
>  entirely for the sake of X11TYPE=native.

Uhm. The documentation on USE_X11BASE and USE_IMAKE contradict you.

Anyway, the current default of the xorg and XFree86 pkg leave you with
an X11 installation that doesn't work by default because the
binaries are silently installed into unusal directories and need
a every user to customize PATH.

This came about because my T30 died and I need to upgrade to upgrade
NetBSD on the disk from 2.x to 3.0 because 2.x didn't support the
hardware in the T43 that replaced it. Unfortunately NetBSD's xsrc
doesn't support the graphics chip in the T43. Therefore I needed
at least an newer X server.

I've looked into installing just the x-sets from NetBSD without xserver
and using xorg-server.  But that requires X11_TYPE to be set in /etc/mk.conf
at all the times that a dependency of xorg-server that installs files
below /usr/pkg/xorg is updated or re-build.  Because there is no way to
handle that automatically, it really requires X11_TYPE to be set permanently.
Otherwise you get an inconsistent system.

At this point, I can't have xorg and XFree86 installed at the same time
from pkgsrc because that would require different settings of X11_TYPE
at just the right time.  So why not acknowledge that and install into
a standard directory.

(Continue reading)

joerg | 1 Jul 14:56 2006
Picon

Re: pkg/33872 (xorg master sites are slow as molasses in january)

On Sat, Jul 01, 2006 at 12:49:37PM +0200, Christoph Badura wrote:
> On Fri, Jun 30, 2006 at 12:35:12AM +0000, joerg <at> netbsd.org wrote:
> > Synopsis: xorg master sites are slow as molasses in january
> > 
> > State-Changed-From-To: open->closed
> > State-Changed-By: joerg <at> netbsd.org
> > State-Changed-When: Fri, 30 Jun 2006 00:35:11 +0000
> > State-Changed-Why:
> > The official master site *is* xorg.freedesktop.org.
> > It is a common occurance that mirrors are faster than
> > the primary site.
> 
> What's that got to do with it? Projects want mirror sites to take
> the load off the master site.  You should know, be cause the project
> you are most involved with actively says to use their master site
> only as a last resort!

The primary site is also most likely to have the official files. When
changed for whatever reason, using the official site most likely shows
the problem first.

This has *nothing* to do with the speed.

> If you do not trust the mirrors to supply correct distfiles why list them
> in the first place?

Because it happened often enough that mirror are partly outdated and
vendor shipped new versions with identical file names.

> > Think about using MASTER_SORT instead.
(Continue reading)


Gmane