Re: Please check the current beta git conversions
from Kevin Oberman: > > 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 My cross-post to freebsd-...@freebsd.org was rejected because I was/am not subscribed to that list. So I deactivate that part for this post. I just checked du /usr/src/.svn ; this is on 11.1-STABLE old system, but this tree is for HEAD : 5817268 : is this 1K-blocks? Now I think it's 512 bytes, in contrast to df that shows diskspace in 1-KB blocks: confusing. I no longer track FreeBSD-11 src trees. Now I wonder how this compares to git and hg: NetBSD plans to switch from cvs to Mercurial. 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: Please check the current beta git conversions
On Wed, 02 Sep 2020 08:30:28 + "Thomas Mueller" wrote: > from Kevin Oberman: > > > > 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 > > My cross-post to freebsd-...@freebsd.org was rejected because I was/am not > subscribed to that list. > > So I deactivate that part for this post. > > I just checked du /usr/src/.svn ; this is on 11.1-STABLE old system, but this > tree is for HEAD : 5817268 : is this 1K-blocks? Now I think it's 512 bytes, > in contrast to df that shows diskspace in 1-KB blocks: confusing. I no > longer track FreeBSD-11 src trees. > > Now I wonder how this compares to git and hg: NetBSD plans to switch from cvs > to Mercurial. > This is HEAD updated a short time ago (r365233): du -sh /usr/src/.svn/ 2.0G/usr/src/.svn/ -- 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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 02, 2020 at 01:20:22AM -0400, grarpamp wrote: > 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 "soon now" seems a bit vague, from what I have read on the subject, whilst the local repository operations are working with SHA256 hashes, it is still lacking remote transport, clones, and such. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Please check the current beta git conversions
On Wed, Sep 02, 2020 at 02:37:45AM +, 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. 2.5GB is for the full history, if you only care about the main branch, you can clone with: git clone --branch=main --single-branch https... It will cut .git down to about 1.2GB. If you do not care about the history and only want the tip of the branch, you can also use: git clone --branch=main --depth 1 https... This will cut it down even more to about 270MB. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Please check the current beta git conversions
Hi, > > 2.5 GB in .git directory sounds crazy and incomprehensible to me. > > 2.5GB is for the full history, if you only care about the main branch, > you can clone with: > > (snip) I do not reproduce this, but instead see `du` reporting 1.2GiB just after a simple clone (no options), which AFAIK contains the whole history. I have a complete mirror of SVN that I update with scripts around `svnrdump dump` and `svnadmin load`, and its size is 6.1GiB (I pack it regularly). For the record, here are the sizes of the `.svn` directories of some checkouts I currently have: - stable/12 at rev 355888: 1.9GiB - stable/12 at rev 361580: 2.4GiB - head at rev 361584: 2.7GiB I must point out that I don't remember the exact creation history of these. It is probable that, to create new ones, I did full copies (`cp -a`) of an old one followed by `svn switch`. Don't know if this can have an influence on these numbers (didn't test with pristine checkouts). Important tip: When using `du`, don't forget to pass the '-A' option, especially if using ZFS + compression. -- Olivier Certner ___ 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
> Receiving objects: 100% (3763254/3763254), 1.10 GiB | 876.00 KiB/s, done. > Executed in 30.36 mins Experienced a comparable full clone time yesterday afternoon from France (did not precisely `time` it). The bandwidth oscillated between 600 and 1.2MiB/s steadily during the transfer. The final reported bandwidth was 991KiB/s (same transfer size). -- Olivier Certner ___ 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: Plans for git (was: Please check the current beta git conversions)
On Wed, 2 Sep 2020 at 07:51, Mathieu Arnold wrote: > > > 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 > > "soon now" seems a bit vague, from what I have read on the subject, > whilst the local repository operations are working with SHA256 hashes, > it is still lacking remote transport, clones, and such. Yes, Git will migrate to SHA256 but will not be completely finished sufficiently soon to matter for our needs. We'll eventually deal with the migration the same way as everyone else. ___ 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: /usr/src/cddl/sbin/zfs don't know how to make zfs-change-key.8
On 9/1/20 7:42 PM, Julian H. Stacey wrote: 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 Thanks, fixed it: https://svnweb.freebsd.org/changeset/base/365250 -Ryan Avoided for now with /etc/src.conf WITHOUT_ZFS=YES Cheers, Julian ___ 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: Plans for git (was: Please check the current beta git conversions)
On Wed, 2 Sep 2020 at 02:31, Steve Kargl wrote: > > > A short intro on git for svn users: > > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view > > > > ROTFL. From the "short intro", 2nd sentence. > > New committers are assumed to already be familiar with the basic > operation of Git. If not, start by reading the Git Book. This doc started as a direct translation of the Subversion primer, which has as its first sentence: > New committers are assumed to already be familiar with the basic operation of > Subversion. If not, start by reading the Subversion Book. As with the Subversion primer the doc is intended to provide a quick reference for day-to-day commands, but not act as a reference or introduction to the entire theory of operation of the associated VCS. ___ 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: Plans for git (was: Please check the current beta git conversions)
On 2 Sep 2020, at 17:18, Ed Maste wrote: > > On Wed, 2 Sep 2020 at 07:51, Mathieu Arnold wrote: >> >>> 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 >> >> "soon now" seems a bit vague, from what I have read on the subject, >> whilst the local repository operations are working with SHA256 hashes, >> it is still lacking remote transport, clones, and such. > > Yes, Git will migrate to SHA256 but will not be completely finished > sufficiently soon to matter for our needs. We'll eventually deal with > the migration the same way as everyone else. Note that Subversion *also* uses SHA1, and has suffered from hash collisions. Which at some point broke the WebKit repository, because somebody thought it was fun to tweak two PDF files to have exactly the same SHA1. This is why Subversion added a few hook scripts to prevent adding such files: https://svn.apache.org/viewvc/subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh?view=markup https://svn.apache.org/viewvc/subversion/trunk/tools/hook-scripts/reject-detected-sha1-collisions.sh?view=markup -Dimitry signature.asc Description: Message signed with OpenPGP
Re: Plans for git (was: Please check the current beta git conversions)
> On Sep 1, 2020, at 10:59 PM, Greg 'groggy' Lehey wrote: > > 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. We’ve been talking about the transition for about 5 years now. So far, only people interested in git have showed up to do any work at all. Subversion has lost, and even Apache, the main users of it, are moving to git. We started early in the year with the firm plans and have been working on it since then. These conversations have happened all over the place, and we’ve been posting to developers for months now... There’s some draft guides, but they need work which is on my plate. They are OK, but have some issues on the more complicated bits. 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: Plans for git (was: Please check the current beta git conversions)
> On Sep 2, 2020, at 10:14 AM, Ed Maste wrote: > > On Wed, 2 Sep 2020 at 02:31, Steve Kargl > wrote: >> >>> A short intro on git for svn users: >>> https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view >>> >> >> ROTFL. From the "short intro", 2nd sentence. >> >> New committers are assumed to already be familiar with the basic >> operation of Git. If not, start by reading the Git Book. > > This doc started as a direct translation of the Subversion primer, > which has as its first sentence: >> New committers are assumed to already be familiar with the basic operation >> of Subversion. If not, start by reading the Subversion Book. > > As with the Subversion primer the doc is intended to provide a quick > reference for day-to-day commands, but not act as a reference or > introduction to the entire theory of operation of the associated VCS. The rest of the guide walks people through how to do the job, but without all the theory for the basics. Again it needs some work for the advanced topic it currently just omits... 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: Please check the current beta git conversions
On Tue, 1 Sep 2020 at 22:38, 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. In fact my clone was larger than it should be, because it had old leftover objects from earlier iterations of the conversion. After cleaning those up I see 1.5GB in .git, 2.2GB including the working tree. My .svn directory has 1.7GB of data. If you have only one working tree then Git's disk space requirements should be "about the same." Each additional working tree tips the scale increasingly in GIt's favour. If disk space is a concern you can clone with the -depth=1 option, which avoids fetching history. I tried that just now and have a .git directory of about 250MB. ___ 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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 02, 2020 at 12:14:08PM -0400, Ed Maste wrote:
> On Wed, 2 Sep 2020 at 02:31, Steve Kargl
> wrote:
> >
> > > A short intro on git for svn users:
> > > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view
> > >
> >
> > ROTFL. From the "short intro", 2nd sentence.
> >
> > New committers are assumed to already be familiar with the basic
> > operation of Git. If not, start by reading the Git Book.
>
> This doc started as a direct translation of the Subversion primer,
> which has as its first sentence:
> > New committers are assumed to already be familiar with the basic operation
> > of Subversion. If not, start by reading the Subversion Book.
>
> As with the Subversion primer the doc is intended to provide a quick
> reference for day-to-day commands, but not act as a reference or
> introduction to the entire theory of operation of the associated VCS.
Like GCC, which did the svn to git dance at start of the year,
FreeBSD is throwing away a decade+ of corporate knowledge of
working with svn and /usr/src. What is needed is a succinct
translation of the most common svn commands translated to git.
Checking out /usr/src as u...@freebsd.org
svn checkout svn+ssh://u...@svn.freebsd.org/base/head /usr/src
git ...
Checking out /usr/src without freebsd.org account
svn checkout https://svn.freebsd.org/base/head ${HOME}/freebsd/src
git ...
Creating diff against updated head.
svn update
svn diff > patch.diff
git ...
Adding a new file
svn add /usr/src/libm/msun/src/_s_sinpi.c
git ...
Committing a change to /usr/src
svn update
svn diff | more (everyone does one last check, right?)
svn commit
git ...
--
Steve
___
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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 2, 2020 at 10:47 AM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> On Wed, Sep 02, 2020 at 12:14:08PM -0400, Ed Maste wrote:
> > On Wed, 2 Sep 2020 at 02:31, Steve Kargl
> > wrote:
> > >
> > > > A short intro on git for svn users:
> > > > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view
> > > >
> > >
> > > ROTFL. From the "short intro", 2nd sentence.
> > >
> > > New committers are assumed to already be familiar with the basic
> > > operation of Git. If not, start by reading the Git Book.
> >
> > This doc started as a direct translation of the Subversion primer,
> > which has as its first sentence:
> > > New committers are assumed to already be familiar with the basic
> operation of Subversion. If not, start by reading the Subversion Book.
> >
> > As with the Subversion primer the doc is intended to provide a quick
> > reference for day-to-day commands, but not act as a reference or
> > introduction to the entire theory of operation of the associated VCS.
>
> Like GCC, which did the svn to git dance at start of the year,
> FreeBSD is throwing away a decade+ of corporate knowledge of
> working with svn and /usr/src. What is needed is a succinct
> translation of the most common svn commands translated to git.
>
> Checking out /usr/src as u...@freebsd.org
>
> svn checkout svn+ssh://u...@svn.freebsd.org/base/head /usr/src
>
> git ...
>
> Checking out /usr/src without freebsd.org account
>
> svn checkout https://svn.freebsd.org/base/head ${HOME}/freebsd/src
>
> git ...
>
> Creating diff against updated head.
>
> svn update
> svn diff > patch.diff
>
> git ...
>
> Adding a new file
>
> svn add /usr/src/libm/msun/src/_s_sinpi.c
>
> git ...
>
> Committing a change to /usr/src
>
> svn update
> svn diff | more (everyone does one last check, right?)
> svn commit
>
> git ...
>
This is an insultingly stupid comment to make. We don't need people to say
the obvious.
This sort of comment isn't helpful. People will just ignore you if you make
too many of them like it.
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: Plans for git (was: Please check the current beta git conversions)
On 2020-09-02 12:47, Steve Kargl wrote:
Checking out /usr/src as u...@freebsd.org
svn checkout svn+ssh://u...@svn.freebsd.org/base/head /usr/src
git ...
Checking out /usr/src without freebsd.org account
svn checkout https://svn.freebsd.org/base/head ${HOME}/freebsd/src
git ...
"which svnlite" -> /usr/bin/svnlite
(from /usr/src/usr.bin/svn)
"which git" -> /usr/local/bin/git
(from /usr/ports/devel/git)
After the transition, will FreeBSD base contain the tool for the cloning
the FreeBSD repository (not one of the mirrors?)
Is there a plan to have 'git' or one of its clones added to the base system?
Surprisingly, I can't seem to find any prominent discussion / debate on
"git in base" (the tool itself).
Theron
___
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: /usr/src/usr.bin/gh-bc don't know how to make /usr/src/contrib/bc/locales/en_US.UTF-8.msg
Am 02.09.20 um 01:42 schrieb Julian H. Stacey: 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 Hi Julian, since I'm building -CURRENT at least once a day with this bc and there have been no other reports, this does appear to be a local problem on your system (or a problem with CTM). Avoided for now with /etc/src.conf WITHOUT_GH_BC=YES Yes, but the correct fix is to provide the missing file, which is a symbolic link to en_US.msg. In fact, most of the message catalogs are provided by symlinks (71 of 96 files in the locales directory). My assumption is, that CTM does not correctly encode and create symbolic links, so you miss them ... (but I did not check the CTM sources to verify that assumption). This ought to be fixed in CTM and then a delta should be created that provides these missing symlinks - since you are one of very few CTM users left, you may want to create a patch ... Since the mail list strips binary attachments, I'm including a compresssed and uuencoded TAR file with these symlinks below. Extract from within src/contrib/bc/locales to generate them: begin 644 gh-bc-locales.tar.bz2 M0EIH.3%!6293618`GIIH`'ZI[JAY5#VJAUJ'0S MB5)<^7/.[OVC><;E,R%I@YC!.4$C!%0&\T"DP#,3(KT4RW8;8ZL<=^PJ'\5# MMBEQ*ABH=RH=50RH94.NHDD@:R,W/GV>3:MKS5-J$-83WJDS. M)1%%A['191"3G$0\(S*S-#O-:6214=J+2@HJ,CILM%IM\<((&8``>!/:`2:D M`UNUOIK>%^6W9OX=W/T^/CPUIGHWXYQ\=I4-M:%0\]0^BH8J'XK\# MO8SO8QF,X3FF939;&8.-0ZE0RH>JH>;DJ'ON,DNYPY9FOK!SW<\J'94-;]CL M6M^I%DP@060$<&-XODQ>V8=20"BM(8:NE8B<)(!>+T9O4D`:<5G*7:#R20#- MX2Y(!CAAV:S,Z0V--71:%+%-XN5>7>I(!F2`60,2JD1@+-54NJ)C#AQJ&HVV MTWXU#THM];M^IOIIEF\-(+*24PU)`*M+=:<7JRV2`54-.&<===0X94.VH]TG M:B\D76B^^G&>V7DL@]%87K];RF:UIIFK6M9K@>-1E'6G"M+5>2+3Y3U9GG1< M65M3M1?DTG"H[?8,9,U)P>M?4J"P(OHDY2!**Z,5&+4D"H>1>,-@`P(<($XD MY3WP^Y/=\8ASA=*BJX555YBB'.%PF`G,;A1$V!^BP`_)=0Z='LPS,F99VU#^ MR@D$#B+N2*<*$@+`$[F``` ` end But since further symlinks will occur if more locales are added, the problem will re-appear for CTM users, unless symlinks are supported by CTM. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: /usr/src/usr.bin/gh-bc don't know how to make /usr/src/contrib/bc/locales/en_US.UTF-8.msg
Thanks Stephan for your comprehensive analaysis, i'll look into all this & reports back inc. CC current. 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 ___ 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: Plans for git (was: Please check the current beta git conversions)
On Wed, 2020-09-02 at 11:11 -0600, Warner Losh wrote:
> On Wed, Sep 2, 2020 at 10:47 AM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > On Wed, Sep 02, 2020 at 12:14:08PM -0400, Ed Maste wrote:
> > > On Wed, 2 Sep 2020 at 02:31, Steve Kargl
> > > wrote:
> > > >
> > > > > A short intro on git for svn users:
> > > > > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view
> > > > >
> > > >
> > > > ROTFL. From the "short intro", 2nd sentence.
> > > >
> > > > New committers are assumed to already be familiar with the
> > > > basic
> > > > operation of Git. If not, start by reading the Git Book.
> > >
> > > This doc started as a direct translation of the Subversion
> > > primer,
> > > which has as its first sentence:
> > > > New committers are assumed to already be familiar with the
> > > > basic
> >
> > operation of Subversion. If not, start by reading the Subversion
> > Book.
> > >
> > > As with the Subversion primer the doc is intended to provide a
> > > quick
> > > reference for day-to-day commands, but not act as a reference or
> > > introduction to the entire theory of operation of the associated
> > > VCS.
> >
> > Like GCC, which did the svn to git dance at start of the year,
> > FreeBSD is throwing away a decade+ of corporate knowledge of
> > working with svn and /usr/src. What is needed is a succinct
> > translation of the most common svn commands translated to git.
> >
> > Checking out /usr/src as u...@freebsd.org
> >
> > svn checkout svn+ssh://u...@svn.freebsd.org/base/head /usr/src
> >
> > git ...
> >
> > Checking out /usr/src without freebsd.org account
> >
> > svn checkout https://svn.freebsd.org/base/head
> > ${HOME}/freebsd/src
> >
> > git ...
> >
> > Creating diff against updated head.
> >
> > svn update
> > svn diff > patch.diff
> >
> > git ...
> >
> > Adding a new file
> >
> > svn add /usr/src/libm/msun/src/_s_sinpi.c
> >
> > git ...
> >
> > Committing a change to /usr/src
> >
> > svn update
> > svn diff | more (everyone does one last check,
> > right?)
> > svn commit
> >
> > git ...
> >
>
> This is an insultingly stupid comment to make. We don't need people
> to say
> the obvious.
>
> This sort of comment isn't helpful. People will just ignore you if
> you make
> too many of them like it.
>
Seriously, Warner?
I applaud Steve's message as being the first one in this thread that
has any real value at all. Unlike everyone else, he has clearly seen
what the basic problem is (zero communications about this impending
cutover to the people who need to work with it every day), and he
summarized it in a completely practical way.
This assumption that everyone knows how to use git is mind-boggling. I
think I installed it once, a few years ago. Then I uninstalled it
because of how abysmally hard it was to try to learn even a few
commands to do anything with it.
I guess Steve & I are a couple dinosaurs and the whole rest of the
freebsd user and committer community is laughing at our ignorance and
thinking "we don't need their contributions anyway, so let's just mock
them and move on."
-- Ian
___
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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 02, 2020 at 11:11:50AM -0600, Warner Losh wrote: > On Wed, Sep 2, 2020 at 10:47 AM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > This is an insultingly stupid comment to make. We don't need people to say > the obvious. > > This sort of comment isn't helpful. People will just ignore you if you make > too many of them like it. > I don't find it insulting at all. I have 15+ years experience using svn with both GCC and FreeBSD repositories. GCC changed from svn and git with little regard to its impact on developers (except for those pushing the move to git). gfortran has lost one of its most active bug fixer/contributors because he knows 0 about git. By extension FreeBSD lost one of the few users that actually tried to ensure GCC works on FreeBSD (hopefully, people don't use g++'s complex math without testing!). -- Steve ___ 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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 2, 2020, at 2:36 PM, Ian Lepore wrote: > Seriously, Warner? Yes, seriously. We are adults. Act accordingly. Don't be confused. I also thought the message he was replying to was out of line. > I applaud Steve's message as being the first one in this thread that > has any real value at all. Unlike everyone else, he has clearly seen > what the basic problem is (zero communications about this impending > cutover to the people who need to work with it every day), and he > summarized it in a completely practical way. We disagree. The message could have been worded without being negative. > This assumption that everyone knows how to use git is mind-boggling. I > think I installed it once, a few years ago. Then I uninstalled it > because of how abysmally hard it was to try to learn even a few > commands to do anything with it. No, it's assumed you will learn. I did. We all can. Please, we cooperate on this project. We don't attack, and yes, these were attacks. > I guess Steve & I are a couple dinosaurs and the whole rest of the > freebsd user and committer community is laughing at our ignorance and > thinking "we don't need their contributions anyway, so let's just mock > them and move on." I don't think so. I'm guessing I'm older and more set in my ways. There are much better ways to communicate that in recent messages. -- Dan Langille d...@langille.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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 2, 2020 at 12:36 PM Ian Lepore wrote:
> On Wed, 2020-09-02 at 11:11 -0600, Warner Losh wrote:
> > On Wed, Sep 2, 2020 at 10:47 AM Steve Kargl <
> > s...@troutmask.apl.washington.edu> wrote:
> >
> > > On Wed, Sep 02, 2020 at 12:14:08PM -0400, Ed Maste wrote:
> > > > On Wed, 2 Sep 2020 at 02:31, Steve Kargl
> > > > wrote:
> > > > >
> > > > > > A short intro on git for svn users:
> > > > > > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view
> > > > > >
> > > > >
> > > > > ROTFL. From the "short intro", 2nd sentence.
> > > > >
> > > > > New committers are assumed to already be familiar with the
> > > > > basic
> > > > > operation of Git. If not, start by reading the Git Book.
> > > >
> > > > This doc started as a direct translation of the Subversion
> > > > primer,
> > > > which has as its first sentence:
> > > > > New committers are assumed to already be familiar with the
> > > > > basic
> > >
> > > operation of Subversion. If not, start by reading the Subversion
> > > Book.
> > > >
> > > > As with the Subversion primer the doc is intended to provide a
> > > > quick
> > > > reference for day-to-day commands, but not act as a reference or
> > > > introduction to the entire theory of operation of the associated
> > > > VCS.
> > >
> > > Like GCC, which did the svn to git dance at start of the year,
> > > FreeBSD is throwing away a decade+ of corporate knowledge of
> > > working with svn and /usr/src. What is needed is a succinct
> > > translation of the most common svn commands translated to git.
> > >
> > > Checking out /usr/src as u...@freebsd.org
> > >
> > > svn checkout svn+ssh://u...@svn.freebsd.org/base/head /usr/src
> > >
> > > git ...
> > >
> > > Checking out /usr/src without freebsd.org account
> > >
> > > svn checkout https://svn.freebsd.org/base/head
> > > ${HOME}/freebsd/src
> > >
> > > git ...
> > >
> > > Creating diff against updated head.
> > >
> > > svn update
> > > svn diff > patch.diff
> > >
> > > git ...
> > >
> > > Adding a new file
> > >
> > > svn add /usr/src/libm/msun/src/_s_sinpi.c
> > >
> > > git ...
> > >
> > > Committing a change to /usr/src
> > >
> > > svn update
> > > svn diff | more (everyone does one last check,
> > > right?)
> > > svn commit
> > >
> > > git ...
> > >
> >
> > This is an insultingly stupid comment to make. We don't need people
> > to say
> > the obvious.
> >
> > This sort of comment isn't helpful. People will just ignore you if
> > you make
> > too many of them like it.
> >
>
> Seriously, Warner?
>
> I applaud Steve's message as being the first one in this thread that
> has any real value at all. Unlike everyone else, he has clearly seen
> what the basic problem is (zero communications about this impending
> cutover to the people who need to work with it every day), and he
> summarized it in a completely practical way.
>
> This assumption that everyone knows how to use git is mind-boggling. I
> think I installed it once, a few years ago. Then I uninstalled it
> because of how abysmally hard it was to try to learn even a few
> commands to do anything with it.
>
> I guess Steve & I are a couple dinosaurs and the whole rest of the
> freebsd user and committer community is laughing at our ignorance and
> thinking "we don't need their contributions anyway, so let's just mock
> them and move on."
>
I'm just extra grumpy today.
First, the doc has what Steve requested already, so the high level
snarkiness isn't helpful.
Second, the doc isn't done, but there was no feedback on where in the doc
it isn't clear, so the message isn't helpful.
Third, you're reading too much into the first paragraph, which was copied
verbatim from the current guide.
That's what lead to my outburst.
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: Plans for git (was: Please check the current beta git conversions)
On Wed, 2020-09-02 at 14:45 -0400, Dan Langille wrote: > On Wed, Sep 2, 2020, at 2:36 PM, Ian Lepore wrote: > > > Seriously, Warner? > > Yes, seriously. We are adults. Act accordingly. > > Don't be confused. I also thought the message he was replying to was out of > line. > > > I applaud Steve's message as being the first one in this thread that > > has any real value at all. Unlike everyone else, he has clearly seen > > what the basic problem is (zero communications about this impending > > cutover to the people who need to work with it every day), and he > > summarized it in a completely practical way. > > We disagree. The message could have been worded without being negative. > > > This assumption that everyone knows how to use git is mind-boggling. I > > think I installed it once, a few years ago. Then I uninstalled it > > because of how abysmally hard it was to try to learn even a few > > commands to do anything with it. > > No, it's assumed you will learn. I did. We all can. > > Please, we cooperate on this project. We don't attack, and yes, these were > attacks. > > > I guess Steve & I are a couple dinosaurs and the whole rest of the > > freebsd user and committer community is laughing at our ignorance and > > thinking "we don't need their contributions anyway, so let's just mock > > them and move on." > > I don't think so. I'm guessing I'm older and more set in my ways. > > There are much better ways to communicate that in recent messages. > How typical: trim away ALL context of what's being discussed, then claim that the material was offensive in some way after destroying the contextual evidence that makes a lie of your claim. -- Ian ___ 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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 2, 2020 at 12:46 PM Dan Langille wrote: > On Wed, Sep 2, 2020, at 2:36 PM, Ian Lepore wrote: > > > Seriously, Warner? > > Yes, seriously. We are adults. Act accordingly. > I agree it was over the top. > Don't be confused. I also thought the message he was replying to was out > of line. > > > I applaud Steve's message as being the first one in this thread that > > has any real value at all. Unlike everyone else, he has clearly seen > > what the basic problem is (zero communications about this impending > > cutover to the people who need to work with it every day), and he > > summarized it in a completely practical way. > > We disagree. The message could have been worded without being negative. > It could have been worded in a way that was actionable. > > This assumption that everyone knows how to use git is mind-boggling. I > > think I installed it once, a few years ago. Then I uninstalled it > > because of how abysmally hard it was to try to learn even a few > > commands to do anything with it. > > No, it's assumed you will learn. I did. We all can. > > Please, we cooperate on this project. We don't attack, and yes, these were > attacks. > > > I guess Steve & I are a couple dinosaurs and the whole rest of the > > freebsd user and committer community is laughing at our ignorance and > > thinking "we don't need their contributions anyway, so let's just mock > > them and move on." > > I don't think so. I'm guessing I'm older and more set in my ways. > > There are much better ways to communicate that in recent messages. > I agree. I apologize for my outburst. Just frustrated. 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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 2, 2020, at 2:50 PM, Ian Lepore wrote: > On Wed, 2020-09-02 at 14:45 -0400, Dan Langille wrote: > > On Wed, Sep 2, 2020, at 2:36 PM, Ian Lepore wrote: > > > > > Seriously, Warner? > > > > Yes, seriously. We are adults. Act accordingly. > > > > Don't be confused. I also thought the message he was replying to was out of > > line. > > > > > I applaud Steve's message as being the first one in this thread that > > > has any real value at all. Unlike everyone else, he has clearly seen > > > what the basic problem is (zero communications about this impending > > > cutover to the people who need to work with it every day), and he > > > summarized it in a completely practical way. > > > > We disagree. The message could have been worded without being negative. > > > > > This assumption that everyone knows how to use git is mind-boggling. I > > > think I installed it once, a few years ago. Then I uninstalled it > > > because of how abysmally hard it was to try to learn even a few > > > commands to do anything with it. > > > > No, it's assumed you will learn. I did. We all can. > > > > Please, we cooperate on this project. We don't attack, and yes, these were > > attacks. > > > > > I guess Steve & I are a couple dinosaurs and the whole rest of the > > > freebsd user and committer community is laughing at our ignorance and > > > thinking "we don't need their contributions anyway, so let's just mock > > > them and move on." > > > > I don't think so. I'm guessing I'm older and more set in my ways. > > > > There are much better ways to communicate that in recent messages. > > > > How typical: trim away ALL context of what's being discussed, then > claim that the material was offensive in some way after destroying the > contextual evidence that makes a lie of your claim. I apologize for the excessive trimming. I regret posting, but still persist in my call for improved methods. Umm, as for the rest... I don't know how to reply to that. -- Dan Langille d...@langille.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: Plans for git (was: Please check the current beta git conversions)
resending, because I clearly have no clue. On Wed, Sep 2, 2020, at 2:50 PM, Ian Lepore wrote: > On Wed, 2020-09-02 at 14:45 -0400, Dan Langille wrote: > > On Wed, Sep 2, 2020, at 2:36 PM, Ian Lepore wrote: > > > > > Seriously, Warner? > > > > Yes, seriously. We are adults. Act accordingly. > > > > Don't be confused. I also thought the message he was replying to was out of > > line. > > > > > I applaud Steve's message as being the first one in this thread that > > > has any real value at all. Unlike everyone else, he has clearly seen > > > what the basic problem is (zero communications about this impending > > > cutover to the people who need to work with it every day), and he > > > summarized it in a completely practical way. > > > > We disagree. The message could have been worded without being negative. > > > > > This assumption that everyone knows how to use git is mind-boggling. I > > > think I installed it once, a few years ago. Then I uninstalled it > > > because of how abysmally hard it was to try to learn even a few > > > commands to do anything with it. > > > > No, it's assumed you will learn. I did. We all can. > > > > Please, we cooperate on this project. We don't attack, and yes, these were > > attacks. > > > > > I guess Steve & I are a couple dinosaurs and the whole rest of the > > > freebsd user and committer community is laughing at our ignorance and > > > thinking "we don't need their contributions anyway, so let's just mock > > > them and move on." > > > > I don't think so. I'm guessing I'm older and more set in my ways. > > > > There are much better ways to communicate that in recent messages. > > > > How typical: trim away ALL context of what's being discussed, then > claim that the material was offensive in some way after destroying the > contextual evidence that makes a lie of your claim. I apologize for the excessive trimming. I regret posting, but still persist in my call for improved methods. Umm, as for the rest... I don't know how to reply to that. -- Dan Langille d...@langille.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: Please check the current beta git conversions
On Wed, 2020-09-02 at 15:16:38 +0200, Olivier Certner wrote: > Hi, > > > > 2.5 GB in .git directory sounds crazy and incomprehensible to me. > > > > 2.5GB is for the full history, if you only care about the main branch, > > you can clone with: > > > > (snip) > > I do not reproduce this, but instead see `du` reporting 1.2GiB just after a > simple clone (no options), which AFAIK contains the whole history. That's correct, the repo size for src should be well under 2.0GiB but could be larger locally if you still have unused refs as can still happen with the conversion producing different commit hashes every once in a while. doc should be less than 500M and ports also under the 2GiB mark. It all depends a bit on how good the repo was repacked, so I can only give ballpark figures. Cheers Uli ___ 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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 02, 2020 at 01:38:09PM -0400, Theron wrote: > After the transition, will FreeBSD base contain the tool for the cloning the > FreeBSD repository (not one of the mirrors?) Just to throw it out there, https://gameoftrees.org/ would be interesting to explore for this. -- Mason Loring Blissma...@blisses.org They also surf, who only stand on waves. signature.asc Description: PGP signature
Re: Plans for git (was: Please check the current beta git conversions)
> Am 02.09.2020 um 18:22 schrieb Warner Losh : > > > >> On Sep 2, 2020, at 10:14 AM, Ed Maste wrote: >> >> On Wed, 2 Sep 2020 at 02:31, Steve Kargl >> wrote: >>> A short intro on git for svn users: https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view >>> >>> ROTFL. From the "short intro", 2nd sentence. >>> >>> New committers are assumed to already be familiar with the basic >>> operation of Git. If not, start by reading the Git Book. >> >> This doc started as a direct translation of the Subversion primer, >> which has as its first sentence: >>> New committers are assumed to already be familiar with the basic operation >>> of Subversion. If not, start by reading the Subversion Book. >> >> As with the Subversion primer the doc is intended to provide a quick >> reference for day-to-day commands, but not act as a reference or >> introduction to the entire theory of operation of the associated VCS. > > The rest of the guide walks people through how to do the job, but without all > the theory for the basics. > > Again it needs some work for the advanced topic it currently just omits… > Sorry, but I had to think of this: https://xkcd.com/1597/ The project was announced a while back in the quarterly status report (that’s the first time I read about it at least). It’s obviously a huge undertaking, the people taking part in it should be commended, not ridiculed (IMO). For people who don’t have much exposure to git, it can be very obnoxious. Though these days, a lot of people assume git=github and the GUI there certainly makes things easier. If it wasn’t completely riddled with security-holes, I would recommend the project to run its own gitlab instance - but for a project this size, you’d be looking at a FTE just herding that bag of cats and constantly upgrading it… ___ 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: Plans for git
On 2-9-2020 21:24, Rainer Duffner wrote: Am 02.09.2020 um 18:22 schrieb Warner Losh : On Sep 2, 2020, at 10:14 AM, Ed Maste wrote: On Wed, 2 Sep 2020 at 02:31, Steve Kargl wrote: A short intro on git for svn users: https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view ROTFL. From the "short intro", 2nd sentence. New committers are assumed to already be familiar with the basic operation of Git. If not, start by reading the Git Book. This doc started as a direct translation of the Subversion primer, which has as its first sentence: New committers are assumed to already be familiar with the basic operation of Subversion. If not, start by reading the Subversion Book. As with the Subversion primer the doc is intended to provide a quick reference for day-to-day commands, but not act as a reference or introduction to the entire theory of operation of the associated VCS. The rest of the guide walks people through how to do the job, but without all the theory for the basics. Again it needs some work for the advanced topic it currently just omits… Sorry, but I had to think of this: https://xkcd.com/1597/ The project was announced a while back in the quarterly status report (that’s the first time I read about it at least). It’s obviously a huge undertaking, the people taking part in it should be commended, not ridiculed (IMO). For people who don’t have much exposure to git, it can be very obnoxious. Though these days, a lot of people assume git=github and the GUI there certainly makes things easier. If it wasn’t completely riddled with security-holes, I would recommend the project to run its own gitlab instance - but for a project this size, you’d be looking at a FTE just herding that bag of cats and constantly upgrading it… I was thrown in the deep when I started the Ceph-FreeBSD port, and it certainly is no walk in the park. But then again every new tools has that problem. Git in itself is a tool like any other, some things are easier, some are hard to grasp. For me Git without Github (or any other reviewing environment) is only half the change, so I'm wondering where code review will take place. But then perhaps I should read the document. Pushing PRs has sort of grown on me over time. --WjW ___ 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 Wed, Sep 02, 2020 at 08:30:28AM +, Thomas Mueller wrote: > NetBSD plans to switch from cvs to Mercurial. So ... from square wheels, to triangular ones??? mcl ___ 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: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 02, 2020 at 08:01:17AM +0200, Kurt Jaeger wrote: > A short intro on git for svn users: > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view For people like me that will not click on random URLs ... ... just feed "svn to git cheat-sheet" to your favorite search engine. Disclaimer: my initial experience with the Github UI has been a disaster. mcl ___ 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"
[openzfs] r365058 arm64 uefi boot fails with "unknown filesystem" after launching kernel
hi Matt, Ryan Something goes awry after loading kernel & zfs drivers, at point of mounting the root filesystem from boot env - unknown filesystem. Running ? to show available fs doesn't show zfs here, but as we loaded kernel already from zfs this is confusing. Any ideas? mountroot> ? List of GEOM managed disk devices: da1 ufs/FreeBSD_Install ufsid/5f3524aa78541663 da0s2 da0p1 da0 gpt/zfs0 gpt/swap0 msdosfs/EFISYS gpt/efiboot0 ada0p3 ada0p2 ada0p1 ada0 Additionally at this point, it doesn't appear to be possible to boot/mount from the previous boot environment, as zfs.ko etc is already loaded, I'm not sure if I can set this prior with `loaddev` or similar. full dmesg/logs here - https://dpaste.org/iwRd , trimmed below. svn path=/head/; revision=365058 , commit 52a2c0f Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk1p1: FreeBSD/arm64 EFI loader, Revision 1.1 Command line arguments: loader.efi Image base: 0x9fe6d3 EFI version: 2.70 EFI Firmware: American Megatrends (rev 5.13) Console: efi (0x2000) Load Path: \EFI\FreeBSD\loader.efi Load Device: PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(1,GPT,BE9634BF-D684-11EA-B300-001B21E07D7B,0x28,0x64000) BootCurrent: 0001 BootOrder: 0001[*] 0004 001b 001f 001a 000e 0003 0005 0006 0007 001c 001d 001e BootInfo Path: HD(1,GPT,BE9634BF-D684-11EA-B300-001B21E07D7B,0x28,0x64000)/\EFI\refind\refind_aa64.efi Ignoring Boot0001: Only one DP found Trying ESP: PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(1,GPT,BE9634BF-D684-11EA-B300-001B21E07D7B,0x28,0x64000) Setting currdev to disk1p1: Trying: PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(2,GPT,BE9A1581-D684-11EA-B300-001B21E07D7B,0x64800,0x280) Setting currdev to disk1p2: Trying: PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(3,GPT,BEA23FFC-D684-11EA-B300-001B21E07D7B,0x2864800,0x355DE800) Setting currdev to zfs:zroot/ROOT/13.0-CURRENT-20200901.193810: Loading /boot/defaults/loader.conf Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local Loading kernel... /boot/kernel/kernel text=0x2a8 text=0x70 text=0x1e7a6c data=0x196b80 data=0x0+0x3a378e syms=[0x8+0x165978+0x8+0x158936] Loading configured modules... /boot/kernel/tmpfs.ko text=0x4421 text=0x8fec data=0x1110+0x18 syms=[0x8+0x1f68+0x8+0x13df] /boot/kernel/xz.ko text=0x850 text=0x22d0 data=0x268+0x400 syms=[0x8+0x870+0x8+0x412] /boot/kernel/linuxkpi.ko text=0x709d text=0x13070 data=0x1970+0x750 syms=[0x8+0x5a48+0x8+0x3dfb] /boot/entropy size=0x1000 /etc/hostid size=0x25 /boot/kernel/mlx5en.ko text=0x19b35 text=0x11a48 data=0x26d8+0x8 syms=[0x8+0x32e8+0x8+0x21ae] /boot/kernel/mlx5.ko text=0xc369 text=0x23e24 data=0x1b50+0x94 syms=[0x8+0x5100+0x8+0x3c65] /boot/kernel/fusefs.ko text=0x8236 text=0xcb48 data=0x3420+0x68 syms=[0x8+0x4350+0x8+0x4894] /boot/kernel/opensolaris.ko text=0x12c3 text=0x94c data=0x468+0x6830 syms=[0x8+0x1050+0x8+0x8bb] /boot/kernel/mlxfw.ko text=0xed2 text=0x167c data=0x258 syms=[0x8+0x750+0x8+0x409] /boot/kernel/zfs.ko text=0xa3e88 text=0x1c8828 data=0x25908+0x158990 syms=[0x8+0x2fa48+0x8+0x29ff3] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! EFI framebuffer information: addr, size 0x43000, 0x1d4c00 dimensions 800 x 600 stride 800 masks 0x00ff, 0xff00, 0x00ff, 0xff00 ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT r365058+d8f4c1a833bf-c271116(master) GENERIC arm64 FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.0-rc1-47-gff47911ddfc) WARNING: WITNESS option enabled, expect reduced performance. VT(efifb): resolution 800x600 module firmware already present! KLD file zfs.ko is missing dependencies module_register: cannot register tmpfs from kernel; already loaded from tmpfs.ko Module tmpfs failed to register: 17 real memory = 137167400960 (130813 MB) avail memory = 133608034304 (127418 MB) FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs random: unblocking device. ... ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: Serial Number 191020FD543B ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 457862MB (937703088 512 byte sectors) ... sysctl_unregister_oid: failed(22) to unregister sysctl(tmpfs) Release APs...done Trying to mount root from zfs:zroot/ROOT/13.0-CURRENT-20200901.193810 []... Mounting from
Re: [openzfs] r365058 arm64 uefi boot fails with "unknown filesystem" after launching kernel
Load cryptodev manually from the loader to boot and then add cryptodev_load="YES" to your loader.conf. Regards, Navdeep On 9/2/20 1:58 PM, Dave Cottlehuber wrote: > hi Matt, Ryan > > Something goes awry after loading kernel & zfs drivers, at point of mounting > the root filesystem from boot env - unknown filesystem. > > Running ? to show available fs doesn't show zfs here, but as we loaded kernel > already from zfs this is confusing. > > Any ideas? > > mountroot> ? > List of GEOM managed disk devices: > da1 ufs/FreeBSD_Install ufsid/5f3524aa78541663 > da0s2 > da0p1 > da0 > gpt/zfs0 > gpt/swap0 > msdosfs/EFISYS > gpt/efiboot0 > ada0p3 > ada0p2 ada0p1 ada0 > > Additionally at this point, it doesn't appear to be possible to boot/mount > from the previous boot environment, as zfs.ko etc is already loaded, I'm not > sure if I can set this prior with `loaddev` or similar. > > full dmesg/logs here - https://dpaste.org/iwRd , trimmed below. > > svn path=/head/; revision=365058 , commit 52a2c0f > > Consoles: EFI console > Reading loader env vars from /efi/freebsd/loader.env > Setting currdev to disk1p1: > FreeBSD/arm64 EFI loader, Revision 1.1 > >Command line arguments: loader.efi >Image base: 0x9fe6d3 >EFI version: 2.70 >EFI Firmware: American Megatrends (rev 5.13) >Console: efi (0x2000) >Load Path: \EFI\FreeBSD\loader.efi >Load Device: > PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(1,GPT,BE9634BF-D684-11EA-B300-001B21E07D7B,0x28,0x64000) >BootCurrent: 0001 >BootOrder: 0001[*] 0004 001b 001f 001a 000e 0003 0005 0006 0007 001c > 001d 001e >BootInfo Path: > HD(1,GPT,BE9634BF-D684-11EA-B300-001B21E07D7B,0x28,0x64000)/\EFI\refind\refind_aa64.efi > Ignoring Boot0001: Only one DP found > Trying ESP: > PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(1,GPT,BE9634BF-D684-11EA-B300-001B21E07D7B,0x28,0x64000) > Setting currdev to disk1p1: > Trying: > PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(2,GPT,BE9A1581-D684-11EA-B300-001B21E07D7B,0x64800,0x280) > Setting currdev to disk1p2: > Trying: > PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(3,GPT,BEA23FFC-D684-11EA-B300-001B21E07D7B,0x2864800,0x355DE800) > Setting currdev to zfs:zroot/ROOT/13.0-CURRENT-20200901.193810: > Loading /boot/defaults/loader.conf > Loading /boot/defaults/loader.conf > Loading /boot/device.hints > Loading /boot/loader.conf > Loading /boot/loader.conf.local > Loading kernel... > /boot/kernel/kernel text=0x2a8 text=0x70 text=0x1e7a6c data=0x196b80 > data=0x0+0x3a378e syms=[0x8+0x165978+0x8+0x158936] > Loading configured modules... > /boot/kernel/tmpfs.ko text=0x4421 text=0x8fec data=0x1110+0x18 > syms=[0x8+0x1f68+0x8+0x13df] > /boot/kernel/xz.ko text=0x850 text=0x22d0 data=0x268+0x400 > syms=[0x8+0x870+0x8+0x412] > /boot/kernel/linuxkpi.ko text=0x709d text=0x13070 data=0x1970+0x750 > syms=[0x8+0x5a48+0x8+0x3dfb] > /boot/entropy size=0x1000 > /etc/hostid size=0x25 > /boot/kernel/mlx5en.ko text=0x19b35 text=0x11a48 data=0x26d8+0x8 > syms=[0x8+0x32e8+0x8+0x21ae] > /boot/kernel/mlx5.ko text=0xc369 text=0x23e24 data=0x1b50+0x94 > syms=[0x8+0x5100+0x8+0x3c65] > /boot/kernel/fusefs.ko text=0x8236 text=0xcb48 data=0x3420+0x68 > syms=[0x8+0x4350+0x8+0x4894] > /boot/kernel/opensolaris.ko text=0x12c3 text=0x94c data=0x468+0x6830 > syms=[0x8+0x1050+0x8+0x8bb] > /boot/kernel/mlxfw.ko text=0xed2 text=0x167c data=0x258 > syms=[0x8+0x750+0x8+0x409] > /boot/kernel/zfs.ko text=0xa3e88 text=0x1c8828 data=0x25908+0x158990 > syms=[0x8+0x2fa48+0x8+0x29ff3] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > No valid device tree blob found! > WARNING! Trying to fire up the kernel, but no device tree blob found! > EFI framebuffer information: > addr, size 0x43000, 0x1d4c00 > dimensions 800 x 600 > stride 800 > masks 0x00ff, 0xff00, 0x00ff, 0xff00 > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2020 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT r365058+d8f4c1a833bf-c271116(master) GENERIC arm64 > FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git > llvmorg-11.0.0-rc1-47-gff47911ddfc) > WARNING: WITNESS option enabled, expect reduced performance. > VT(efifb): resolution 800x600 > module firmware already present! > KLD file zfs.ko is missing dependencies > module_register: cannot register tmpfs from kernel; already loaded from > tmpfs.ko > Module tmpfs failed to register: 17 > real memory = 137167400960 (130813 MB) > avail memory = 133608034304 (127418 MB) > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > random: unblocking device. > ... > ada0 at ahcich0
Re: Plans for git (was: Please check the current beta git conversions)
On Wed, Sep 02, 2020 at 09:47:06AM -0700, Steve Kargl wrote:
> Checking out /usr/src as u...@freebsd.org
>
> svn checkout svn+ssh://u...@svn.freebsd.org/base/head /usr/src
git checkout ssh://u...@git.freebsd.org/base/head /usr/src
> Checking out /usr/src without freebsd.org account
>
> svn checkout https://svn.freebsd.org/base/head ${HOME}/freebsd/src
git checkout https://git.freebsd.org/base/head ${HOME}/freebsd/src
> Creating diff against updated head.
>
> svn update
> svn diff > patch.diff
git pull
git diff >patch.diff
> Adding a new file
>
> svn add /usr/src/libm/msun/src/_s_sinpi.c
git add /usr/src/libm/msun/src/_s_sinpi.c
> Committing a change to /usr/src
>
> svn update
> svn diff | more (everyone does one last check, right?)
> svn commit
git pull
git add -A # add all files, even new ones
# alternative would be "git add "
git diff --cached
git commit
I "assumed" that u...@git.freebsd.org is valid, but depending on
configuration of the server, g...@git.freebsd.org might be the right one.
Someone with actual knowledge (and I'm looking at Ed) will fill in the
right details.
If needed for any doc/example/howto, feel free to copy these examples
where suites best FreeBSD project/developers or tell me what to edit.
Regards,
meka
signature.asc
Description: PGP signature
Re: Please check the current beta git conversions
Ed Maste wrote in : I tried simply updating my github clone by switching url = https://cgit-beta.freebsd.org/src.git #url = https://github.com/freebsd/freebsd.git and whereas ls-remote worked fine fetch -v --dry-run aborted as well as normal fetch, after dumping dozens of POSTs POST git-upload-pack (gzip 1472 to 804 bytes) ... POST git-upload-pack (gzip 976722 to 483608 bytes) POST git-upload-pack (chunked) error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 fatal: the remote end hung up unexpectedly Maybe clone from scratch instead, but mysterious it is? Good night, and Ciao from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ 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: Strange USB loop
On Thu, Aug 27, 2020 at 10:02:21AM -0700, bob prohaska wrote: > On Tue, Aug 25, 2020 at 11:29:16AM -0700, bob prohaska wrote: > > > With a _different_ FT232 plugged in it also came up normally. > > > > Both are thought to be genuine, but they are of different age > > and produce different recognition messages: > > > > The FT232 that causes trouble reports > > ugen1.4: at usbus1 > > uftdi0 on uhub1 > > uftdi0: on usbus1 > > > > The one that seems to work is newer and reports > > ugen1.4: at usbus1 > > uftdi0 on uhub1 > > uftdi0: on usbus1 > > With the system updated to r364900 both FT232 devices seem to be working. The machine boots from a USB disk successfully with mouse, keyboard and FT232 connected at powerup. Thanks for your help, bob prohaska ___ 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"
Where's the fingerprints and sigs? (was: Please check the current beta git conversions)
On 9/1/20, Shawn Webb wrote: > 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. A bit moot when such key materials of all services, and repos, and ticketing, and reviews, and builds, and downloads, and packages, forums, and git hashtree initialization first hashes, and pubkey modulus not just the larger DER's by untrusted/attacking CA's, etc... are all not sha-256 fingerprint signed and attested to in a base included textfile, in repo and on website, etc by security officer keys having good WoT... for users to reference, import, validate, pin down, etc. And tools for accessing such services often not have fingerprint pinning options. Woes be to those using such untrustable massively MITM'd and spied upon networks as the Internet, Workplace, Home, Travel, VPN, WiFi, Tor Exits, etc not having any way to authenticate fingerprints and pin such services back to their favorite OS project's security apostille office yet. Security vaunted OpenBSD still serves up via cleartext non-hashtree anoncvs on non-ecc harware on non-zfs-skein filesystems etc... So the BSD world must still be thought secure, bit integral, and trustably accessible without any of these infrastructure tool fingerprint sig and pin basics... still no need to supply them since decades since TLS/SSH/etc were deployed... Right? Not. Cheers all :) [Same for Linux ;] ___ 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: 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 For those interested, additional topical from same site... https://github.com/bk2204/git/tree/transition-stage-4 https://lwn.net/Articles/823352/ Updating the Git protocol for SHA-256 https://lwn.net/Articles/811068/ A new hash algorithm for Git https://lwn.net/Articles/715716/ Moving Git past SHA-1 https://lwn.net/Articles/813646/ Attestation for kernel patches https://lwn.net/Articles/821367/ Merkle trees and build systems https://lwn.net/Articles/663875/ Changes in the TLS certificate ecosystem, part 1 https://lwn.net/Articles/468911/ Sovereign Keys for certificate verification https://lwn.net/Articles/652580/ Decentralization for the web ___ 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: [openzfs] r365058 arm64 uefi boot fails with "unknown filesystem" after launching kernel
On Wed, 2 Sep 2020, at 21:01, Navdeep Parhar wrote: > Load cryptodev manually from the loader to boot and then add > cryptodev_load="YES" to your loader.conf. Hi Navdeep that was it - thanks! crisis averted. A+ Dave — O for a muse of fire, that would ascend the brightest heaven of invention! ___ 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: Plans for git
Willem Jan Withagen wjw at digiware.nl wrote on Wed Sep 2 19:50:35 UTC 2020 : > For me Git without Github (or any other reviewing environment) is only > half the change, so I'm wondering where code review will take place. When I look at the likes of, say, https://cgit-beta.freebsd.org/src/log/ and see content in columns for: Commit message (Expand) Author Age Files Lines and see lines like: Fix a buffer overrun. John Baldwin 31 hours1 -3/+3 it gives me no clue where/what-area in the tree had changes that provided such a fix. (It is just an example of many where I find a subsystem context unable to be readily identified.) A https://cgit-beta.freebsd.org/src/ (summary) example is: Age Commit message Author Files Lines 12 hoursFix build fallout after r365054 . Hans Petter Selasky 1 -1/+1 I used to (still) monitor via the likes of: https://lists.freebsd.org/pipermail/svn-src-head/2020-September/thread.html Seeing things like "svn commit: r365039 - head/sys/arm64/arm64" was useful for how I used to monitor: a lot I could ignore based on the subsystem involved and selectively look at the ones of potential interest. Is there going to be some rough equivalent to the pipermail/svn-src-head/*-*/* list with identifications analogous to head/sys/arm64/arm64 ? (Something that can be browsed and easily allows selectively looking at specific commits.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: [openzfs] r365058 arm64 uefi boot fails with "unknown filesystem" after launching kernel
On 03/09/2020 00:01, Navdeep Parhar wrote: > Load cryptodev manually from the loader to boot and then add > cryptodev_load="YES" to your loader.conf. I think that this shouldn't be needed *if* zfs module has a dependency on cryptodev module (MODULE_DEPEND in the code). The loader knows how to load dependencies. -- Andriy Gapon ___ 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"
