Re: i915 observations
On Wed, Dec 14, 2022 at 11:14:31PM +, RVP wrote: > xrandr rotation on my laptop display worked fine on Linux. (On NetBSD, > I have to use wsfb--the other drivers are either unusable or hang the > system.) On Linux it works with intel driver and without any AccelMethod explicitly set. On NetBSD it works with intel driver and with UXA but only in default mode of eDP1. Mode change on eDP1 or any mode on HDMI work sluggishly. Assuming x11 world may not differ much on both OSes (I am using modular x11), isn't it i915 driver that must be making a difference? -- Mayuresh
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
daily CVS update output
Updating src tree: P src/distrib/notes/common/main P src/doc/BRANCHES P src/doc/CHANGES P src/doc/CHANGES.prev P src/external/gpl2/groff/tmac/mdoc.local P src/share/man/man7/sysctl.7 P src/sys/dev/tprof/tprof.c P src/sys/kern/uipc_mbuf.c P src/sys/sys/mbuf.h P src/sys/sys/param.h P src/usr.sbin/sysinst/bsddisklabel.c P src/usr.sbin/tprof/tprof.8 P src/usr.sbin/tprof/tprof.c P src/usr.sbin/tprof/tprof.h P src/usr.sbin/tprof/tprof_top.c Updating xsrc tree: P xsrc/external/mit/makedepend/dist/def.h Killing core files: Updating tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/games: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-8 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.4 P usr.sbin/sysinst/bsddisklabel.c P usr.sbin/sysinst/arch/amiga/md.c P usr.sbin/sysinst/arch/atari/md.c P usr.sbin/sysinst/arch/dummy/md.c P usr.sbin/sysinst/arch/sparc/md.c P usr.sbin/sysinst/arch/sparc64/md.c Updating release-9 xsrc tree (netbsd-9): Updating release-9 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Updating file list: -rw-rw-r-- 1 srcmastr netbsd 43654757 Dec 17 03:33 ls-lRA.gz
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: /etc/protocols generation
On Thu, Dec 15, 2022 at 08:35:42PM -0500, Jan Schaumann wrote: > This, then would speak in favor of leaving the tools > in pkgsrc. Yes, and stop there. No point in automating more - just like the web files are generated by various tools from the meta-pkgs/netbsd-www pkg, the IANA-derived files can be created by whatever tools hidden in pkgsrc. Then for an update you do: - make sure you have the proper pkg(s) installed - download the latest versions and run the import tools on them - put the results in you source tree - do a full build to verify nothing broke and finaly either - install the resulting etc files on a test machine and run local ATF tests, or - do an Anita test run with the build results to verify there are no regressions. Licenses do not matter here, as long as the commited results are properly licensed. Martin
Re: /etc/protocols generation
Jan Schaumann writes:
> 1) Since this is solving the same problem using the
> same input and producing the same output, the awk
> scripts there resemble those from pkgsrc/net/iana-etc/
> necessarily. Those, however, are released under the
> Open Software License ("OSL") v. 3.0. I don't know
> whether my scripts are sufficiently original to not be
> considered derived work; if not, then we'd have to
> import those scripts using the OSL.
OSL is problematic for TNF becaues it is AGPL-like and board@ decided
that was not ok for DEFAULT_ACCEPTABLE in pkgsrc, so it is obviously not
ok in base -- even though fears of having to distribute modified
services build scripts if someone does so and runs a web service are a
bit overblown :-)
If you copied enough, it's a derivative work, and if you didn't copy, it
isn't. The fact that it ends up similar is not relevant technically,
but I can see that it is a concern when assessing risk. If there's only
one way to do it sanely and you wrote it separately, i don't see an
issue, but IANAL, IANYL, TINLA as always. I looked quickly and the
programs don't look particularly similar in details.
You could write to the author and ask if they consider what you did to
be a derived work, or permission to distribute what you did under a
2-clause BSD also crediting them. I suspect there is no actual problem.
> This, then would speak in favor of leaving the tools
> in pkgsrc. The Makefile could then perform the task
> of reaching over into pkgsrc? Seems like a messy set
> up and not much of a win. :-/
I don't think the build can depend on pkgsrc. If you mean a step in a
process to update what is checked in under src, I don't see that as a
big problem.
> 2) I wanted to add the execution of the ATF tests, but
> those literally test the outcome of the files
> installed under /etc. For a full validation, one
> would need to copy the generated file into /etc, which
> seems heavy handed to me. Having a partial test that
> may generate a diff when the file is updated seemed
> reasonable to me.
It could make sense to encapsulate in ATF building our file from sources
and then comparing it to what is checked in. It seems obviously not ok
for an ATF test to modify the running system or even DESTDIR.
signature.asc
Description: PGP signature
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.
