3.0 release catchall ticket
Catchall ticket for 3.0 release.
#5 Updated by marino almost 3 years ago
I feel so strong about 2108 (*context on x86_64) that I believe it should block the release of 3.0 until the fix is included. There are over 400 failures in the x86_64 bulkbuild report caused by Ruby193 alone, which is caused by bug 2108. All Boehm Garbage Collector failures are caused by this as well.
#6 Updated by mneumann over 2 years ago
Am 24.01.2012 17:53, schrieb John Marino via Redmine:
> Issue #2286 has been updated by John Marino.
> I feel so strong about 2108 (*context on x86_64) that I believe it should block the release of 3.0 until the fix is included. There are over 400 failures in the x86_64 bulkbuild report caused by Ruby193 alone, which is caused by bug 2108. All Boehm Garbage Collector failures are caused by this as well.
Ruby19 can be compiled without the need of *context kernel support, but
it slows down execution I guess. If we cannot implement *context we
should at least fix the pkgsrc Ruby package.
#7 Updated by masterblaster over 2 years ago
When it comes to boehm, just prevent it from using *context until a stable implementation is available. Following patch works for me:
@@ -18,3 +18,12 @@ $NetBSD$
#endif /* !USE_ASM_PUSH_REGS */
#if defined(HAVE_PUSH_REGS) && defined(THREADS)
+@@ -175,7 +177,7 @@
+ # if defined(HAVE_PUSH_REGS)
+ # elif defined(UNIX_LIKE) && !defined(DARWIN) && !defined(ARM32) && \
++ !defined(HURD) && !defined(X86_64)
+ /* Older versions of Darwin seem to lack getcontext(). */
+ /* ARM Linux often doesn't support a real getcontext(). */
+ ucontext_t ctxt;
#10 Updated by vsrinivas over 2 years ago
There are a few bugfixes in -master that should be merged into the release:
702c883ec92ded8a3fd9f214077f8b979c21f626 (rlimit check in tmpfs_write path)
23ecc5880dd169ab9c408114e82a49d099f45a8d (udp auto bind proc null fix)
There is a tmpfs data corruption bug that may have been fixed by three recent VM commits as well.
In addition, there are some outstanding complaints wrt the NFS client; some manifested as failure-to-push onto git trees on the official DF machines (EIO returned from perhaps badly-constructed RPCs?) and some perhaps tied to bug 2297.
#12 Updated by vsrinivas over 2 years ago
Merged back 702c883ec92ded8a3fd9f214077f8b979c21f626 (rlimit check in tmpfs_write path), 23ecc5880dd169ab9c408114e82a49d099f45a8d (udp auto bind proc null fix), d52fdd344b45d86e656629e2f16e6e1f267b08a7 (linprocfs vnode locking).
tmpfs changes still need to be MFC-ed.
Should tmpfs NFS export support be MFC-ed? (see bug 2277).
#15 Updated by thomas.nikolajsen over 2 years ago
I think we should MFC:
- tmpfs NFS export support (bug 2277)
- trouble building/loading crypto.ko
Will do in a few days if I see no objections.
#17 Updated by dragonflybsd1 over 2 years ago
Justin C. Sherrill wrote:
> Packages for 3.0 uploaded.
I checked avalon reports and see a 2 FEB 2012 data on both i386 and x86_64 architectures.
The packages were built with an older version of 3.0 because the binutils 2.22 related failures are still there, resulting in hundreds of unbuilt packages (e.g. esound alone caused nearly 400 packages to not build)
The quote above makes it sound like the package building for the release is complete, but really each platform needs to be built to the latest world and the bulkbuild needs to be run again to allow the broken package that can actually build be created.
Added: Also the install phase / user issue primarily seen on ruby packages is still occurring breaking several hundred more packages so we need to get several eyes on that problem. We haven't had good package build on any platform since Oct 2011.
#19 Updated by ahuete.devel over 2 years ago
I've recovered manually issue 2276, please close it.
2012/2/16 Venkatesh Srinivas via Redmine <
> Issue #2286 has been updated by Venkatesh Srinivas.
> The MFS unmount panic was resolved by commit
> 0a5fa2b36cd3a10f75060ac42f431307aef7cea4 and has been MFCed. I deleted the
> bug instead of marking it closed by mistake, sorry!
> Bug #2286: 3.0 release catchall ticket
> Author: Justin C. Sherrill
> Status: New
> Priority: Urgent
> Assignee: Justin C. Sherrill
> Target version:
> Catchall ticket for 3.0 release.
> You have received this notification because you have either subscribed to
> it, or are involved in it.
> To change your notification preferences, please click here:
#20 Updated by vsrinivas over 2 years ago
The panic-during-shutdown mount bug has been root-cased and a fix is in progress.
Basically, VFS accounting holds a reference to the pfs mountpoint structure inside a vnode for nullfs cases; however it accesses a freed mount's mnt_op vector in the shutdown path, as its reference does not protect against the mount structure being freed.