NetBSD Packages Collection No Longer Frozen

jschauma writes "As many users will probably have noticed by the increase in recent pkgsrc commits, the NetBSD Packages Collection freeze is now officially over. Starting October 6th, 2003 and lasting almost two months, the NetBSD Packages team concentrated upon stabilizing the over 4,000 software packages and the pkgsrc infrastructure to prepare for a stable pkgsrc branch. During that time, the number of broken packages during a i386 bulk build was brought down to a mere 15, and a large number of PRs was closed. A new branch with the tag ``pkgsrc-2003Q4'' was created, allowing our users to maintain a highly stabilized third-party software package managment environment, as only pullups of significant importance (such as security issues) are applied to this branch."

Yay!

[__aafkqj3628]

Although I don't use NetBSD (did for a short period of time, but now a FreeBSD user), this is still happy news for me.

Hmmmm, I wonder who's poor 486 got stuck with the 4000 package bulk build...

Re:Yay! you can compile for...

[__aafkqj3628]

You can compile for other cpus and even other CPU architectures on one machine for use on another.

I belive the word 'sarcasm' plays a role in my original post.

A nice cake is waiting for you

Oooo! What kind of cake?

Re:Yay! you can compile for...

[__aafkqj3628]

It's nice to see my antics don't go unnoticed ;)

Re:Yay! you can compile for...

[rthille]

I'm pretty sure that cross compiles is supported for the base-OS, but not for pkgsrc.

At least, that was the case the last time I checked (since compiling a bunch of stuff on my Qube2 instead of my Athlon was way way slower).

Re:Yay! you can compile for...

[Anonymous Coward]

Is it just me or does the linux kernel support more CPU ISAs than netbsd? Here is my count.

NetBSD (12):
alpha
arm
i386
m68k
ns32k
parisc
ppc
superh
sparc
sparc64
vax
x86-64

Linux (17):
alpha
arm
cris
h8300
i386
ia64
m68k
mips
parisc
ppc
ppc64
s390
superh
sparc
spa rc64
v850
x86-64

Re:Yay! you can compile for...

[Anonymous Coward]

Does Linux build to all those CPUs out of a single source-tree? Does it build a complete OS? FWIW, there was some similar discussion on netbsd-advocacy [netbsd.org] a while back...

Re:Yay! you can compile for...

[Strog]

Stop spreading FUD here. NetBSD [netbsd.org] shows 17 cpu types. Yes, Linux still supports more with ia64, ppc64, s390, etc. so at least your counting is somewhat off on both sides.

Your counts totally ignore edian issues. A playstation 2 and an SGI machine can't run the same binaries even though they are both MIPS because one is big endian and the other is little endian. ARMv2 is completely different architecturally than later versions. There are many other examples.

x86-64 is still a work in progress on both platforms and so is ppc64 (it's only a couple weeks old :)) but both are in heavy development and will quickly improve on all OSes. Obscure embedded platforms like v850, cris, h8300, etc. would make me nervous to use in a large production. They are not widely developed for and what info you can dig up suggests that they could be quirky with all the compiler weirdness, etc. that hasn't been shaken out yet. I'd much rather go with a more matured platform like ARM, MIPS, M68k, etc. regardless of the OS being chosen for the application.

There are times when a platform is more mature/complete/etc. (PA-RISC on linux is better supported) but NetBSD is generally very consistent and complete across all of the 40 platforms it currently supports.

The bottom line is use the right tool for the job. If I have a PA-RISC or s390 or wanted to build a PVR then I'd probably choose Linux and I would choose a BSD for most of the rest of my needs. You might choose a little different but both are good tools and very capable.

To get back ontopic. I use pkgsrc on several platforms ( BSD, Linux, OS X, Irix) and these fixes helped out on all platforms. I love the work that everyone has put into pkgsrc and can't wait to see it grow and develop more. Someone else needs to test it on Solaris Sparc/x86 since I don't have a box currently running it. :)

Re:Yay! you can compile for...

[Anonymous Coward]

"Obscure embedded platforms like v850, cris, h8300, etc.
would make me nervous to use in a large production."

Huh? There are more products shipped with any one
of these running Linux then the entire installed base of
NetBSD (no, literally). Choose an ARM (nommu) target
and there are millions of units a month shipped.

Widely developed has nothing to do with production ready.
But you are correct, this has nothing to do with pkgsrc.

D. Jeff Dionne

Re:Yay! you can compile for...

[Anonymous Coward]

NetBSD can already cross-compile the system from any arch to any arch. The cross-toolchain can be used in a chrooted environment to cross-build packages, but it is still touchy. see pkgsrc/pkgtools/pkg_comp .

Re: pkgsrc bulk build information

[alistair.crooks]

My Athlon XP 1800+, with 1.1 GB RAM and a fair bit of disk, was used. A "from-scratch" bulk-build takes between 5 and 6 days. The time for update bulk builds depends upon what was updated (duh). The machine was running NetBSD 1.6ZF (aka NetBSD-current), and the builds were done in a 1.6.2RC2 sandbox. The 15 broken packages which Jan mentioned can mostly be attributed to this setup: we found that pkgsrc/pkgtools/libkver works really well (it's a wrapper around sysctl(2)), but that Linux emulation has problems with libkver (because NetBSD and Linux use different ways of delivering errno for threaded programs). Using a wrapper for uname(1) allowed the packages which used Linux emulation during the build process to complete successfully, but imake uses sysctl(2) directly to get OS version information, and in the end we had to use a hybrid of the two to make packages. The bulk build results do not reflect this, which is probably the reason for the 15 packages.

Re: pkgsrc bulk build information

[zzyp]

I am just curious to know if it is possible for you guys to reduce the "from-scratch" build time to 1-2 days?

Thanks

The best thing...

[Fulkkari]

The best thing about this is propably that new stabilized branch. In the past I've used almost everytime the newest sources available to keep up with all the patches, but if this new branch has only the important patches applied to it, it's definetely going to be the one I'm using. If this is going to be updated in the future too, the name of the new branch (pkgsrc-2003Q4) wasn't the best one though.

Stable pkgsrc

[pkplex]

If you want to stay on the old pkgsrc tree and receive importaint fixes only ( eg, security bug fixes ), then use the 'pkgsrc-2003Q4' cvs tag :)

Any idea when NetBSD 2.0 is due?

[Burb]

As a casual user of NetBSD, I'm interested in version 2.0 as it will have lots of new stuff that I really want (threading etc.) Can anyone enlighten me as to the expected release schedule for 2.0?

Re:FreeBSD flaws

[rsax]

FreeBSD suffers from a couple of serious process flaws -- it is an operating system which is truly at home neither in the open-source nor the proprietary markets primarily because, although the source is open, the development team is not. Furthermore the license allows proprietary software to "steal" source code and use it. The combination of these problems leads to a somewhat inferior OS.

OK let me try to figure this out. If you have a patch for the Linux kernel which enhances functionality or fixes bugs