headers
NetBSD source update | 1 Jan 2012 02:04
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/databases/postgresql-postgis/Makefile
P pkgsrc/databases/postgresql-postgis/PLIST
P pkgsrc/databases/postgresql-postgis/distinfo
cvs update: pkgsrc/databases/postgresql-postgis/patches/patch-aa is no longer in the repository
cvs update: pkgsrc/databases/postgresql-postgis/patches/patch-ab is no longer in the repository
cvs update: pkgsrc/databases/postgresql-postgis/patches/patch-ac is no longer in the repository
cvs update: pkgsrc/databases/postgresql-postgis/patches/patch-ad is no longer in the repository
cvs update: pkgsrc/databases/postgresql-postgis/patches/patch-ae is no longer in the repository
U pkgsrc/databases/postgresql-postgis/patches/patch-configure
U pkgsrc/databases/postgresql-postgis/patches/patch-configure.ac
P pkgsrc/devel/libffi/distinfo
U pkgsrc/devel/libffi/patches/patch-src_arm_sysv.S
P pkgsrc/doc/CHANGES-2011
P pkgsrc/editors/emacs21/Makefile.common
P pkgsrc/editors/emacs21/distinfo
P pkgsrc/editors/emacs21/patches/patch-ab
U pkgsrc/editors/emacs21/patches/patch-src_alloc_c
P pkgsrc/mail/cyrus-imapd24/Makefile
P pkgsrc/mail/cyrus-imapd24/PLIST
P pkgsrc/mail/cyrus-imapd24/distinfo
cvs update: pkgsrc/mail/cyrus-imapd24/patches/patch-ad is no longer in the repository
cvs update: pkgsrc/mail/cyrus-imapd24/patches/patch-ae is no longer in the repository
cvs update: pkgsrc/mail/cyrus-imapd24/patches/patch-af is no longer in the repository
cvs update: pkgsrc/mail/cyrus-imapd24/patches/patch-ag is no longer in the repository
cvs update: pkgsrc/mail/cyrus-imapd24/patches/patch-aj is no longer in the repository
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Drake | 1 Jan 2012 03:54
Picon

Re: NetBSD's sed is not gsed (Was: Re: pkg/45752: security/gnome-keyring does (still) not build)

On Sat, 31 Dec 2011, David Holland wrote:

> So there are really three cases:
> 
> (1) the package needs any sed, and e.g. old SVR4 sed is good eonugh.
> (2) the package needs a working sed, which includes the non-gnu native
>     sed on a number of platforms (not just NetBSD).
> (3) the package specifically needs GNU sed.
>
> [....]
> 
> I would suggest that we dump case (1). On the legacy platforms
> affected most users will want a working sed installed anyway, or so
> I'd think, so it's reasonable to install one for building packages.

I agree with this idea, it makes sense.

> 
> This would mean:
> 
>    - packages that need a working sed should set USE_TOOLS+=sed
>    - packages that specifically need GNU sed should set USE_TOOLS+=gsed
> 
> This means that 17 packages that currently have "USE_TOOLS+=sed" would
> grow a build dependency on gsed on Solaris (and I guess on Irix too if
> anyone still cares) and 8 packages would grow a full dependency.

gsed? what about textproc/nbsed, it's already a built-in to the bootstrap
script and mk/tools/replace.mk, only needs removing 5 lines from various
mk/tools/tools.${OPSYS}.mk and are already be a part of the bootstrap-kit
(Continue reading)

Permalink | Reply | 1 comment |
headers
OBATA Akio | 1 Jan 2012 09:16
Picon

Re: NetBSD's sed is not gsed (Was: Re: pkg/45752: security/gnome-keyring does (still) not build)

On Sun, 01 Jan 2012 08:59:03 +0900, David Holland <dholland-pkgtech <at> netbsd.org> wrote:

> On Sun, Jan 01, 2012 at 01:57:32AM +0900, OBATA Akio wrote:
>  > It means that "NetBSD's sed is compatible with gsed" is not
>  > majority in pkgsrc.
>  >
>  > Then, if a package does not require gsed on NetBSD, following style
>  > should be used instead.
>  >
>  > .if ${OPSYS} != "NetBSD"
>  > USE_TOOLS+= gsed
>  > .endif
>
> I don't think this is the right solution, because it's not just
> NetBSD. I think we can be reasonably certain that the native sed is
> good enough on any of the BSD platforms, and possibly even on MacOS.
> So there are really three cases:
>
> (1) the package needs any sed, and e.g. old SVR4 sed is good eonugh.
> (2) the package needs a working sed, which includes the non-gnu native
>     sed on a number of platforms (not just NetBSD).
> (3) the package specifically needs GNU sed.
>
> Unfortunately, we only have two names to put in USE_TOOLS: "sed" and
> "gsed". Therefore, we either need a new name that we'll be able to
> remember ("oksed"? "nsed"?) or abandon one of the cases.
>
> I would suggest that we dump case (1). On the legacy platforms
> affected most users will want a working sed installed anyway, or so
> I'd think, so it's reasonable to install one for building packages.
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Holland | 1 Jan 2012 21:52
Picon

Re: NetBSD's sed is not gsed (Was: Re: pkg/45752: security/gnome-keyring does (still) not build)

On Sun, Jan 01, 2012 at 03:54:44PM +1300, Steven Drake wrote:
 > > This means that 17 packages that currently have "USE_TOOLS+=sed" would
 > > grow a build dependency on gsed on Solaris (and I guess on Irix too if
 > > anyone still cares) and 8 packages would grow a full dependency.
 > 
 > gsed? what about textproc/nbsed, it's already a built-in to the bootstrap
 > script and mk/tools/replace.mk, only needs removing 5 lines from various
 > mk/tools/tools.${OPSYS}.mk and are already be a part of the bootstrap-kit
 > on those platforms that need it.

Oops, I didn't realize that was there :-/

I don't see any further problem then... except that we should really
wait until after the freeze to deploy it.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 0 comments |
headers
David Holland | 1 Jan 2012 21:53
Picon

Re: NetBSD's sed is not gsed (Was: Re: pkg/45752: security/gnome-keyring does (still) not build)

On Sun, Jan 01, 2012 at 05:16:49PM +0900, OBATA Akio wrote:
 > And about my suggested style, I did not intend to present right solution.
 > IT IS THE STYLE.
 > Currently, it is specially treated with TOOLS_PLATFORM.gsed on NetBSD.
 > I just said, it should not be done with such style.

Sure. But it's getting done that way because things are wrong
underneath, so we may as well fix that.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 0 comments |
headers
John Klos | 1 Jan 2012 22:32

Different behavior for make update?

Hi,

I used to like "make update" because it used to clean up after itself 
(unlike "make install ; make clean" which only cleans up the current 
package, not dependencies also installed). However, that changed sometime:

cd /usr/pkgsrc/www/apache22 ; make update
...
ls -ld /usr/pkgsrc/*/*/work
drwxr-xr-x  16 root  wheel  1024 Jan  1 19:48 devel/apr-util/work
drwxr-xr-x  16 root  wheel  1024 Jan  1 19:46 devel/apr/work
drwxr-xr-x  16 root  wheel  1024 Jan  1 19:40 devel/pkg-config/work
drwxr-xr-x  15 root  wheel  1024 Jan  1 19:41 pkgtools/osabi/work
drwxr-xr-x  16 root  wheel  1024 Jan  1 19:41 pkgtools/x11-links/work

What happened? What target won't leave a mess lying around to screw up 
later installs and updates?

John
Permalink | Reply | 2 comments |
headers
David Holland | 1 Jan 2012 23:05
Picon

Re: Different behavior for make update?

On Sun, Jan 01, 2012 at 09:32:20PM +0000, John Klos wrote:
 > I used to like "make update" because it used to clean up after
 > itself (unlike "make install ; make clean" which only cleans up the
 > current package, not dependencies also installed). However, that
 > changed sometime:
 > 
 > cd /usr/pkgsrc/www/apache22 ; make update
 > ...
 > ls -ld /usr/pkgsrc/*/*/work
 > drwxr-xr-x  16 root  wheel  1024 Jan  1 19:48 devel/apr-util/work
 > drwxr-xr-x  16 root  wheel  1024 Jan  1 19:46 devel/apr/work
 > drwxr-xr-x  16 root  wheel  1024 Jan  1 19:40 devel/pkg-config/work
 > drwxr-xr-x  15 root  wheel  1024 Jan  1 19:41 pkgtools/osabi/work
 > drwxr-xr-x  16 root  wheel  1024 Jan  1 19:41 pkgtools/x11-links/work
 > 
 > 
 > What happened? What target won't leave a mess lying around to screw
 > up later installs and updates?

Nothing happened and it hasn't changed; it's just somewhat stupid and
nobody's taken the trouble to fix it.

The problem you've run into is that it only cleans the packages that
it removes for recompilation, the ones that end up in work/.DDIR.
Others get left around. It may be possible to fix this by setting
UPDATE_TARGET in mk.conf, although I would think it should be the
default behavior.

The other problem is that for some reason I completely don't
understand, after it finishes building it regenerates work/.DDIR and
(Continue reading)

Permalink | Reply | 0 comments |
headers
NetBSD source update | 2 Jan 2012 02:14
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/databases/gdbm_compat/builtin.mk
P pkgsrc/databases/postgresql91-client/Makefile
U pkgsrc/doc/CHANGES-2012
P pkgsrc/net/xnap/Makefile
P pkgsrc/net/xnap/distinfo
P pkgsrc/net/xnap/patches/patch-aa
P pkgsrc/pkgtools/x11-links/buildlink3.mk
P pkgsrc/sysutils/cdrtools/Makefile
P pkgsrc/sysutils/cdrtools/distinfo
U pkgsrc/sysutils/cdrtools/patches/patch-RULES_rules.man
P pkgsrc/textproc/libplist/Makefile
P pkgsrc/textproc/libplist/distinfo
U pkgsrc/textproc/libplist/patches/patch-swig_plist.i

Killing core files:

Updating pkgsrc-2011Q3 pkgsrc tree (/ftp/pub/pkgsrc/pkgsrc-2011Q3):
? pkgsrc/INDEX
Permalink | Reply | 0 comments |
headers
David Holland | 2 Jan 2012 20:28
Picon

Re: pkgsrc NetBSD 5.99.59/x86_64 2011-12-23 13:35

On Sun, Dec 25, 2011 at 11:07:02PM +0900, Ryo ONODERA wrote:
 > >> > emulators/xm7                                tech-pkg-ja <at> jp.NetBSD.org
 > >> 
 > >> I have just add xm71010s.lzh to ftp.NetBSD.org.
 > >> make package is O.K. now.
 > > 
 > > Sadly, this package has:
 > > RESTRICTED=             source archive is not redistributable
 > > NO_BIN_ON_CDROM=        ${RESTRICTED}
 > > NO_SRC_ON_CDROM=        ${RESTRICTED}
 > > NO_BIN_ON_FTP=          ${RESTRICTED}
 > > NO_SRC_ON_FTP=          ${RESTRICTED}
 > > 
 > > Please remove the file.
 > 
 > Thank you.
 > I have removed it.
 > 
 > Sorry.

Is the conclusion that the distfile is no longer (legally) available?

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 2 comments |
headers
Julio Merino | 2 Jan 2012 20:57
Picon

Re: Different behavior for make update?

On 1/1/12 10:32 PM, John Klos wrote:
> Hi,
> 
> I used to like "make update" because it used to clean up after itself
> (unlike "make install ; make clean" which only cleans up the current
> package, not dependencies also installed).

CLEANDEPENDS=yes in mk.conf is your friend.

--

-- 
Julio Merino /  <at> jmmv
Permalink | Reply | 0 comments |

Gmane