Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[grarpamp]

> We do have most of the keys in docs/share/pgpkeys/ plus history.

https://git.kernel.org/pub/scm/docs/kernel/ksmap
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys
___
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"

MII media status race condition causing fictitious link down

[Ali Abdallah]

Hello,

As I've sent a couple of patches to add support for Thinkpad USB-C gen2
to if_ure(4), I came across a very strange link random state change,
causing dhclient to think the link went effectively down, which is not
the case.

First I thought that if_ure(4) doesn't play well with the new chip of the
dock, but after lot of debugging, it turns out to be a nasty race
condition in mii bus code [1].

I'm sending this mail to raise awareness about this issue. Apparently it
exists since long time (I even remember having had this issue in the
past on my older Thinkpad).

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165

Regards,

-- 
Ali Abdallah | SUSE L3 Engineer
GPG fingerprint: 51A0 F4A0 C8CF C98F 842E  A9A8 B945 56F8 1C85 D0D5

___
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: src: continued use of Subversion for getting updates

[Steffen Nurpmeso]

Hello.

Ulrich Spörlein wrote in
 :
 |On Sat, 2020-12-26 at 02:55:30 +0100, Steffen Nurpmeso wrote:
 |>Warner Losh wrote in
 |> :
 |>|On Fri, Dec 25, 2020 at 3:25 PM Steffen Nurpmeso  \
 |>|wrote:
 |>|> Warner Losh wrote in
 |>|>  :
 |>|>|> On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso 
 |>|>|> wrote:
 |>|>|>> Ulrich Spörlein wrote in
 |>|>|>>  :
 |>|>|>>|On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
 |> ...
 |>|>|>>|>I really dislike that vendor imports have been tagged.  Because
 |> ...
 |>|>|>>|That's basically what was done? I don't understand what you're \
 |>|>|>>|saying
 |>|>|>>|here ...
 |>|>|>> Well, cgit-beta did not have had all these tags if i recall
 |> ...
 |>|>|> It had them, but not under the refs/head/vendor space but under the
 |>|>|> refs/vendor space.
 |>|>
 |>|> These are not tags but branches.  I have nothing against the
 |> ...
 |>|>|> They did exist. They were under refs/vendor rather than
 |>|> refs/head/vendor
 |>|>|> though.
 |>|>
 |>|> Under refs/tags/vendor?  refs/tags/ is the "special" namespace
 |>|> managed by "git tag", this is different than the rest.
 |> ...
 |>|>|>> there is
 |>|>|>>
 |>|>|>>   #?0|kent:free-src.git$ git sr|wc -l
 |>|>|>>   2137
 |>|>|>>
 |>|>|>> but if i go for "the real" FreeBSD itself it is just
 |>|>|>>
 |>|>|>>   #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
 |>|>|>>   19
 |>|>|>
 |>|>|You might be happier tracking on github, once we start pushing there as
 |>|> the
 |>|>|vendor branches won't be published there.
 |>|>
 |>|> No problem with any number of branches, Warner.  Just tags under
 |>|> refs/tags this is above.
 |>|
 |>|They were tags in the cgit-beta as well (and a few branches). I don't
 |>|believe that detail changed, but my old copies of the repo are gone.
 |>
 |>Yes mine is gone, for a month.  Then i am sorry that i did not
 |>speak out by then.
 |
 |They were annotated tags, git doesn't care where you actually store 
 |them. Yes, refs/tags/ is special but more in terms of automatically 
 |pulling them down, not in whether that has commit objects or tag 
 |objects.

I know that.  The git maintainer is prowd of being able to use
neat tricks like storing the OpenPGP key in the repo like that.
_I_ was only talking about refs/tags from the beginning, was i.

  ...
 |>|You may be happier running custom refs, or grab from github. The \
 |>|source of
 |>|truth has a lot of stuff. We may work to prune some of the vendor \
 |>|branches
 |>
 |>I am not interested in the entire repo, yes.  For almost a decade
 ...
 |You say you're not interested in the entire repo, but as soon as you 
 |fetch `main` or any of the stable branches you get the entire repo 
 |anyway. So I don't understand what you're talking about ...

:)  That depends on the project does it.  Just imagine NetBSD with
all of its topic branches and all the non-starters, and the
starters, the fully fledged regression tests etc etc etc, a real
fan or project mentor etc wants to have it all, but to me this is
useless.  I would consider also tracking the doc branch.

Interesting would be how many savings can be achieved by storing
it all in one repository, source, tests, doc, etc etc.
The Plan9 people with their fossil/venti storage system did
measure that, and even though they used all that image, sound and
video media the curve of newly created storag€ blocks (of unique
hashes) became flatter and flatter over time.

  ...
 |>|>|>>|That's a valid point, we debated whether to keep vendor tags and
 |>|>|>> decided
 |>|>|>>|for now to replicate what we have in SVN. We can still delete \
 |>|>|>>|all the
 |>|>|>>|vendor tags on the main repo anytime we want ...
  ...
 |>|>|We need tags to keep track of what's been done, and to revert and do
 |>|> other
 |>|>|management things with vendor imports.
 |>|>
 |>|> But why?  You have the commit on a topic/vendor branch, and yppou
  ...
 |>|I'm not sure I follow. Unless I misunderstand, you are describing a
 |>|different problem with different issues.
 |>
 |>No, maybe i was mistaken.  I never did a vendor import myself.
 |>..But looking at the history i see lots of import disasters ;-))
 |>Look for example at llvm 10.x this year, it consumed three _tags_!
 |>
 |>I am luckily free to say that this is merde (without the intention
 |>to annoy the poor one who did it) and am going to talk.  I presume
 ...
 |>There should be a real per-vendor branch, say [vendor/sqlite].
 |>The way FreeBSD seems to do vendor imports this should even be
 |>easy, since vendor stuff is usually in separate directories.
 |>Create it once it is needed first, merge into main via --no-ff so
 |>that you get real "merge commits".  You can see the difference
 |>below.
 |
 |Umm, no offense but wtf are you talking about? I asked this earlier but 
 |you didn't reply to that part of the question. Of course the vendor 
 |branches are stand-alone vendor branches.
 |
 |% git log --reverse --compact-summary -n2 origin/vendor/sqlite3

  ...
 |% git ls-tree -r 

Re: src: continued use of Subversion for getting updates

[Graham Perrin]

On 23/12/2020 11:10, Thomas Mueller wrote:


… Will stable/11 and stable/12 be available by both git and svn? …



Yes; 
 
offers some detail.


___
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: src: continued use of Subversion for getting updates

[Ulrich Spörlein]

On Sat, 2020-12-26 at 02:55:30 +0100, Steffen Nurpmeso wrote:

Warner Losh wrote in
:
|On Fri, Dec 25, 2020 at 3:25 PM Steffen Nurpmeso  \
|wrote:
|> Warner Losh wrote in
|>  :
|>|> On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso 
|>|> wrote:
|>|>> Ulrich Spörlein wrote in
|>|>>  :
|>|>>|On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
...
|>|>>|>I really dislike that vendor imports have been tagged.  Because
...
|>|>>|That's basically what was done? I don't understand what you're saying
|>|>>|here ...
|>|>> Well, cgit-beta did not have had all these tags if i recall
...
|>|> It had them, but not under the refs/head/vendor space but under the
|>|> refs/vendor space.
|>
|> These are not tags but branches.  I have nothing against the
...
|>|> They did exist. They were under refs/vendor rather than
|> refs/head/vendor
|>|> though.
|>
|> Under refs/tags/vendor?  refs/tags/ is the "special" namespace
|> managed by "git tag", this is different than the rest.
...
|>|>> there is
|>|>>
|>|>>   #?0|kent:free-src.git$ git sr|wc -l
|>|>>   2137
|>|>>
|>|>> but if i go for "the real" FreeBSD itself it is just
|>|>>
|>|>>   #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
|>|>>   19
|>|>
|>|You might be happier tracking on github, once we start pushing there as
|> the
|>|vendor branches won't be published there.
|>
|> No problem with any number of branches, Warner.  Just tags under
|> refs/tags this is above.
|
|They were tags in the cgit-beta as well (and a few branches). I don't
|believe that detail changed, but my old copies of the repo are gone.

Yes mine is gone, for a month.  Then i am sorry that i did not
speak out by then.


They were annotated tags, git doesn't care where you actually store 
them. Yes, refs/tags/ is special but more in terms of automatically 
pulling them down, not in whether that has commit objects or tag 
objects.



 ...
|>|>> Which is a pity since all these references will be checked during
|>|>> "git fetch" unless i am mistaken.
|>|>
|>|Yes.  So far it's been doing it quite quickly for me, but I'm decently
|>|connected...
|>
|> Yes, terrible here, shared with many.
|
|You may be happier running custom refs, or grab from github. The source of
|truth has a lot of stuff. We may work to prune some of the vendor branches

I am not interested in the entire repo, yes.  For almost a decade
i had only the sources as such, without history, for me this is an
improvement.  As i am not a BSD developer it is for snooping
around only.  And when i report bugs they are not fixed, but i am
not alone with this.  Nonetheless: interest in FreeBSD here, ok.


You say you're not interested in the entire repo, but as soon as you 
fetch `main` or any of the stable branches you get the entire repo 
anyway. So I don't understand what you're talking about ...




|into their own repos in the future, but today there's a lot of stuff that's
|there, some of which is for the convenience of the developer and you may
|need to trim (at least in the short term).

|  ...
|>|>>|That's a valid point, we debated whether to keep vendor tags and
|>|>> decided
|>|>>|for now to replicate what we have in SVN. We can still delete all the
|>|>>|vendor tags on the main repo anytime we want ...
|>|>>
|>|>> I personally would track that in the commit message of the import
|>|>> on the vendor branch that anyway exists(!), and then when merging
|>|>> this into the mainline, but not create a real tag in the tag
|>|>> namespace.  Also the backups/ and such, because why?
|>|>
|>|We need tags to keep track of what's been done, and to revert and do
|> other
|>|management things with vendor imports.
|>
|> But why?  You have the commit on a topic/vendor branch, and yppou
|> revert nothing but the commit.  In fact doing so messes the tag,p
|> it has to be retagged when you do re-commit an import proper,
|> which requires a forced push even!
|
|I'm not sure I follow. Unless I misunderstand, you are describing a
|different problem with different issues.

No, maybe i was mistaken.  I never did a vendor import myself.
..But looking at the history i see lots of import disasters ;-))
Look for example at llvm 10.x this year, it consumed three _tags_!

I am luckily free to say that this is merde (without the intention
to annoy the poor one who did it) and am going to talk.  I presume
most of you can do git(1) better than i, i use it for a decade
(almost exactly in fact!), but have never stepped forward, and
have a very primitive way of daily use.

There should be a real per-vendor branch, say [vendor/sqlite].
The way FreeBSD seems to do vendor imports this should even be
easy, since vendor stuff is usually in separate directories.
Create it once it is needed first, merge into main via --no-ff so
that you get real "merge commits".  You can see the difference
below.


Umm, no offense but wtf are you talking about? I asked this earlier but 
you didn't reply to that part of the question. Of course the vendor 
branches are stand-alone 

Re: (251866) installers for FreeBSD fail to boot HP EliteBook 830 G7, ProBook 440 G7 …

[Ludovit Koren]

> Graham Perrin  writes:

> On 25/12/2020 13:40, Ludovit Koren wrote:
>> FreeBSD-13.0-CURRENT-amd64-20201224-3cc0c0d66a0-255241-memstick.img
>> still not working on HP EliteBook 830 G7.


> Thank you, is it still exactly as shown in the photograph below?

> 

Yes, exactly.

lk
___
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"