Re: Branching for netbsd-10 next week
On Sat, Dec 17, 2022 at 01:41:18AM -0500, Tom Lane wrote: > but I suppose that just reflects a branch existing in the CVS repo. Yes, and also that pullup ticket queues for -10 exist. > I don't see any sign of the branch being supported at, say, > > https://nycdn.netbsd.org/pub/NetBSD-daily/ > http://releng.netbsd.org/cgi-bin/builds.cgi It is building right now (see the second url): Currently building tag: netbsd-10 started at Sat Dec 17 04:29:51 UTC 2022 18 passed so far and when that build is done it will appear in the daily site and there will be armbsd.org images for it. Martin
Re: Branching for netbsd-10 next week
"Thomas Mueller" writes: > A couple days ago, didn't you say the branch was 10 hours away? It says here that the branch has been made: https://releng.netbsd.org but I suppose that just reflects a branch existing in the CVS repo. I don't see any sign of the branch being supported at, say, https://nycdn.netbsd.org/pub/NetBSD-daily/ http://releng.netbsd.org/cgi-bin/builds.cgi I'm a newbie here, but I'm curious when that infrastructure will come on-line ... regards, tom lane
Re: Branching for netbsd-10 next week
On Thu, Dec 15, 2022 at 07:59:35PM +, Thomas Mueller wrote: > > I will want to update my NetBSD installation from 9.99.82 from source > > and am inclined toward 10.99.1 rather than 10.0_BETA. I use "cvs up > > -dP -A" to update the source on base system and pkgsrc, currently am on > > native X. > As your current installation is in the "bad" time window, you will have to > follow Chuck's guide to safely update: > https://wiki.netbsd.org/features/UFS2ea/ > But most likely you will decide to no not need EAs and the easy upgrade > path is to stay with FFSv2 (i.e.: not run ufs2ea-flip, but only fsck). > This is the path we expect most users to take. > Martin I don't know what you mean by the "bad" time window but think now I do better to maintain compatibility, especially since the entropy bug, which gets in the way of building packages, might still pose problems as nia says. A couple days ago, didn't you say the branch was 10 hours away? Has Linux emulation improved since NetBSD 9.99.82? Tom
Re: Branching for netbsd-10 next week
from nia: > On Thu, Dec 15, 2022 at 07:59:35PM +, Thomas Mueller wrote: > > How will I be able to access (read-only OK) FFS2ea from NetBSD 9.99.82, and > > what about compatibility with FreeBSD regarding file system? I assume no > > compatibility with Linux. > There will be no compatibility with either, older NetBSD releases > won't recognize the superblock AFAIK. > > Will I have to worry about the entropy problem when building or updating > > packages from 9.99.82 to 10.99.1, or, less likely, 10.0_BETA? Has that > > been fixed? > There aren't any changes since 99.82 to the way entropy(7) accounting > works because the opinions in the community are too strong. My opinion is strong that this entropy bug should not be allowed to get in the way of building packages. Is any other OS afflicted by this bug? Tom
Re: Branching for netbsd-10 next week
On Thu, Dec 15, 2022 at 07:59:35PM +, Thomas Mueller wrote: > I will want to update my NetBSD installation from 9.99.82 from source > and am inclined toward 10.99.1 rather than 10.0_BETA. I use "cvs up > -dP -A" to update the source on base system and pkgsrc, currently am on > native X. As your current installation is in the "bad" time window, you will have to follow Chuck's guide to safely update: https://wiki.netbsd.org/features/UFS2ea/ But most likely you will decide to no not need EAs and the easy upgrade path is to stay with FFSv2 (i.e.: not run ufs2ea-flip, but only fsck). This is the path we expect most users to take. Martin
Re: Branching for netbsd-10 next week
On Thu, Dec 15, 2022 at 07:59:35PM +, Thomas Mueller wrote: > How will I be able to access (read-only OK) FFS2ea from NetBSD 9.99.82, and > what about compatibility with FreeBSD regarding file system? I assume no > compatibility with Linux. > There will be no compatibility with either, older NetBSD releases won't recognize the superblock AFAIK. > Will I have to worry about the entropy problem when building or updating > packages from 9.99.82 to 10.99.1, or, less likely, 10.0_BETA? Has that been > fixed? There aren't any changes since 99.82 to the way entropy(7) accounting works because the opinions in the community are too strong.
Re: Branching for netbsd-10 next week
> Just to wrap up this thread: > - branch will probably happen in the next ~10h > - default file system for new installations will be FFSv2 > I will update docs and extend the wiki page about FFS2ea to show how to > switch later, and also provide installation instructions how to select > FFSv2ea right during installation (trivial to do, but better we have > something to be found for later searches). > Thanks to all the input provided on this list and off list! > Martin I will want to update my NetBSD installation from 9.99.82 from source and am inclined toward 10.99.1 rather than 10.0_BETA. I use "cvs up -dP -A" to update the source on base system and pkgsrc, currently am on native X. How will I be able to access (read-only OK) FFS2ea from NetBSD 9.99.82, and what about compatibility with FreeBSD regarding file system? I assume no compatibility with Linux. Will I have to worry about the entropy problem when building or updating packages from 9.99.82 to 10.99.1, or, less likely, 10.0_BETA? Has that been fixed? Tom
Re: Branching for netbsd-10 next week
Am 15.12.22 um 11:35 schrieb Martin Husemann: Just to wrap up this thread: - branch will probably happen in the next ~10h - default file system for new installations will be FFSv2 I will update docs and extend the wiki page about FFS2ea to show how to switch later, and also provide installation instructions how to select FFSv2ea right during installation (trivial to do, but better we have something to be found for later searches). Thanks to all the input provided on this list and off list! Martin Thanks Martin for keeping us up with the progress and the decision for the default file system. I think considering all the opinions expressed, this is a good decision. Kind regards Matthias smime.p7s Description: S/MIME Cryptographic Signature
Re: Branching for netbsd-10 next week
Just to wrap up this thread: - branch will probably happen in the next ~10h - default file system for new installations will be FFSv2 I will update docs and extend the wiki page about FFS2ea to show how to switch later, and also provide installation instructions how to select FFSv2ea right during installation (trivial to do, but better we have something to be found for later searches). Thanks to all the input provided on this list and off list! Martin
Re: Branching for netbsd-10 next week
Hi Martin, Martin Husemann wrote: - unaware users may install FFSv2ea file systems and later find the need to access them from older NetBSD kernels. "Downgrading" them is quite easy using the ufs2ea-flip tool mentioned in the wiki page, but it is not "plug & play". - if FFSv2ea is not the default, most new installs will create non-EA enabled file systems and - the EAs will not get much testing - packets from pkgsrc (like samba) will continue to have the corresponding options disabled by default - users will have a hard time to find the conversion options later. It is hidden in fsck_ffs(8) and quite simple: after having made sure your bootloader is up to date, boot to single user and run something like: "fsck_ffs -c ea /" So, what should be the default FFS type for new installs in netbsd-10 ? given that switching to the new version is "relatively easy" after install too, in both directions, I would conservatively keep using FFSv2 as default, but suggesting EA for new installation without interoperability issues, for this release. If all goes well, for the next release, which would be 11, or even 10.1 (debatable) switch EA on. Given, however, that ufs2ea-flip exists, I don't find it that menacing to switch to EA by default. Riccardo
Re: Branching for netbsd-10 next week
On Sat, Dec 10, 2022 at 03:28:14PM +0100, Reinoud Zandijk wrote: > related, I think we should really iron out all installation issues that > plagued NetBSD before and were scorned on say Slashdot i.e. provide easy > install/live images with a gui installed, with optional extra variants with > say a complete xfce4 one with FF etc. and provide complete installs like the > live CD running as option in sysinst. You are free to work on that any time, but we are not going to delay the branch nor the release for any of that. Instead of (or as first step towards) a xfce4 install image I would prefer to have signed binary packages, but it seems impossible to do with the current pkgsrc infrastructure: https://wiki.netbsd.org/projects/project/Make_signed_binary_pkgs_for_NetBSD_happen/ Martin
Re: Branching for netbsd-10 next week
Hi, related, I think we should really iron out all installation issues that plagued NetBSD before and were scorned on say Slashdot i.e. provide easy install/live images with a gui installed, with optional extra variants with say a complete xfce4 one with FF etc. and provide complete installs like the live CD running as option in sysinst. Separate images could be made for VMs and for the cloud instances complete with documentation and sensible default setup. Also kind of important, good defaults for the shell logins so noone sees ^T etc when line editing. That might be fixed nowadays but some stuff migrated here over from earlier installs dating from 1.4 and at times i just enter tcsh or so just to get the line editing working. Just my $0.02 :) Reinoud
Re: Branching for netbsd-10 next week
Robert Elz writes: > | And it's not just NetBSD > > The relevant issue is, in that NetBSD10 might have EA support, but > perhaps without them being enabled by default on anything, for which > the solution, and its ramifications are a peculiarly NetBSD issue > (the same thing does not apply to FreeBSD for example, there you > just need a new enough system, and not to be using FFSv1). And you need not to be using FAT32, and probabbly a bunch of other filesystems, on various operating systems. NetBSD already has the property that EA might be present in a filesystem (FFSv1 maybe, ZFS) and it might not. That basic "maybe" is not going to change; there's just one more option with. > | --- it's a larger issue that you need to use a FS with > | certain properties if you want certain features. So it really belongs > | in the upstream documentation in general. > > That one needs ACLs yes, certainly - that to get those working on > NetBSD requires NetBSD >= 10, and one needs to then either newfs > with some specific option, or fsck with some specific option, not so much. In that case, sure. But there is a tendency in pkgsrc to put in fixes that apply to all use on NetBSD, not just in pkgsrc context (which is great) and then not push them upstream. signature.asc Description: PGP signature
Re: Branching for netbsd-10 next week
Date:Fri, 09 Dec 2022 06:48:23 -0500 From:Greg Troxel Message-ID: | Not MESSAGE; this is not a "your hair is on fire" thing. Probably not, but I'm not a samba user (or a user of anything which might use samba) so the importance eludes me. | And it's not just NetBSD The relevant issue is, in that NetBSD10 might have EA support, but perhaps without them being enabled by default on anything, for which the solution, and its ramifications are a peculiarly NetBSD issue (the same thing does not apply to FreeBSD for example, there you just need a new enough system, and not to be using FFSv1). | --- it's a larger issue that you need to use a FS with | certain properties if you want certain features. So it really belongs | in the upstream documentation in general. That one needs ACLs yes, certainly - that to get those working on NetBSD requires NetBSD >= 10, and one needs to then either newfs with some specific option, or fsck with some specific option, not so much. kre
Re: Branching for netbsd-10 next week
On Fri, Dec 09, 2022 at 10:03:46AM +0100, Matthias Petermann wrote: > compatibility. However, if I understand correctly, this only affects new > installations? If I migrate an existing NetBSD 9 to 10, nothing changes in > the file system format. I.e. as long as I do not actively initite the > migration, I can always access it with NetBSD 9. Correct. No special action is needed if you never run any current kernel on it and file systems will remain plain FFSv2 (and have EAs deactivated). > How likely is it that I > will have to access the filesystem with NetBSD 9 after a new installation of > NetBSD 10? Not very, IMHO. And in the cases you want, there is a path to convert it. As Robert pointed out, you don't need to fiddle with the not-in-tree ufs2ea-flip tool, you can just use "fsck_ffs -c" from your -current (or netbsd-10) install. Martin
Re: Branching for netbsd-10 next week
Robert Elz writes: > | - packets from pkgsrc (like samba) will continue to have the > | corresponding options disabled by default > > Those packages could have warnings in DESCR and MESSAGE (or whatever it > is called) advising of the need for FFSv2ea for full functionality. > How does samba (and anything else like it) deal with this - if it is > a compile time option, then since NetBSD supports EAs (and hence the > sys call interface exists) EA support in samba should be enabled. > More likely it is to be a run time problem, as whether a filesys has > EA support or not will vary, some might, others not, so whether samba > can provide EA functionality will tend to vary file by file (or at least > directory by directory) - given that, a solid warning that FFSv2ea support > is needed in the samba man page (or other doc) for NetBSD should allow > users to know what to do. Not MESSAGE; this is not a "your hair is on fire" thing. And it's not just NetBSD --- it's a larger issue that you need to use a FS with certain properties if you want certain features. So it really belongs in the upstream documentation in general. As a general point, these sorts of issues are not properly pkgsrc accomodations, but belong upstream, as anyone building samba from sources following the upstream build instructions should get the same hints. Indeed, a warning in the code (pushed to the upstream project) about using ACLs in a fs that doesn't have ACLs seems good. signature.asc Description: PGP signature
Re: Branching for netbsd-10 next week
Hello Martin, Am 08.12.22 um 20:21 schrieb Martin Husemann: Now the question: should the default install really use this new FFS type, or should it default to plain FFSv2? thanks for the good news about the branching progress, as well as the good preparation of the topic around the installer and the support for EA/ACL. Depending from which point of view one sees NetBSD, one or the other variant could appear as the better one. Here therefore only my completely personal opinion. For classification: I see NetBSD as a solid server operating system for small and medium appliances. I prefer it (not only) because of the stability and the low maintenance effort to all other Unix variants everywhere where I can make the decision myself and take responsibility. I hope that NetBSD will keep its relevance in this area or even gain it. Thats why I would like to see stable features that are standard on other comparable operating systems also enabled by default on NetBSD. This concerns not only the ACLs, but for example also WAPBL (log). This would make it easier for new users on modern systems to get started. Especially regarding the ACLs, which allow for the first time to run an Active Directory compatible domain controller with NetBSD, a nice straight path opens up which has the potential to lead to a wider distribution and thus better test coverage in those inhomogeneous environments where NetBSD has not been present so far due to this gap. The detour over the single user mode and the execution of a migration on the nevertheless just freshly installed system represents here an unnecessary complication. On the other hand, of course, I also see the concerns about backward compatibility. However, if I understand correctly, this only affects new installations? If I migrate an existing NetBSD 9 to 10, nothing changes in the file system format. I.e. as long as I do not actively initite the migration, I can always access it with NetBSD 9. How likely is it that I will have to access the filesystem with NetBSD 9 after a new installation of NetBSD 10? I can only think of experimental or recovery scenarios. In such cases, is it possibly more reasonable to refer the (experienced) user to single user mode and migration than the (new) user for a fresh install? Probably you can read it out - I would vote for FFSv2ea as default, but am also fine with the opposite if there are good reasons for it. It's ever just a few keystrokes in the installer ;-) Many greetings Matthias smime.p7s Description: S/MIME Cryptographic Signature
Re: Branching for netbsd-10 next week
Hello Robert, Am 09.12.22 um 08:55 schrieb Robert Elz: | - packets from pkgsrc (like samba) will continue to have the | corresponding options disabled by default Those packages could have warnings in DESCR and MESSAGE (or whatever it is called) advising of the need for FFSv2ea for full functionality. How does samba (and anything else like it) deal with this - if it is a compile time option, then since NetBSD supports EAs (and hence the sys call interface exists) EA support in samba should be enabled. More likely it is to be a run time problem, as whether a filesys has EA support or not will vary, some might, others not, so whether samba can provide EA functionality will tend to vary file by file (or at least directory by directory) - given that, a solid warning that FFSv2ea support is needed in the samba man page (or other doc) for NetBSD should allow users to know what to do. That's right - on NetBSD 10, the necessary library functions for managing ACLs are available and linked to Samba at compile time. This currently has to be enabled manually via the acl compile option - I've had this in my custom builds for a few months now. A Samba version compiled this way works in standalone mode even without an ACL-capable file system. Error messages about the missing ACL support of the operating system only occur when it is supposed to be used as Active Directory Domain Controller. The first place where this usually occurs is when you initialize the structures for the AD in the file system with "samba-tool domain provision" (mainly affects the directory sysvol). I therefore agree with you - a corresponding note in the MESSAGE would be sufficient. Especially since even on a system without EA/ACL on the root file system, for example, a separate partition for the sysvol can be mounted with ACLs. This is how I have currently implemented this on my domain controllers - primarily for historical reasons and in order not to expose the root file system to the risks of the "fresh" EA implementation that still existed at that time. Kind regards Matthias smime.p7s Description: S/MIME Cryptographic Signature
Re: Branching for netbsd-10 next week
Date:Thu, 8 Dec 2022 20:21:26 +0100 From:Martin Husemann Message-ID: <20221208192126.gb...@mail.duskware.de> | Now the question: should the default install really use this new FFS type, | or should it default to plain FFSv2? I'd suggest FFSv2, but that's not much more than a suggestion. | - unaware users may install FFSv2ea file systems and later find the need |to access them from older NetBSD kernels. "Downgrading" them is |quite easy using the ufs2ea-flip tool mentioned in the wiki page, |but it is not "plug & play". I thought that tool was intended to take old (as in what existed at the start of this year in HEAD) FFSv2 files with EAs and convert them into FFSv2ea filesystems? Downgrading necessarily loses the EA data, and ought to be accomplished by simply changing the filesystem type (on a clean filesystem) and running fsck -fy -- the loss of data makes that an unattractive thing to suggest. I wonder if we could perhaps have FFSv2pea filesystems (p==potential) - that is one which allows creation of EAs, automatically switches itself to FFSv2ea if an EA is created (and then just stays that way without specific action), but is otherwise identical to an FFSv2 filesystem (so much so that one can be downgraded by simply flipping the magic number and doing nothing else) ? fsck could treat those exactly like FFSv2, plus verifying the EA inode fields contain nothing. | - if FFSv2ea is not the default, most new installs will create non-EA |enabled file systems and | - the EAs will not get much testing That one is an issue, so I'd probably leave it like it is, probably with a warning in the initial motd, when -10 is branched, for those who want to get started on -10 early (beta testers, who may be expected to understand things a bit better), and in HEAD, but switch 10 back just before it is actually released. | - packets from pkgsrc (like samba) will continue to have the | corresponding options disabled by default Those packages could have warnings in DESCR and MESSAGE (or whatever it is called) advising of the need for FFSv2ea for full functionality. How does samba (and anything else like it) deal with this - if it is a compile time option, then since NetBSD supports EAs (and hence the sys call interface exists) EA support in samba should be enabled. More likely it is to be a run time problem, as whether a filesys has EA support or not will vary, some might, others not, so whether samba can provide EA functionality will tend to vary file by file (or at least directory by directory) - given that, a solid warning that FFSv2ea support is needed in the samba man page (or other doc) for NetBSD should allow users to know what to do. | - users will have a hard time to find the conversion options later. If that's correct, then we need better doc. Perhaps an entry in a FAQ "How do I enable extended attributes" and "How to I export a filesystem to FreeBSD/linux/..." kre
Branching for netbsd-10 next week
Hey folks, after the EA changes are in current now and all tests look good, we can finally move on and branch for netbsd-10. Proposed date is next wednsday. We have quite a few things to finish before the final release, but this gets things moving - and I hope it will not take more than three months to get the release out of the door. Before the branch one final issue needs to be decided, and I would like to solicit your feedback on this: With the new EA-enabled variant of FFSv2 (see https://wiki.netbsd.org/features/UFS2ea/ for details) we have the choice to use ACLs and EAs on FFS file systems - which makes them incompatible with all prior releases and other operating systems - or to forbid them. The installer offers upto three options for FFS file systems: - FFSv1, typically only used with bootloaders that did not get FFSv2 support yet or firmware that loads the kernel directly (examples: mac68k or shark). - FFSv2, compatible with older releases but not supporting EAs/ACLs. In read-only mode partly compatible with other operating systems. - FFSv2ea, with full support for EAs and ACLs, but incompatible with all prior NetBSD releases and all other operating systems (the file system superblock has a different magic number, so will be rejected by older code). Currently the installer defaults to creating FFSv2ea file systems for new installations, so if you do intend to share a partition with older NetBSD kernels, be sure to change the filesystem type. This will require a good description in the release notes, and probably more extensions to the wiki page pointed to above. Now the question: should the default install really use this new FFS type, or should it default to plain FFSv2? The change is trivial and from my PoV both choices have serious downsides: - unaware users may install FFSv2ea file systems and later find the need to access them from older NetBSD kernels. "Downgrading" them is quite easy using the ufs2ea-flip tool mentioned in the wiki page, but it is not "plug & play". - if FFSv2ea is not the default, most new installs will create non-EA enabled file systems and - the EAs will not get much testing - packets from pkgsrc (like samba) will continue to have the corresponding options disabled by default - users will have a hard time to find the conversion options later. It is hidden in fsck_ffs(8) and quite simple: after having made sure your bootloader is up to date, boot to single user and run something like: "fsck_ffs -c ea /" So, what should be the default FFS type for new installs in netbsd-10 ? Martin
Re: Branching for NetBSD 10
> > On Sat, Jun 04, 2022 at 05:16:34AM +, Thomas Mueller wrote: > > My big concern with the branch is the entropy bug, where building > > many packages from pkgsrc is stopped. > Yes, you are kinda right: > https://wiki.netbsd.org/releng/netbsd-10/ > "Waiting for Randot" as open point, although you may notice that all other > entropy related subpoints have been dealt with. > But again: this is not a bug, but a broken system setup - and nowadays > it is pretty hard to get into that state on new installations. The installer > will push you very hard to fix the setup before completing installation. > Various improvements in this area have happened lately, and once your > system setup is fixed (one time, and savely shutdown or rebooted w/o > crash after that fix) everything will just work. > But most importantly in this context: this is nothing that can delay > the branch itself (only the release). The one sub item that altered > libc ABI (addition of getentropy(3)) has happened. > Martin I suppose now the branch is just a few days away, and running "cvs up -dP -A" will just go the new HEAD? A lot must have happened with NetBSD-current since the time of 9.99.82, a little more than one year ago. I will want to try on amd64 and i386. Tom
Re: Branching for NetBSD 10
On Fri 03 Jun 2022 at 21:08:15 +0200, Reinoud Zandijk wrote: > Well I'd like to add another point! Fixed i915 DRM support! That seems to work on my laptop (although glxgears doesn't work, so it must be missing some things) but the touchpad doesn't have any effect in my case. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Branching for NetBSD 10
On Sat, Jun 04, 2022 at 05:16:34AM +, Thomas Mueller wrote: > My big concern with the branch is the entropy bug, where building > many packages from pkgsrc is stopped. Yes, you are kinda right: https://wiki.netbsd.org/releng/netbsd-10/ "Waiting for Randot" as open point, although you may notice that all other entropy related subpoints have been dealt with. But again: this is not a bug, but a broken system setup - and nowadays it is pretty hard to get into that state on new installations. The installer will push you very hard to fix the setup before completing installation. Various improvements in this area have happened lately, and once your system setup is fixed (one time, and savely shutdown or rebooted w/o crash after that fix) everything will just work. But most importantly in this context: this is nothing that can delay the branch itself (only the release). The one sub item that altered libc ABI (addition of getentropy(3)) has happened. Martin
Re: Branching for NetBSD 10
On Sat, Jun 04, 2022 at 05:16:34AM +, Thomas Mueller wrote: > My big concern with the branch is the entropy bug, where building many > packages from pkgsrc is stopped. Isn't "entropy bug" a misnomer for the interesting libpthread bug https://gnats.netbsd.org/56414 which has recently been fixed? Cheers, Patrick
Re: Branching for NetBSD 10
> On Mon, May 02, 2022 at 04:22:56PM +0200, Martin Husemann wrote: > > After a bit more than two years after the first NetBSD 9 release > > (9.0 happened February 14, 2020) and nearly a year after the last > > (so far) netbsd-9 release (9.2 happened May 12, 2021) we are in > > the final steps to prepare for the next really great release: > > > We are planning to branch netbsd-10 in about a week from now. > As you may have noticed, this did not happen. > Those who followed the NetBSD Foundation's annual general meeting saw > that we discussed a new plan that wanted to branch early two weeks ago - > and that also did not happen. > The major issue that came up late and that we are now trying to resolve > properly before the branch (so we can document what people testing the > branch need to know about it) is the handling of extended attributes > on FFS file systems. > See the thread about "File system corruption due to UFS2 extended attributes" > on current-users and tech-kern, starting here: > https://mail-index.netbsd.org/tech-kern/2022/05/24/msg028105.html > We hope to have these changes landed within the next few days and will > start with the branch process right after that. > Sorry for yet another delay, but let's do it right. > Martin > P.S.: of course the *real* cause for the delay is that we are still trying > very hard to find reasons to bump the -current version to 9.99.99 - only > two bumps to go! My big concern with the branch is the entropy bug, where building many packages from pkgsrc is stopped. I don't know if the situation now with NetBSD-current is any better than it was with NetBSD 9.99.82 (amd64 and i386). Is there any way to build NetBSD from source to disable the entropy bug, so it does not get in the way? Tom
Re: Branching for NetBSD 10
| Date: Fri, 3 Jun 2022 21:08:15 +0200 | From: Reinoud Zandijk | Well I'd like to add another point! Fixed i915 DRM support! That's not needed for the branch (nor are other bugs, known or otherwise) but should certainly be fixed (if it hasn't already, I thought some progress had been made in that area?) before 10 is released, but doesn't need to be before the branch. What needs to be done before the branch is anything that affects the way people who download an alpha/beta/RC version which works (for them) but might have to change, breaking things, before the release. The UFS2 EA changes are like that, because they will alter filesystem parameters. kre ps: while I'd definitely like to see 9.99.99 (even better if I'm still around when we get to 99.99.99 - seems unlikely at our release pace though!) but I'd also like to see is go beyond that to 9.99.100 just to demonstrate that it can be done, and make sure nothing is making any incorrect assumptions.
Re: Branching for NetBSD 10
On Fri, Jun 03, 2022 at 03:32:50PM +0200, Martin Husemann wrote: > On Mon, May 02, 2022 at 04:22:56PM +0200, Martin Husemann wrote: > > We are planning to branch netbsd-10 in about a week from now. > > As you may hgqapave noticed, this did not happen. > Those who followed the NetBSD Foundation's annual general meeting saw > that we discussed a new plan that wanted to branch early two weeks ago - > and that also did not happen. > > The major issue that came up late and that we are now trying to resolve > properly before the branch (so we can document what people testing the > branch need to know about it) is the handling of extended attributes > on FFS file systems. Well I'd like to add another point! Fixed i915 DRM support! There are quite some machines featuring them and the only result they get is a black screen or even a locked up machine when it used to work fine. People won't be expecting this. Reinoud
Re: Branching for NetBSD 10
On Mon, May 02, 2022 at 04:22:56PM +0200, Martin Husemann wrote: > After a bit more than two years after the first NetBSD 9 release > (9.0 happened February 14, 2020) and nearly a year after the last > (so far) netbsd-9 release (9.2 happened May 12, 2021) we are in > the final steps to prepare for the next really great release: > > We are planning to branch netbsd-10 in about a week from now. As you may have noticed, this did not happen. Those who followed the NetBSD Foundation's annual general meeting saw that we discussed a new plan that wanted to branch early two weeks ago - and that also did not happen. The major issue that came up late and that we are now trying to resolve properly before the branch (so we can document what people testing the branch need to know about it) is the handling of extended attributes on FFS file systems. See the thread about "File system corruption due to UFS2 extended attributes" on current-users and tech-kern, starting here: https://mail-index.netbsd.org/tech-kern/2022/05/24/msg028105.html We hope to have these changes landed within the next few days and will start with the branch process right after that. Sorry for yet another delay, but let's do it right. Martin P.S.: of course the *real* cause for the delay is that we are still trying very hard to find reasons to bump the -current version to 9.99.99 - only two bumps to go!
Branching for NetBSD 10
Hi to all! Sorry for my bad English... nia> i915 is now perfect for me in current In my case: NetBSD-9.99.96-amd64-install.img from May 02 2022 I have access to the following computers: 1. Nettop Acer Revo Box RN86 [Intel UHD Graphics 630] with _DisplayPort_ connection (NetBSD-Current and i915 works) 2. Notebook Acer Aspire 1 A114-33 [Intel Jasper Lake UHD Graphics] with _eDP_ internal screen connection (NetBSD-Current and i915 works) 3. Desktop Acer Aspire XC-895 [Intel UHD Graphics 630] with _HDMI_ connection (NetBSD-Current and i915 doesn't work, blank screen on boot) 4. Nettop Intel NUC7PJYH [Intel HD Graphics 605] with _HDMI_ connection (NetBSD-Current and i915 doesn't work, blank screen on boot) 5. Nettop Intel NUC5PPYH [Intel HD Graphics 405] with _VGA (D-Sub)_ connection (NetBSD-Current and i915 doesn't work, blank screen on boot) I think NetBSD-9.99.96 currently works with DP and eDP, but does not work with HDMI and D-Sub.
Re: Branching for NetBSD 10
Hi, Martin Husemann écrit : > > We are planning to branch netbsd-10 in about a week from now. > [...] > > The most user visible fallout preventing testing of the new beta > versions is likely the DRM/KMS update and the current massive fallout > on intel i915 chips, here is an excerpt of the open PRs: > > https://gnats.NetBSD.org/56608 > https://gnats.NetBSD.org/56648 > https://gnats.NetBSD.org/56672 > https://gnats.NetBSD.org/56724 > https://gnats.NetBSD.org/56727 > https://gnats.NetBSD.org/56740 > https://gnats.NetBSD.org/56761 > https://gnats.NetBSD.org/56765 Might I respectfully ask about 52070 (53215 seems to be a duplicate of the first report, I don't know why there are two different numbers)? The patch from Robert Elz (in 52070, 2017-03-15) solved my problem but the PR seems to have been stuck for the last five years. Thanks.
Re: Branching for NetBSD 10
On Mon, May 02, 2022 at 04:22:56PM +0200, Martin Husemann wrote: > https://gnats.NetBSD.org/56727 Ah, my bug. For the record this was a hdaudio bug that got worse in current. jmcneill fixed it. i915 is now perfect for me in current :)
Branching for NetBSD 10
After a bit more than two years after the first NetBSD 9 release (9.0 happened February 14, 2020) and nearly a year after the last (so far) netbsd-9 release (9.2 happened May 12, 2021) we are in the final steps to prepare for the next really great release: We are planning to branch netbsd-10 in about a week from now. It seems that -current is in good shape overall, and we hope to get the big blockers resolved before the release. There is a list here: http://wiki.netbsd.org/releng/netbsd-10/ The most user visible fallout preventing testing of the new beta versions is likely the DRM/KMS update and the current massive fallout on intel i915 chips, here is an excerpt of the open PRs: https://gnats.NetBSD.org/56608 https://gnats.NetBSD.org/56648 https://gnats.NetBSD.org/56672 https://gnats.NetBSD.org/56724 https://gnats.NetBSD.org/56727 https://gnats.NetBSD.org/56740 https://gnats.NetBSD.org/56761 https://gnats.NetBSD.org/56765 We hope to get this issues resolved soonish, but couldn't allow them to further delay this long overdue branch. We don't yet know how long the branch will take to the first release (NetBSD 10), but hope it will not be more than three months. [But note that all my personal estimates on NetBSD-10 have been off by years, so this might need a correction - we will see once i915 works again.] Martin
