Re: in -current is svn still canonical?
El día lunes, noviembre 16, 2020 a las 10:32:38p. m. -0700, Warner Losh escribió: > For the supported stable branches, you'll be able to download via > subversion and switch over at any time before the end of project support > for the branch. > > However, when you make the switch to git (either due to the flag day and > tracking -current, or jumping from svn on a stable branch), there's no tool > to convert the subversion checked out tree to a git tree. The needed > information needed to create the git tree isn't easily available from the > subversion checkout, so you'll need to do a git clone. If bandwidth is a > problem, you can do a shallow clone that omits all the history and just > grabs the branch of interest. Git is a bit more link efficient than > subversion, which is helpful. Git also has ways to help you share one local > repo across checked out versions, which can also help if you have to track > multiple branches. > > Warner, please forgive me my nearly off-topic question: When we move to git, will this conserve all the FreeBSD svn history of ci's somehow? Can you please point me to a document about FreeBSD's transition from svn to git? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: in -current is svn still canonical?
On Mon, Nov 16, 2020 at 10:00 PM Thomas Mueller wrote: > > Subversion is the source of truth for FreeBSD today. > > > In the near future, likely early next month, we'll move our operations > over > > to git. Git will be the source of truth after the flag day. All developer > > operations will be in git: committing to current, and MFCing will all be > > done with git. As an aide to users that started the FreeBSD stable/11 and > > stable/12 branches, however, we'll be exporting the commits to the git > > branch stable/11 and stable/12 to subversion. The subversion tree will > > otherwise be read-only after this date. > > > The doc tree will likely convert at the same time that the src tree moves > > over. There will likely be a lag for the ports tree. It's unclear if they > > will switch at the same time as the src tree, or if there will be a > > few-months-long lag. > > > Warner > > Thanks for the information, but if you feel the need to send me a > not-quite-CC, please don't send me the multipart/alternative version when > you send the plain-text version to the list. > > I hate multipart/alternative! > I must apologize. Sadly, I use gmail, so I have no control over how it decides to encode things, sadly. I've tried in the past, and alas, nothing I've tried works for any length of time. Please forgive me whatever unspeakable MIME atrocities it sends on my behalf. I've removed you from the cc line in the hopes that the FreeBSD mail server cleans things up to be more to your liking. > When git becomes the source of truth on FreeBSD after the flag day, will > it be necessary to git-clone the whole tree from scratch, or will there be > a conversion tool to switch the svn download to proper git format? > For the supported stable branches, you'll be able to download via subversion and switch over at any time before the end of project support for the branch. However, when you make the switch to git (either due to the flag day and tracking -current, or jumping from svn on a stable branch), there's no tool to convert the subversion checked out tree to a git tree. The needed information needed to create the git tree isn't easily available from the subversion checkout, so you'll need to do a git clone. If bandwidth is a problem, you can do a shallow clone that omits all the history and just grabs the branch of interest. Git is a bit more link efficient than subversion, which is helpful. Git also has ways to help you share one local repo across checked out versions, which can also help if you have to track multiple branches. > The doc tree is much smaller than the src tree, while the ports tree is > much bigger than the src tree. Is that the reason for the few-months-long > lag switching the ports trree to git? > There's a couple of things that make it trickier. The ports tree does quarterly branches. So there's a window around the quarterly branch when it's easiest to make the switch. In addition, the character of the files in the ports tree differs from src. Unlike subversion, git infers copies, moves, etc. The mostly similar nature of the ports tree is likely to cause git grief when ports are copied, resurrected from the attic, etc. The ports folks are still figuring out how to best use git to track the history they need to track without creating undue issues. It's not clear if that will all be sorted out before the next window in December, or if they will have to defer until March. This is why I hedged a bit as to the exact time, since it's not been nailed down yet. So it's not so much the size, as the difference in makeup and character between the two trees. The doc tree is, as you point out, much smaller, less active and its needs are more modest and largely mirror the src tree, so it can be done quickly at any time. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: in -current is svn still canonical?
> Subversion is the source of truth for FreeBSD today. > In the near future, likely early next month, we'll move our operations over > to git. Git will be the source of truth after the flag day. All developer > operations will be in git: committing to current, and MFCing will all be > done with git. As an aide to users that started the FreeBSD stable/11 and > stable/12 branches, however, we'll be exporting the commits to the git > branch stable/11 and stable/12 to subversion. The subversion tree will > otherwise be read-only after this date. > The doc tree will likely convert at the same time that the src tree moves > over. There will likely be a lag for the ports tree. It's unclear if they > will switch at the same time as the src tree, or if there will be a > few-months-long lag. > Warner Thanks for the information, but if you feel the need to send me a not-quite-CC, please don't send me the multipart/alternative version when you send the plain-text version to the list. I hate multipart/alternative! When git becomes the source of truth on FreeBSD after the flag day, will it be necessary to git-clone the whole tree from scratch, or will there be a conversion tool to switch the svn download to proper git format? The doc tree is much smaller than the src tree, while the ports tree is much bigger than the src tree. Is that the reason for the few-months-long lag switching the ports trree to git? Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: in -current is svn still canonical?
On Mon, Nov 16, 2020 at 7:48 PM Thomas Mueller wrote: > from tech-lists: > > > As subject - is svn still canonical for -current or is it git now? > > If it's not git now, when roughly is the intended switch? > > I recently updated FreeBSD doc, ports, src (current), and src12 > (12-stable) using svn (not svnup or svnlite). > > But I read some time before that, FreeBSD current source would go on git, > while other src trees (non-current), ports and doc would stay with svn for > the time being, until git on current src is further tested and stabilized. > Subversion is the source of truth for FreeBSD today. In the near future, likely early next month, we'll move our operations over to git. Git will be the source of truth after the flag day. All developer operations will be in git: committing to current, and MFCing will all be done with git. As an aide to users that started the FreeBSD stable/11 and stable/12 branches, however, we'll be exporting the commits to the git branch stable/11 and stable/12 to subversion. The subversion tree will otherwise be read-only after this date. The doc tree will likely convert at the same time that the src tree moves over. There will likely be a lag for the ports tree. It's unclear if they will switch at the same time as the src tree, or if there will be a few-months-long lag. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: in -current is svn still canonical?
from tech-lists: > As subject - is svn still canonical for -current or is it git now? > If it's not git now, when roughly is the intended switch? I recently updated FreeBSD doc, ports, src (current), and src12 (12-stable) using svn (not svnup or svnlite). But I read some time before that, FreeBSD current source would go on git, while other src trees (non-current), ports and doc would stay with svn for the time being, until git on current src is further tested and stabilized. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On Mon, Nov 16, 2020 at 10:56:06AM +, Graham Perrin wrote: > On 16/11/2020 09:32, Benjamin Kaduk wrote: > > On Mon, Nov 16, 2020 at 09:27:29AM +, Graham Perrin wrote: > > > Attempting to build r367615 on Friday 13th: > > > > > > … > > > > > > ===> lib/libprocstat/zfs (install) > > > install -U -C -o root -g wheel -m 444 > > > /usr/src/lib/libprocstat/libprocstat.h > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ > > > ===> lib/libc (obj,all,install) > > > install -U -C -o root -g wheel -m 444 libc.a > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ > > > install -U -s -o root -g wheel -m 444 -S libc.so.7 > > > /usr/obj/usr/src/amd64.amd64/tmp/lib/ > > > install -U -o root -g wheel -m 444 libc.so.7.debug > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ > > > install: short write to > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: > > > 393216 bytes written, 7462472 bytes asked to write > > > *** [_libinstall] Error code 71 > > Is your disk/filesystem full? > > > > -Ben > AVAIL: 204G And what is the type of filesystem you are _installing_ to ? Also what is the type of filesystem for /tmp, and how much space do you have there ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
acpi_wmi noisy without EC
I have started seeing the following on boot since some time: acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device device_attach: acpi_wmi0 attach returned 6 Likely following this commit: commit 708d048ccfdacf6199cc08a56aa05a9c899441fd Author: Vladimir Kondratyev Date: Sat Oct 31 22:19:39 2020 + acpi_wmi(4): Add ACPI_PNP_INFO While the reason is obvious -- there's no EC in this system (Gigabyte X299X AORUS MASTER desktop motherboard), at least searching the `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly looks like "something is broken" when first noticed. I wonder if we could/should handle this gracefully -- no EC, do nothing, simply exit? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
in -current is svn still canonical?
Hi As subject - is svn still canonical for -current or is it git now? If it's not git now, when roughly is the intended switch? thanks, -- J. signature.asc Description: PGP signature
ghostBSD-CURRENT?
hi again, now world is installed and mergemaster done I get every time I try to command pkg: cannot determine local path. built pkg or pkg-devel from /ports/ports-mgmt pkg can't be installed as /usr/local/etc/bash_completion/_pkg.bash exists --- error 70. rm'ing doesn't help! tar -xfv pkg.tgz leads to the same output "cannot determine local path"! what now? lizbeth ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Shutdown errors and timeout
On 14/11/2020 13:03, Mateusz Piotrowski wrote:
Hi,
On 11/14/20 1:19 AM, Tomoaki AOKI wrote:
On Fri, 13 Nov 2020 20:04:59 +0900 (JST)
Yasuhiro KIMURA wrote:
From: Johan Hendriks
Hello all, i have two FreeBSD 13 machines, one is a bare metal and one
is virtualbox machine which i both update about once a week.
The vritual machine seems to fail stopping something and gives a
timeout after 90 sec.
The console ends with
Writing entropy file: .
Writing early boot entropy file: .
90 second watchdog timeout expired. Shutdown terminated.
Fri Nov13 11:20:40 CEST 2020
Nov 13 11:20:40 test-head init[1]: /etc/rc.shutdown terminated
abnormally, going to single user mode
...
On the bare metal machine i see the following.
Writing entropy file: .
Writing early boot entropy file: .
cannot unmount '/var/run': umount failed
cannot unmount '/var/log': umount failed
cannot unmount '/var': umount failed
cannot unmount '/usr/home': umount failed
cannot unmount '/usr': umount failed
cannot unmount '/': umount failed
(snip)
The pools have not been upgraded after the latest openzfs import,
maybe that is related?
FreeBSD test-freebsd-head 13.0-CURRENT FreeBSD 13.0-CURRENT #2
r367585:
First thing i noticed is about a week ago.
I'm facing same problem with 13.0-CURRENT amd64 r367487 and
virtualbox. In my case I use autofs to mount remote file system of
12.2-RELEASE amd64 server with NFSv4. When there is still filesystem
mounted by autofs, then watchdog timeout happens while shutdown. The
watchdog timeout can be worked around by executing `automount -fu`
before shutting down. But 'cannot unmount ...' error messages are
still displayed.
I added 'rc_debug="YES"' to /etc/rc.conf and checked which rc script
causes this message. Then it is displayed when following `zfs_stop`
function of /etc/rc.d/zfs is executed.
--
zfs_stop_main()
{
zfs unshare -a
zfs unmount -a
}
--
At this point syslog process still running and it opens some files
under /var/log. So it make sence that `zfs unmount -a` results in the
message.
Probably order of executing each rc script in shutdown time should be
changed so `/etc/rc.d/zfs faststop` is executed after all processes
other than `init' are exited.
This happens on stable/12, too.
As a workaround, reverting r367291 on head (r367546 on stable/12)
would stop the issue until this is really fixed.
If you have shared dataset or jail(s) mounting dataset, the workaround
would be discouraged. Read commit message for detail.
I've committed r367291 and r367546.
I am not sure if I can think of a proper fix for the described issues,
so I guess the best idea would be to revert those changes for now
until we figure out how to do it properly.
Sorry for the regression.
Best,
Mateusz
I can tell that reverting the mentioned commit i do not have the
symptoms when i reboot my servers.
Thank you all for your time, and no sorry needed ;-)
regards,
Johan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[REVIEW] new function getlocalbase() - D27236 and D27237
I have created two Phabricator reviews for my proposed implementation
of getlocalbase():
https://reviews.freebsd.org/D27236
https://reviews.freebsd.org/D27237
The first one implements getlocalbase() with quite similar semantics
to getenv("LOCALBASE") which it will replace in a number of places in
the base system.
This implementation returns a pointer to either of:
1) getenv("LOCALBASE")
2) sysctlbyname("user.localbase", ...)
3) _PATH_LOCALBASE or "/usr/local"
I had considered to copy any result of 1) or 3) into the same static
buffer used to retrieve the sysctl result, but have for now implemented
a version that returns the pointers as is (in case of getenv() into the
environment, in case of the fall-back strings into the area for R/O
strings).
I'd be willing to change this to either:
a) retrieve a value on the first invocation and copy it to the buffer
b) retrieve a new value on each invocation and copy it to the buffer
Most programs will call getlocalbase() at most once and will either
construct the required path to e.g. a config file directory from it,
or they will store a local copy. The return type should prevent any
accidental overwriting of values at the returned address (but does
not really protect e.g. the environment variable area - same as if
getenv() was directly called).
If returning the pointer into the environment is considered too
dangerous, I'd prefer to implement variant a).
A potential problem exists due the unlimited length of the string
returned by getenv("LOCALBASE"), i.e. it could cause a path name
longer than PATHNAMEMAX to be created. I do not want to introduce
a potential error return or to silently discard superfluous data
from the returned value and therefore prefer to return the pointer
into the environment area without guarantees regarding the maximum
length of the string pointed to.
The second review replaces getenv() calls with getlocalbase() in
code that already used getenv(). The code is simplified but has
unchanged behavior if LOCALBASE is defined in the environment.
If it is undefined, than the sysctl value or the hard-coded value
is returned (and the only difference is that sysctl may cause the
system wide value to be controlled without recompilation of the
world).
In one program the constant _PATH_LOCALBASE was concatenated to
a relative file path, and in that case the same approach can be
used as in the other two (with snprintf() filling a local buffer).
I have not looked for other programs that should be modified to
use getlocalbase(), but all affected by my recent _PATH_LOCALBASE
commit are candidates ...
I'd appreciate comments in the Phabricator or review or by mail.
Regards, STefan
OpenPGP_signature
Description: OpenPGP digital signature
Re: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On 16/11/2020 09:32, Benjamin Kaduk wrote: On Mon, Nov 16, 2020 at 09:27:29AM +, Graham Perrin wrote: Attempting to build r367615 on Friday 13th: … ===> lib/libprocstat/zfs (install) install -U -C -o root -g wheel -m 444 /usr/src/lib/libprocstat/libprocstat.h /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ ===> lib/libc (obj,all,install) install -U -C -o root -g wheel -m 444 libc.a /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ install -U -s -o root -g wheel -m 444 -S libc.so.7 /usr/obj/usr/src/amd64.amd64/tmp/lib/ install -U -o root -g wheel -m 444 libc.so.7.debug /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ install: short write to /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: 393216 bytes written, 7462472 bytes asked to write *** [_libinstall] Error code 71 Is your disk/filesystem full? -Ben AVAIL: 204G ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On Mon, Nov 16, 2020 at 09:27:29AM +, Graham Perrin wrote: > Attempting to build r367615 on Friday 13th: > > … > > ===> lib/libprocstat/zfs (install) > install -U -C -o root -g wheel -m 444 > /usr/src/lib/libprocstat/libprocstat.h > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ > ===> lib/libc (obj,all,install) > install -U -C -o root -g wheel -m 444 libc.a > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ > install -U -s -o root -g wheel -m 444 -S libc.so.7 > /usr/obj/usr/src/amd64.amd64/tmp/lib/ > install -U -o root -g wheel -m 444 libc.so.7.debug > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ > install: short write to > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: > 393216 bytes written, 7462472 bytes asked to write > *** [_libinstall] Error code 71 Is your disk/filesystem full? -Ben ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
Attempting to build r367615 on Friday 13th: … ===> lib/libprocstat/zfs (install) install -U -C -o root -g wheel -m 444 /usr/src/lib/libprocstat/libprocstat.h /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ ===> lib/libc (obj,all,install) install -U -C -o root -g wheel -m 444 libc.a /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ install -U -s -o root -g wheel -m 444 -S libc.so.7 /usr/obj/usr/src/amd64.amd64/tmp/lib/ install -U -o root -g wheel -m 444 libc.so.7.debug /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ install: short write to /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: 393216 bytes written, 7462472 bytes asked to write *** [_libinstall] Error code 71 make[4]: stopped in /usr/src/lib/libc 1 error make[4]: stopped in /usr/src/lib/libc root@mowa219-gjp4-8570p:/usr/src # ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
