Re: Plans for git (was: Please check the current beta git conversions)
The underlying initializing 'git init' commit hash must be signed by security officer key having sufficient human PGP-WoT. Git also supports sha-256 soon now, adoption should be researched from various online article series and work product before committing plans... https://lwn.net/Articles/823352/ https://git-scm.com/docs/hash-function-transition ___ 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"
Plans for git (was: Please check the current beta git conversions)
On Tuesday, 1 September 2020 at 13:14:10 -0400, Ed Maste wrote: > We've been updating the svn-git converter and pushing out a new > converted repo every two weeks, and are now approaching the time where > we'd like to commit to the tree generated by the exporter, > ... Somehow I've missed this development. Reading between the lines, it seems that we're planning to move from svn to git, but I can't recall seeing any announcement on the subject. Can you give some background? It would also be nice to find a HOWTO both for the migration and for life with git. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA signature.asc Description: PGP signature
Re: Please check the current beta git conversions
On Tue, Sep 1, 2020 at 7:38 PM Thomas Mueller wrote: > from Ed Maste: > > > > Any guidance on amount of diskspace and how long it takes to clone the > repo ? > > > I see just over 3GB in my clone, including about 2.5GB in the .git > directory. > > > If you have only one checkout git will require a bit more disk space > > than svn. However, if you have two or more working trees (say, vanilla > > FreeBSD and multiple work-in-progress trees, or head and stable > > branches, etc.) using "git worktree" will share the .git directory and > > in total will occupy less space than the equivalent in svn. > > > I'd expect clones to take minutes, although cgit-beta is running on a > > lower spec jail host and might have trouble if many people are cloning > > at the same time. > > 2.5 GB in .git directory sounds crazy and incomprehensible to me. > > Only src tree I would be interested in now is HEAD (13-current), though I > would also want the ports and doc trees. Would that mollify the diskspace > bloat? > > I had trouble with the ethernet and wireless network drivers in FreeBSD 12 > and 13-current, but there subsequently was a post on a big improvement to > the network drivers for HEAD but not 12-stable. > > So I am abandoning FreeBSD 12.x . > > Hopefully I could update 13-current from within 13-current where I have no > internet access but could use git from NetBSD, where I also have svn. > > Tom > Not really much different from subversion. .svn in /usr/sys is also 2.5G, at least for 12.1. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Please check the current beta git conversions
from Ed Maste: > > Any guidance on amount of diskspace and how long it takes to clone the repo > > ? > I see just over 3GB in my clone, including about 2.5GB in the .git directory. > If you have only one checkout git will require a bit more disk space > than svn. However, if you have two or more working trees (say, vanilla > FreeBSD and multiple work-in-progress trees, or head and stable > branches, etc.) using "git worktree" will share the .git directory and > in total will occupy less space than the equivalent in svn. > I'd expect clones to take minutes, although cgit-beta is running on a > lower spec jail host and might have trouble if many people are cloning > at the same time. 2.5 GB in .git directory sounds crazy and incomprehensible to me. Only src tree I would be interested in now is HEAD (13-current), though I would also want the ports and doc trees. Would that mollify the diskspace bloat? I had trouble with the ethernet and wireless network drivers in FreeBSD 12 and 13-current, but there subsequently was a post on a big improvement to the network drivers for HEAD but not 12-stable. So I am abandoning FreeBSD 12.x . Hopefully I could update 13-current from within 13-current where I have no internet access but could use git from NetBSD, where I also have svn. 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: /sys/modules/ nfscl & nfsd
Julian H. Stacey wrote: >Hi curr...@freebsd.org, > >/sys/modules/ nfscl & nfsd >With .ctm_status src-cur 14656 .svn_revision 364986 > >/usr/src/sys/fs/nfsclient/nfs_clkrpc.c:40:10: fatal error: 'opt_kern_tls.h' >file not found ># #include "opt_kern_tls.h" > ># /usr/src/sys/modules/nfsd ># /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:41:10: fatal error: >'opt_kern_tls.h' file not found > >Avoided for now by manualy patching out modules/Makefile Should be fixed by r365262. Thanks for reporting it, rick Cheers, Julian -- Julian Stacey, Consultant Sys. Engineer, BSD Linux http://berklix.com/jhs/ Crash Brexit Dec. 2020 paid by speculators. http://berklix.uk/brexit/#money Contraception V. Global warming, pollution, hunger, contagion, resource wars. ___ 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" ___ 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"
/usr/src/cddl/sbin/zfs don't know how to make zfs-change-key.8
Hi curr...@freebsd.org, With .ctm_status src-cur 14656 .svn_revision 364986 /usr/src/cddl/sbin/zfs # bmake[4]: don't know how to make zfs-change-key.8. Stop Avoided for now with /etc/src.conf WITHOUT_ZFS=YES Cheers, Julian -- Julian Stacey, Consultant Sys. Engineer, BSD Linux http://berklix.com/jhs/ Crash Brexit Dec. 2020 paid by speculators. http://berklix.uk/brexit/#money Contraception V. Global warming, pollution, hunger, contagion, resource wars. ___ 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"
/sys/modules/ nfscl & nfsd
Hi curr...@freebsd.org, /sys/modules/ nfscl & nfsd With .ctm_status src-cur 14656 .svn_revision 364986 /usr/src/sys/fs/nfsclient/nfs_clkrpc.c:40:10: fatal error: 'opt_kern_tls.h' file not found # #include "opt_kern_tls.h" # /usr/src/sys/modules/nfsd # /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:41:10: fatal error: 'opt_kern_tls.h' file not found Avoided for now by manualy patching out modules/Makefile Cheers, Julian -- Julian Stacey, Consultant Sys. Engineer, BSD Linux http://berklix.com/jhs/ Crash Brexit Dec. 2020 paid by speculators. http://berklix.uk/brexit/#money Contraception V. Global warming, pollution, hunger, contagion, resource wars. ___ 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"
/usr/src/usr.bin/gh-bc don't know how to make /usr/src/contrib/bc/locales/en_US.UTF-8.msg
Hi curr...@freebsd.org, /usr/src/usr.bin/gh-bc don't know how to make /usr/src/contrib/bc/locales/en_US.UTF-8.msg With .ctm_status src-cur 14656 .svn_revision 364986 /usr/src/usr.bin/gh-bc Avoided for now with /etc/src.conf WITHOUT_GH_BC=YES Cheers, Julian -- Julian Stacey, Consultant Sys. Engineer, BSD Linux http://berklix.com/jhs/ Crash Brexit Dec. 2020 paid by speculators. http://berklix.uk/brexit/#money Contraception V. Global warming, pollution, hunger, contagion, resource wars. ___ 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: Please check the current beta git conversions
On Tue, Sep 01, 2020 at 01:43:19PM -0400, Ed Maste wrote: > Thanks for the report - I wouldn't be surprised if the host is a bit > bogged down from folks trying this just after my message went out. > Once your clone finishes please do let us know how long it took > overall. time git clone https://cgit-beta.freebsd.org/src.git freebsd-cgit-beta Cloning into 'freebsd-cgit-beta'... remote: Enumerating objects: 390952, done. remote: Counting objects: 100% (390952/390952), done. remote: Compressing objects: 100% (30728/30728), done. remote: Total 3763254 (delta 382506), reused 360224 (delta 360224), pack-reused 3372302 Receiving objects: 100% (3763254/3763254), 1.10 GiB | 876.00 KiB/s, done. Resolving deltas: 100% (2984823/2984823), done. Updating files: 100% (81780/81780), done. Executed in 30.36 mins fish external usr time 666.58 secs 672.00 micros 666.58 secs sys time 30.38 secs 144.00 micros 30.38 secs signature.asc Description: PGP signature
Re: Please check the current beta git conversions
On Tue, Sep 01, 2020 at 01:14:10PM -0400, Ed Maste wrote: > We've been updating the svn-git converter and pushing out a new > converted repo every two weeks, and are now approaching the time where > we'd like to commit to the tree generated by the exporter, and > guarantee that hashes will remain consistent from this point. At this > point the Git Working Group believes the conversion represents a > high-fidelity translation of the Subversion history, but would > appreciate additional review in case we've missed anything. > > I'd ask folks with an interest in the FreeBSD repository to clone the > beta conversion and review the converted history in the specific areas > they are interested in - e.g., specific contrib/ software, device > drivers, etc. This will also present our final opportunity to change > the author map file, if necessary. > > The beta src tree can be cloned via: > % git clone https://cgit-beta.freebsd.org/src.git freebsd-cgit-beta > > Please follow up this week if you notice any discrepancies or author > entries that require updates. Hello, While I can clone src nicely, it is very slow in Serbia/Europe. The best speed I got is 1.45MB/s but it's mostly around 700kB/s (still cloning). It is probably not what you asked for, I just wanted you to know what's the speed over here. Are there any mirrors planned? If not, is github mirror recommended (mostly, what's the difference if I clone from cgit vs github)? Also, you probably want to hide gitolite-admin repo from cgit (not a biggie). Regards, meka signature.asc Description: PGP signature
Re: usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR
driesm.michi...@gmail.com wrote: I just want to add a "me to" here. With a recent upgrade of CURRENT on my laptop, these error messages started popping up. Possibly not really harming anything under the hood though. Looks like r365029 fixed it for me, and even ubt0 is back happily spamming console with netgraph warnings; didn't notice its absence as I'm not using bluetooth at the moment. -Original Message- From: owner-freebsd-curr...@freebsd.org On Behalf Of Yuri Pankov Sent: Thursday, 27 August 2020 21:18 To: bob prohaska Cc: curr...@freebsd.org Subject: Re: usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR bob prohaska wrote: On Thu, Aug 27, 2020 at 09:41:16PM +0300, Yuri Pankov wrote: Another issue that I started seeing lately, didn't try finding out when exactly in case someone knows what it's about: Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR [details snipped] So far not seeing any ill effects from this, i.e. I can connect USB HDD to these ports, and it's successfully detected. If it's convenient, connecting a USB-serial adapter and rebooting might be interesting. I'm having trouble with FT232 obstructing disk detection in some cases and self-disconnecting in others on a Pi3B. Don't have one. It is "desktop" PC, so the only USB devices I have/need are keyboard/mouse and memsticks. ___ 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: What is the zstreamdump command in OpenZFS?
On 9/1/20 2:13 PM, Ryan Moeller wrote: On 9/1/20 1:32 PM, Thomas Laus wrote: Group: Whenever I perform a major upgrade to any of my ZFS pools, I make a habit of sending the most recent snapshot to a file and then to a DLT tape or DVD. I run the zstreamdump utility on the file and record the checksum. I also run zstreamdump on the archive media and compare checksums. With the recent ZFS upgrade in CURRENT, I could not locate this utility. With a major upgrade such as this, I was really concerned about not being able to boot and loosing everything on a production system. Fortunately this upgrade went smoothly and I did not have to restore from alternate media. The next time, I may not be lucky. Tom zstreamdump is supposed to be a script wrapper around a new, more general, command: zstream #!/bin/sh zstream dump "$@" It doesn't appear to be installing itself properly, though. I'll have to look into that. https://svnweb.freebsd.org/changeset/base/365057 -Ryan ___ 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" ___ 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: What is the zstreamdump command in OpenZFS?
On 9/1/20 1:32 PM, Thomas Laus wrote: Group: Whenever I perform a major upgrade to any of my ZFS pools, I make a habit of sending the most recent snapshot to a file and then to a DLT tape or DVD. I run the zstreamdump utility on the file and record the checksum. I also run zstreamdump on the archive media and compare checksums. With the recent ZFS upgrade in CURRENT, I could not locate this utility. With a major upgrade such as this, I was really concerned about not being able to boot and loosing everything on a production system. Fortunately this upgrade went smoothly and I did not have to restore from alternate media. The next time, I may not be lucky. Tom zstreamdump is supposed to be a script wrapper around a new, more general, command: zstream #!/bin/sh zstream dump "$@" It doesn't appear to be installing itself properly, though. I'll have to look into that. -Ryan ___ 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: Please check the current beta git conversions
On Tue, 1 Sep 2020 at 13:37, Poul-Henning Kamp wrote: > > > Goran Mekić writes: > > > While I can clone src nicely, it is very slow in Serbia/Europe. The best > > speed I got is 1.45MB/s but it's mostly around 700kB/s (still cloning). > > I was about to ask about that: > > Any guidance on amount of diskspace and how long it takes to clone the repo ? I see just over 3GB in my clone, including about 2.5GB in the .git directory. If you have only one checkout git will require a bit more disk space than svn. However, if you have two or more working trees (say, vanilla FreeBSD and multiple work-in-progress trees, or head and stable branches, etc.) using "git worktree" will share the .git directory and in total will occupy less space than the equivalent in svn. I'd expect clones to take minutes, although cgit-beta is running on a lower spec jail host and might have trouble if many people are cloning at the same time. ___ 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: Please check the current beta git conversions
On Tue, 1 Sep 2020 at 13:23, Goran Mekić wrote: > > Hello, > > While I can clone src nicely, it is very slow in Serbia/Europe. Thanks for the report - I wouldn't be surprised if the host is a bit bogged down from folks trying this just after my message went out. Once your clone finishes please do let us know how long it took overall. We will have mirrors set up, which will be some combination of our own hosts, GitHub, GitLab, or other third party hosts. The current GitHub mirror is generated from an old version of svn2git, which misses a lot of metadata - in particular, merges (for vendor branch updates and such) are just missing. There are also some mistakes that originated in our Subversion mirror network that are now stuck in the current GitHub Mirror (commits authored by "svnmir" instead of the correct committer, for example). We expect we will continue to have a mirror on GitHub since many folks consider it "the" repository of open source projects. There will be a documented process for folks to migrate from the old to the new version of the mirror ___ 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: Please check the current beta git conversions
On Tue, Sep 01, 2020 at 01:14:10PM -0400, Ed Maste wrote: > We've been updating the svn-git converter and pushing out a new > converted repo every two weeks, and are now approaching the time where > we'd like to commit to the tree generated by the exporter, and > guarantee that hashes will remain consistent from this point. At this > point the Git Working Group believes the conversion represents a > high-fidelity translation of the Subversion history, but would > appreciate additional review in case we've missed anything. > > I'd ask folks with an interest in the FreeBSD repository to clone the > beta conversion and review the converted history in the specific areas > they are interested in - e.g., specific contrib/ software, device > drivers, etc. This will also present our final opportunity to change > the author map file, if necessary. > > The beta src tree can be cloned via: > % git clone https://cgit-beta.freebsd.org/src.git freebsd-cgit-beta > > Please follow up this week if you notice any discrepancies or author > entries that require updates. I'm curious if there's any plans for read-only access over ssh. Trusting FreeBSD's ssh key material is likely easier than trusting HTTPS in certain regions. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Please check the current beta git conversions
Goran Mekić writes: > While I can clone src nicely, it is very slow in Serbia/Europe. The best > speed I got is 1.45MB/s but it's mostly around 700kB/s (still cloning). I was about to ask about that: Any guidance on amount of diskspace and how long it takes to clone the repo ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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"
What is the zstreamdump command in OpenZFS?
Group: Whenever I perform a major upgrade to any of my ZFS pools, I make a habit of sending the most recent snapshot to a file and then to a DLT tape or DVD. I run the zstreamdump utility on the file and record the checksum. I also run zstreamdump on the archive media and compare checksums. With the recent ZFS upgrade in CURRENT, I could not locate this utility. With a major upgrade such as this, I was really concerned about not being able to boot and loosing everything on a production system. Fortunately this upgrade went smoothly and I did not have to restore from alternate media. The next time, I may not be lucky. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: installkernel: install: /usr/lib/debug/boot/kernel/: No such file or directory *** Error code 71
It's not my bug but i'll make sure it is taken care of. On 8/30/20, Hartmann, O. wrote: > On Fri, 28 Aug 2020 13:16:05 +0200 > Mateusz Guzik wrote: > >> On 8/28/20, Hartmann, O. wrote: >> > On Fri, 28 Aug 2020 12:31:21 +0200 >> > Mateusz Guzik wrote: >> > >> >> Can you show more of the log? >> >> >> >> When you installkernel you should see: >> >> mkdir -p /boot/kernel >> >> install -p -m 555 -o root -g wheel kernel /boot/kernel/ >> > >> > These lines are seen right after the beginning of "make >> > installkernel". >> >> mkdir -p /usr/lib/debug/boot/kernel >> >> install -p -m 555 -o root -g wheel kernel.debug >> >> /usr/lib/debug/boot/kernel/ >> > >> > I wouldn't expect these lines according to my /etc/src.conf, since I >> > disbaled debugging and installing debugging infos. >> >> >> >> Did these succeed? Do these dirs exist now? >> > >> > It is not existent, as expected: >> > >> > >> > # ll /usr/lib/debug/boot/kernel/ >> > ls: /usr/lib/debug/boot/kernel/: No such file or directory >> > >> >> Ok. I recently made changes to the namecache, which if buggy, could >> have resulted in woes like the above. >> >> Thus it looks like the newly imported zfs does not respect >> WITHOUT_DEBUG_FILES. > > Even in r364973 the problem still remains. > Disabling option WITHOUT_DEBUG_FILES in src.conf is exhausting the > /usr/obj partition (using UFS/FFS) and no option. > > Got now several boxes having "make installkernel" issued with a running > system but incomplete kernel installation, as buildkernel suggested a > clean build. Can this be fixed, please? > > >> >> >> >> >> On 8/28/20, Hartmann, O. wrote: >> >> > On CURRENT (FreeBSD 13.0-CURRENT #185 r364767: Tue Aug 25 >> >> > 16:10:50 CEST 2020 amd64), /usr/src at revision 364907, >> >> > installkernel fails now due to an error as shown below. For the >> >> > record, "options ZFS" ist statically in the kernel config file. >> >> > >> >> > Also deleting /usr/obj and restarting buildworld and buildkernel >> >> > from scratch doesn't solve the problem. The buildworld and >> >> > buildkernel mutually finish without error (I do not see any on >> >> > the console), installworld also finishes fine, but installkernel >> >> > not. >> >> > >> >> > /etc/src.conf looks as follows: >> >> > >> >> > [...] >> >> > CPUTYPE?= native >> >> > # World >> >> > CFLAGS+=-O3 >> >> > #CFLAGS+= -DNDEBUG >> >> > # Kernel >> >> > COPTFLAGS+= -O3 >> >> > #COPTFLAGS+=-DNDEBUG >> >> > #CXXFLAGS+= -std=c++17 >> >> > WITH_CLANG_EXTRAS= YES >> >> > WITH_LLDB= YES >> >> > #WITH_BSD_GREP= YES >> >> > WITH_OFED_EXTRA=YES >> >> > WITH_NAND= YES >> >> > #WITH_CTF= YES >> >> > WITH_SVN= YES >> >> > WITH_BEARSSL= YES >> >> > WITH_PIE= YES >> >> > WITH_SORT_THREADS= YES >> >> > WITH_ZONEINFO_LEAPSECONDS_SUPPORT= YES >> >> > MALLOC_PRODUCTION= YES >> >> > WITHOUT_ASSERT_DEBUG= YES >> >> > WITHOUT_TESTS= YES >> >> > WITHOUT_PROFILE=YES >> >> > WITHOUT_DEBUG_FILES=YES >> >> > WITHOUT_REPRODUCIBLE_BUILD= YES >> >> > >> >> > [...] >> >> > >> >> > Debugging facilities are disabled as src.conf indicates. >> >> > >> >> > [...] >> >> > install -T release -o root -g wheel -m 555 xz.ko >> >> > /boot/kernel/ ===> zfs (install) >> >> > install -T release -o root -g wheel -m 555 zfs.ko /boot/kernel/ >> >> > install -T dbg -o root -g wheel -m 555 zfs.ko.debug >> >> > /usr/lib/debug/boot/kernel/ >> >> > install: /usr/lib/debug/boot/kernel/: No such file or directory >> >> > *** Error code 71 >> >> > >> >> > Stop. >> >> > make[4]: stopped in /usr/src/sys/modules/zfs >> >> > *** Error code 1 >> >> > *** Error code 1 >> >> > >> >> >> >> >> > >> > >> >> > > -- Mateusz Guzik ___ 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"
Please check the current beta git conversions
We've been updating the svn-git converter and pushing out a new converted repo every two weeks, and are now approaching the time where we'd like to commit to the tree generated by the exporter, and guarantee that hashes will remain consistent from this point. At this point the Git Working Group believes the conversion represents a high-fidelity translation of the Subversion history, but would appreciate additional review in case we've missed anything. I'd ask folks with an interest in the FreeBSD repository to clone the beta conversion and review the converted history in the specific areas they are interested in - e.g., specific contrib/ software, device drivers, etc. This will also present our final opportunity to change the author map file, if necessary. The beta src tree can be cloned via: % git clone https://cgit-beta.freebsd.org/src.git freebsd-cgit-beta Please follow up this week if you notice any discrepancies or author entries that require updates. ___ 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: should rpctlssd be called rpc.tlssd?
Gary Jennejohn wrote:On Tue, 1 Sep 2020 13:00:33 +0200 (CEST) >Ronald Klop wrote: >> Van: Rick Macklem >> Datum: dinsdag, 1 september 2020 04:37 >> Aan: "freebsd-current@FreeBSD.org" >> Onderwerp: should rpctlssd be called rpc.tlssd? >> > >> > This sounds trivial, but I thought I'd ask, in case anyone >> > has a preference? >> > >> > The NFS over TLS code includes two daemons, one for >> > the client and one for the server. >> > I have called them rpctlscd and rpctlssd. >> > >> > There was/is a tradition in Sun RPC of putting a "." in >> > the names. >> > So, should I be calling these daemons: >> > rpc.tlscd and rpc.tlssd? >> >> I don't have an opinion about the rpc* vs rpc.* tradition. >> But what I do not understand is why the difference between 2 daemons >> is only reflected in 1 character of their names. The rest of the >> name is actually not really significant in keeping them apart. >> > >I had the same reaction. Maybe something like rpc.tlsclntd and rpc.tlsservd? Good point. Ben Kaduk thought the second "s" was a typo. So, unless I hear comments to the contrary, rpc.tlsclntd and rpc.tlsservd it is. Thanks everyone for your comments, rick ps: Using a single letter was the old tradition of "shorter is better". ls, cp, mv instead of dir, copy, move But these aren't commands typed by users, so having move obvious names seems correct. -- Gary Jennejohn ___ 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"
Call for 2020Q3 quarterly status reports
Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is October, 1st 2020 for work done since the last round of Quarterly Reports: July 2020 - September 2020. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the Markdown template, fill it in, and email it to quarterly-submissi...@freebsd.org. The template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md We look forward to seeing your 2020Q3 reports! Thanks, Daniel Ebdrup Jensen (on behalf of quarterly@) ___ freebsd-quarterly-ca...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls To unsubscribe, send any mail to "freebsd-quarterly-calls-unsubscr...@freebsd.org" ___ 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: should rpctlssd be called rpc.tlssd?
On Tue, 1 Sep 2020 13:00:33 +0200 (CEST) Ronald Klop wrote: > Van: Rick Macklem > Datum: dinsdag, 1 september 2020 04:37 > Aan: "freebsd-current@FreeBSD.org" > Onderwerp: should rpctlssd be called rpc.tlssd? > > > > This sounds trivial, but I thought I'd ask, in case anyone > > has a preference? > > > > The NFS over TLS code includes two daemons, one for > > the client and one for the server. > > I have called them rpctlscd and rpctlssd. > > > > There was/is a tradition in Sun RPC of putting a "." in > > the names. > > So, should I be calling these daemons: > > rpc.tlscd and rpc.tlssd? > > I don't have an opinion about the rpc* vs rpc.* tradition. > But what I do not understand is why the difference between 2 daemons > is only reflected in 1 character of their names. The rest of the > name is actually not really significant in keeping them apart. > I had the same reaction. Maybe something like rpc.tlsclntd and rpc.tlsservd? -- Gary Jennejohn ___ 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: should rpctlssd be called rpc.tlssd?
Van: Rick Macklem Datum: dinsdag, 1 september 2020 04:37 Aan: "freebsd-current@FreeBSD.org" Onderwerp: should rpctlssd be called rpc.tlssd? This sounds trivial, but I thought I'd ask, in case anyone has a preference? The NFS over TLS code includes two daemons, one for the client and one for the server. I have called them rpctlscd and rpctlssd. There was/is a tradition in Sun RPC of putting a "." in the names. So, should I be calling these daemons: rpc.tlscd and rpc.tlssd? I don't have an opinion about the rpc* vs rpc.* tradition. But what I do not understand is why the difference between 2 daemons is only reflected in 1 character of their names. The rest of the name is actually not really significant in keeping them apart. Regards and happy hacking, Ronald. > Thanks, rick ___ 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" ___ 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"
