CURRENT, usr/src on git, howto "mergemaster"?

[Hartmann, O.]

Now, since /usr/src has been siwtched to git on several boxes and the former 
svn tag
$FreeBSD$ seem not valid/useful anymore, how am I (or any other here) supposed 
to
"mergemaster"?

I did a full "mergemaster -CUFi" lately and did the same again, but when 
mergemaster ran
the second (or n-th) time again, it stops by by the same non standard files in 
etc edited
by me. Is there a workaround and if so, please hint me to the announcement. 

Thanks in advance,
a happy new year

oh


pgp2wkatkgO06.pgp
Description: OpenPGP digital signature

Re: CURRENT, usr/src on git, howto "mergemaster"?

[David Wolfskill]

On Mon, Jan 04, 2021 at 12:35:28PM +0100, Hartmann, O. wrote:
> Now, since /usr/src has been siwtched to git on several boxes and the former 
> svn tag
> $FreeBSD$ seem not valid/useful anymore, how am I (or any other here) 
> supposed to
> "mergemaster"?
> 
> I did a full "mergemaster -CUFi" lately and did the same again, but when 
> mergemaster ran
> the second (or n-th) time again, it stops by by the same non standard files 
> in etc edited
> by me. Is there a workaround and if so, please hint me to the announcement. 
> 
> Thanks in advance,
> a happy new year
> 

After trying to use mergemaster for a couple of weeks (after the switch
to sources from git, vs. svn) of daily tracking of head & stable/12 on a
pair of machines (and weekly tracking of stable/12 on another 4), I gave
up and switched to etcupdate.

Note that each of mergemaster and etcupdate has a "-p" flag; it is
functionally equivalent between the two, but called slightly
differently:

* mergemaster: 'Pre-buildworld mode'

* etcupdate: '“pre-world” mode'

And note that per src/UPDATING, "mergemaster -Fp" is invoked after "make
buildworld" but before "make installworld" (under "To rebuild everything
and install it on the current system.", under "COMMON ITEMS:").

Caveat: Since the switch, I have yet to encounter a case where I needed
to merge a change in (e.g., because of a newly-created user, or there
was a commit to /etc/crontab or /etc/newsyslog.conf).  I may find things
rather "more interesting" when that happens; we shall see.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
An election becomes "disputed" merely when any party claims a disagreement
about it, no matter how evidence-free, specious, absurd, or ridiculous.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

13-current panic

[Sergey Dyatko]

Hi,
I  have multiple servers  running 13-CURRENT and after upgrade to r368448
the following panic began to appear on them:

vpan1c() at vpanic.Ox1b2/frame Oxfe019b32ffa0
panic() at panic.0x43/frame Oxfe01933
trap_fatal() at trap_fatal.0x387/frame Oxfe019b330060
trap_pfault() at trap_pfault.0x4f/frame Oxfe019b3300c0
trap() at trap.0x27d/frame Oxfe019b3301d0
calltrap() at calltrap+0x8/frame Oxfe019b3301d0
--- trap 0xc. rip = Ox80c8b3c8. rsp = Oxfe019b3302a0, rbp =
Oxfe
019b330310 ---
m_copydata() at m_copydata+0x58/frame Oxfe019b330310
tcp_output() at tcp_output+0x100b/frame Oxfe019b3304b0
tcp_do_segment() at tcp_do_segment+0x2867/frame Oxfe019b3305a0
tcp_input() at tcp_input.Oxabe/frame Oxfe019b3306d0
ip_input() at ip_input+0x125/frame Oxfe019b330760
netisr_dispatch_src() at netisr_dispatch_src+0xca/frame Oxfe019b3307b0
ether_demux() at ether demux+0x138/frame Oxfe019b3307e0
ether_nh_input() at ether_nh_input+0x351/frame Oxfe019b330840
netisr_dispatch_src() at netisr dispatch_src+0xca/frame Oxfe019b330890
ether_input() at ether_input+0x69/frame Oxfe019b3308f0
tcp_flush_out_le() at tcp_flush_out_le+0x211/frame Oxfe019b330910
tcp_push_and_replace() at tcp_push_and_replace+0x30/frame
Oxfe019b330950
tcp_lro_flush() at tcp_lro_flush+0x4c/frame Oxfe019b330980
tcp_lro_flush_all() at tcp_lro_flush_all+0x13b/frame Oxfe019b3309c0
iflib_rxeof() at iflib_rxeof+Oxc7a/frame Oxfe019b330ac0
_task_fn_rx() at _task_fn_rx+0x72/frame Oxfe019b330b00
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x15d/frame
Oxfe019b330b80
gtaskqueue thread_loop() at gtaskqueue thread loop+0xac/frame
Oxfe019b330bb0
fork_exit() at fork_exit+0x7e/frame Oxfe019b330bf0
fork trampoline() at fork_trampoline+0xe/frame Oxfe019b330bf0
-- trap O. rip = O. rsp = O. rbp = 0 ---

it is fileservers with zfs+nginx, higher is the result of recognizing
picture to text, just in case (there are was many recognision mistakes)
screenshot:
https://gyazo.com/116e9666daf0dac6d09628d1585596fa

I can run commands in the debugger when panic reappears if needed
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Matthew Seaman]

On 04/01/2021 12:29, David Wolfskill wrote:


Caveat: Since the switch, I have yet to encounter a case where I needed
to merge a change in (e.g., because of a newly-created user, or there
was a commit to /etc/crontab or /etc/newsyslog.conf).  I may find things
rather "more interesting" when that happens; we shall see.


The process of merging changes in etcupdate(1) is essentially identical 
to merging in mergemaster(1) -- the difference being that typically 
etcupdate(1) will run to completion without any user intervention 
needed, or else it will flag up that there are unresolved differences to 
merge and flag to the user to run `etcupdate resolve` as a separate command.


This is much more time efficient than the typical mergemaster(1) 
procedure, and I find it lends itself much more effectively to 
automation through eg. ansible.  (ie. you can just run the first 
`etcupdate` through automation across all of your server inventory, and 
then go round and manually resolve anything that needs it.)


Cheers,

Matthew

___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Jeffrey Bouquet]

On Mon, 4 Jan 2021 12:57:43 +, Matthew Seaman  wrote:

> On 04/01/2021 12:29, David Wolfskill wrote:
> 
> > Caveat: Since the switch, I have yet to encounter a case where I needed
> > to merge a change in (e.g., because of a newly-created user, or there
> > was a commit to /etc/crontab or /etc/newsyslog.conf).  I may find things
> > rather "more interesting" when that happens; we shall see.
> 
> The process of merging changes in etcupdate(1) is essentially identical 
> to merging in mergemaster(1) -- the difference being that typically 
> etcupdate(1) will run to completion without any user intervention 
> needed, or else it will flag up that there are unresolved differences to 
> merge and flag to the user to run `etcupdate resolve` as a separate command.
> 
> This is much more time efficient than the typical mergemaster(1) 
> procedure, and I find it lends itself much more effectively to 
> automation through eg. ansible.  (ie. you can just run the first 
> `etcupdate` through automation across all of your server inventory, and 
> then go round and manually resolve anything that needs it.)
> 
>   Cheers,
> 
>   Matthew
> 
> ___
> 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"


after checking out stable/12 with git, here a
#   cd /usr/src/usr.sbin/mergemaster
#  sh ./mergemaster.sh -piPcv

and then answering 'l' for left for most merges
it seems to have sufficed. 
This was before installworld. 

In case that helps.
I keep that command parameter in /etc/motd for each time around lookup. 
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[David Wolfskill]

On Mon, Jan 04, 2021 at 05:22:10AM -0800, Jeffrey Bouquet wrote:
> ... 
> after checking out stable/12 with git, here a
> #   cd /usr/src/usr.sbin/mergemaster
> #  sh ./mergemaster.sh -piPcv
> 
> and then answering 'l' for left for most merges
> it seems to have sufficed. 
> This was before installworld. 

Yes.  However, the salient issue for me is that with the Ids in the
file, on subsequent invocations, mergemaster would leave the file as-is
unless the Id changed.  This wass usually on the order of a few times
per year for a given file.

Now that the Ids are no longer present, mergemaster will now prompt on
every invocation for each file locally modified on each machine.

This amounts to about a dozen opportunities to screw things up for each
machine daily for me; that's just not ... reasonable.

So far, etcupdate seems to be working out OK for me (as in "not
prompting for each of the files in question on each invocation").

> In case that helps.
> I keep that command parameter in /etc/motd for each time around lookup. 
> 

:-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
An election becomes "disputed" merely when any party claims a disagreement
about it, no matter how evidence-free, specious, absurd, or ridiculous.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: CURRENT, usr/src on git, howto "mergemaster"?

[Marek Zarychta]

W dniu 04.01.2021 o 14:32, David Wolfskill pisze:
> On Mon, Jan 04, 2021 at 05:22:10AM -0800, Jeffrey Bouquet wrote:
>> ... 
>> after checking out stable/12 with git, here a
>> #   cd /usr/src/usr.sbin/mergemaster
>> #  sh ./mergemaster.sh -piPcv
>>
>> and then answering 'l' for left for most merges
>> it seems to have sufficed. 
>> This was before installworld. 
> 
> Yes.  However, the salient issue for me is that with the Ids in the
> file, on subsequent invocations, mergemaster would leave the file as-is
> unless the Id changed.  This wass usually on the order of a few times
> per year for a given file.
> 
> Now that the Ids are no longer present, mergemaster will now prompt on
> every invocation for each file locally modified on each machine.
> 
> This amounts to about a dozen opportunities to screw things up for each
> machine daily for me; that's just not ... reasonable.
> 
> So far, etcupdate seems to be working out OK for me (as in "not
> prompting for each of the files in question on each invocation").
> 
>> In case that helps.
>> I keep that command parameter in /etc/motd for each time around lookup. 
>> 


$FreeBSD$ tags can be regenerated locally with Git clean and smudge
filters[1] applied on local git repository. This helps to keep the track
of files updated by mergemaster(8) or etcupdate(8).

The filters should be applied to only the files important for
mergemagster. Applying filters to the whole repository degrades
performance.


[1]https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes

Regards,
-- 
Marek Zarychta



OpenPGP_signature
Description: OpenPGP digital signature

Re: CURRENT, usr/src on git, howto "mergemaster"?

[Warner Losh]

On Mon, Jan 4, 2021 at 5:57 AM Matthew Seaman  wrote:

> On 04/01/2021 12:29, David Wolfskill wrote:
>
> > Caveat: Since the switch, I have yet to encounter a case where I needed
> > to merge a change in (e.g., because of a newly-created user, or there
> > was a commit to /etc/crontab or /etc/newsyslog.conf).  I may find things
> > rather "more interesting" when that happens; we shall see.
>
> The process of merging changes in etcupdate(1) is essentially identical
> to merging in mergemaster(1) -- the difference being that typically
> etcupdate(1) will run to completion without any user intervention
> needed, or else it will flag up that there are unresolved differences to
> merge and flag to the user to run `etcupdate resolve` as a separate
> command.
>

etcupdate does a full three merge, while mergemaster fakes it in a number
of ways. etcupdate directly keeps track of the resolutions, which is why
$FreeBSD$ doesn't matter so much to it.

mergemaster is deprecated and will likely be removed from the system
because it has no maintainer and is quite a bit harder to keep working than
etcupdate.

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: CURRENT, usr/src on git, howto "mergemaster"?

[Christos Chatzaras]

> I do not remember mergemaster having a bootstrap stage in setting
> it up, a stage that should be executed before /usr/src (or whatever)
> is updated. So the procedures are different overall.

etcupdate does a 3-way merge.

What I did to replace mergemaster with etcupdate was:

rm -fr /usr/src
svnup release
etcupdate extract
rm -fr /usr/src
gitup release

cd /usr/src
make buildworld
make buildkernel

make installkernel
etcupdate -p
make installworld
etcupdate

make -DBATCH_DELETE_OLD_FILES delete-old
make -DBATCH_DELETE_OLD_FILES delete-old-libs

shutdown -r now
___
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"

boot loader blank screen

[John Kennedy]

This is a little weird.

Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th),
I've lost the screen in the boot loader.  This is really weird because I
didn't update the boot loader (in quite a while, actually), but I suppose it
might drag some stuff off of the disk and misbehave.

But the system boots, presumably after the countdown that I can't see, I just
have to SSH in from a different machine to tweak things.  Just no screen at
all past the GELI encrypted disk password prompt (and some usual noise as
it complains about some padding that I've seen forever).

I used to just upgrade the boot loader around ZFS upgrades, and I haven't
done that since OpenZFS got merged.  I just got overly conservative there
and may have missed the "all clear" for all combinations of ZFS and the
bootloader recognizing them.

The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
I'm going to repull all the sources and recompile, just in case.  I might
have initiall pulled it during the git conversion and maybe it is confused.

___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Marek Zarychta]

W dniu 04.01.2021 o 17:14, Warner Losh pisze:

> etcupdate does a full three merge, while mergemaster fakes it in a number
> of ways. etcupdate directly keeps track of the resolutions, which is why
> $FreeBSD$ doesn't matter so much to it.
> 
> mergemaster is deprecated and will likely be removed from the system
> because it has no maintainer and is quite a bit harder to keep working than
> etcupdate.
> 

Please don't sacrifice mergemaster(8) for the successful transition to
Git. The amount of feedback on the mailing list should give the core@
some idea of how widely mergemasted is still deployed. Some people just
like to merge files side by side with pressing keys. Why innocent
mergemaster(8) has to be a victim of switching to Git? Sacrifice please
svnlite(1) - it became completely useless for HEAD and upcoming stable
branches.

Kind regards,

-- 
Marek Zarychta



OpenPGP_signature
Description: OpenPGP digital signature

git non-time-sequential logs

[John Kennedy]

On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote:
> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
> I'm going to repull all the sources and recompile, just in case.  I might
> have initiall pulled it during the git conversion and maybe it is confused.

This might be perfectly natural and just new to me, but when I look at the
git logs this morning I see things like this (editing by me):

commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, 
freebsd/main, freebsd/HEAD)
Author: Emmanuel Vadot 
Date:   Mon Jan 4 17:30:00 2021 +0100

commit f61a3898bb989edef7ca308043224e495ed78f64
Author: Emmanuel Vadot 
Date:   Mon Dec 14 18:56:56 2020 +0100

commit b6cc69322a77fa778b00db873781be04f26bd2ee
Author: Emmanuel Vadot 
Date:   Tue Dec 15 13:50:00 2020 +0100

commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
Author: Emmanuel Vadot 
Date:   Mon Jan 4 16:23:10 2021 +0100

  This is a fresh clone+pull off of anon...@git.freebsd.org:src.git.

  I've always assumed that the "Date:" there was when the commit happened,
so they'd be increasing (most recent on top), but I suppose that you might
have developers in branches that are committing to their branch at one
point in time and it's getting merged into current (main) later, but the
original date is preserved?

  I guess I only care because I was trying to use time to bisect the
time I thought the problem might have been introduced.

___
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: git non-time-sequential logs

[Poul-Henning Kamp]

John Kennedy writes:

> This might be perfectly natural and just new to me, but when I look at the
> git logs this morning I see things like this (editing by me):
>
>   Date:   Mon Jan 4 17:30:00 2021 +0100
>   Date:   Mon Dec 14 18:56:56 2020 +0100
>   Date:   Tue Dec 15 13:50:00 2020 +0100
>   Date:   Mon Jan 4 16:23:10 2021 +0100
>
>   I've always assumed that the "Date:" there was when the commit happened,

It is, but it is the time it was committed in the first git repos it was 
committed to,
in this case the repos of the committer in question.

Without taking a position on the merits of this design-choice, I
just want to point out that it means that timestamps should be
viewed very sceptically, since they depend on the *local* clock on
somebodys computer, not on the central repos machine.

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

Re: git non-time-sequential logs

[Alan Somers]

On Mon, Jan 4, 2021 at 9:58 AM Poul-Henning Kamp  wrote:

> 
> John Kennedy writes:
>
> > This might be perfectly natural and just new to me, but when I look at
> the
> > git logs this morning I see things like this (editing by me):
> >
> >   Date:   Mon Jan 4 17:30:00 2021 +0100
> >   Date:   Mon Dec 14 18:56:56 2020 +0100
> >   Date:   Tue Dec 15 13:50:00 2020 +0100
> >   Date:   Mon Jan 4 16:23:10 2021 +0100
> >
> >   I've always assumed that the "Date:" there was when the commit
> happened,
>
> It is, but it is the time it was committed in the first git repos it was
> committed to,
> in this case the repos of the committer in question.
>
> Without taking a position on the merits of this design-choice, I
> just want to point out that it means that timestamps should be
> viewed very sceptically, since they depend on the *local* clock on
> somebodys computer, not on the central repos machine.
>

I'll be more frank than phk: it sucks.  Git's commit dates are basically
useless.  But there are a few ways to improve the situation:
1) If we start using Gitlab or something similar, we can ban pushes
directly to head.  Then we'll be able to trust the Dates on Gitlab's merge
commits.
2) Perhaps we can use the Git Notes to add a field for the Date when a
commit was pushed to the master server?
3) The internet is full of suggestions for how to change the way commits
are displayed locally to mediate this problem.  But they all seem to
involve changes to the working copy's configuration, not the master's.  And
I haven't gotten any way to work.

-Alan
___
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: git non-time-sequential logs

[Poul-Henning Kamp]

Alan Somers writes:

> I'll be more frank than phk: it sucks.  Git's commit dates are basically
> useless.

Git is not built as, or to be, version control.

Git is built to be distrbuted collaboration tool.

The designed-in version control aspect was always, and only, that
the ranting finish guy *by fiat* had the golden tree.

The fact that people, like us, dress git up and call it a VCS does
not wash the stripes of the tiger.

To me, personally, having a distributed collaboration tool has been
much more valuable than any "pure" or "real" VCS ever were.

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

Re: git non-time-sequential logs

[Warner Losh]

On Mon, Jan 4, 2021 at 10:51 AM Poul-Henning Kamp 
wrote:

> 
> Alan Somers writes:
>
> > I'll be more frank than phk: it sucks.  Git's commit dates are basically
> > useless.
>
> Git is not built as, or to be, version control.
>
> Git is built to be distrbuted collaboration tool.
>
> The designed-in version control aspect was always, and only, that
> the ranting finish guy *by fiat* had the golden tree.
>
> The fact that people, like us, dress git up and call it a VCS does
> not wash the stripes of the tiger.
>
> To me, personally, having a distributed collaboration tool has been
> much more valuable than any "pure" or "real" VCS ever were.
>

Yes. Git has never been a true/pure VCS. However, it does offer enough
VCS-like features to create a shared distributed versioned tree that's
useful to the project.

As for date order, we could also add a commit hook that requires the date
to be properly set, but that creates friction for developers. Is that
friction worth the benefits? I don't think so, but as you say we could also
add notes... but since there's no checkout by date feature, I'm not sure
what good it would do.

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: CURRENT, usr/src on git, howto "mergemaster"?

[Warner Losh]

On Mon, Jan 4, 2021 at 9:36 AM Marek Zarychta 
wrote:

> W dniu 04.01.2021 o 17:14, Warner Losh pisze:
>
> > etcupdate does a full three merge, while mergemaster fakes it in a number
> > of ways. etcupdate directly keeps track of the resolutions, which is why
> > $FreeBSD$ doesn't matter so much to it.
> >
> > mergemaster is deprecated and will likely be removed from the system
> > because it has no maintainer and is quite a bit harder to keep working
> than
> > etcupdate.
> >
>
> Please don't sacrifice mergemaster(8) for the successful transition to
> Git. The amount of feedback on the mailing list should give the core@
> some idea of how widely mergemasted is still deployed. Some people just
> like to merge files side by side with pressing keys. Why innocent
> mergemaster(8) has to be a victim of switching to Git? Sacrifice please
> svnlite(1) - it became completely useless for HEAD and upcoming stable
> branches.
>

mergemaster has been on its way out since well before the switch to git.
It's been disfavored for at least a decade and basically unmaintained in
the base for maybe last 5 years. Apart from major breakage, only doc
changes have happened in that time.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT, usr/src on git, howto "mergemaster"?

[Enji Cooper]

> On Jan 4, 2021, at 10:19, Warner Losh  wrote:
> 
> On Mon, Jan 4, 2021 at 9:36 AM Marek Zarychta 
> wrote:
> 
>> W dniu 04.01.2021 o 17:14, Warner Losh pisze:
>> 
>>> etcupdate does a full three merge, while mergemaster fakes it in a number
>>> of ways. etcupdate directly keeps track of the resolutions, which is why
>>> $FreeBSD$ doesn't matter so much to it.
>>> 
>>> mergemaster is deprecated and will likely be removed from the system
>>> because it has no maintainer and is quite a bit harder to keep working
>> than
>>> etcupdate.
>>> 
>> 
>> Please don't sacrifice mergemaster(8) for the successful transition to
>> Git. The amount of feedback on the mailing list should give the core@
>> some idea of how widely mergemasted is still deployed. Some people just
>> like to merge files side by side with pressing keys. Why innocent
>> mergemaster(8) has to be a victim of switching to Git? Sacrifice please
>> svnlite(1) - it became completely useless for HEAD and upcoming stable
>> branches.
>> 
> 
> mergemaster has been on its way out since well before the switch to git.
> It's been disfavored for at least a decade and basically unmaintained in
> the base for maybe last 5 years. Apart from major breakage, only doc
> changes have happened in that time.

Adding to this: it has no maintainer, it’s less featureful, and it lacks tests. 
Once I switched to etcupdate a few years back I never looked back at 
mergemaster.

I honestly think it should be deprecated in 13.x and removed in 14.x. It’s been 
several major releases since it’s been unofficially deprecated.

-Enji
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Andrea Venturoli]

On 1/4/21 7:18 PM, Warner Losh wrote:


mergemaster has been on its way out since well before the switch to git.
It's been disfavored for at least a decade


I first heard about this today.
While I don't have any opinion on this, shouldn't any reference to it in 
the instructions in /usr/src/UPDATING be changed?
They way I read that file is that mergemaster is still the official way 
to go.


 bye & Thanks
av.
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[David Wolfskill]

On Mon, Jan 04, 2021 at 10:30:28AM -0800, Enji Cooper wrote:
> ... 
> Adding to this: it has no maintainer, it’s less featureful, and it lacks 
> tests. Once I switched to etcupdate a few years back I never looked back at 
> mergemaster.
> 
> I honestly think it should be deprecated in 13.x and removed in 14.x. It’s 
> been several major releases since it’s been unofficially deprecated.
> 
> -Enji
> 

All of which is fine, but at some point prior to that, perhaps
src/UPDATING's instructions that cite its use might merit a change to
reflect the use of a supported tool?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Real "RINOs": Donald Trump and his acolytes (e.g., Ted Cruz; Josh Hawley).

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: boot loader blank screen

[John Kennedy]

On Mon, Jan 04, 2021 at 06:30:38PM +0200, Toomas Soome wrote:
> Yes, it is known defect, and I???m searching for cause; the issue is with 
> /boot/loader and BIOS text mode (unfortunately I have the usual ???but it is 
> working for me??? case). For workaround, you can try to either: 1 (blind) 
> press esc to get out of boot menu, then enter: vbe on; another option is to 
> add hw.vga.textmode=???0??? to loader.conf.
> 
> Sorry for confusion,
> toomas

  Yeah, that is a BIOS (vs UEFI) system.  Adding hw.vga.textmode=0 worked,
and I like the graphical demon for what that's worth.  (:

  I've also upgraded the bootcode, although that may mean nothing if the
textmode is avoiding the problem.

  In any case, I guess I have a known-bad (?) system, so if I can help you
out in some way let me know.  Bonking that box every now and then isn't a
problem for me.
___
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: boot loader blank screen

[Warner Losh]

On Mon, Jan 4, 2021 at 11:35 AM John Kennedy  wrote:

> On Mon, Jan 04, 2021 at 06:30:38PM +0200, Toomas Soome wrote:
> > Yes, it is known defect, and I???m searching for cause; the issue is
> with /boot/loader and BIOS text mode (unfortunately I have the usual ???but
> it is working for me??? case). For workaround, you can try to either: 1
> (blind) press esc to get out of boot menu, then enter: vbe on; another
> option is to add hw.vga.textmode=???0??? to loader.conf.
> >
> > Sorry for confusion,
> > toomas
>
>   Yeah, that is a BIOS (vs UEFI) system.  Adding hw.vga.textmode=0 worked,
> and I like the graphical demon for what that's worth.  (:
>
>   I've also upgraded the bootcode, although that may mean nothing if the
> textmode is avoiding the problem.
>
>   In any case, I guess I have a known-bad (?) system, so if I can help you
> out in some way let me know.  Bonking that box every now and then isn't a
> problem for me.
>

Yea, this is a feature that needs to be fixed since black on black text is
a show stopper :(

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: CURRENT, usr/src on git, howto "mergemaster"?

[Enji Cooper]

> On Jan 4, 2021, at 10:33 AM, David Wolfskill  wrote:
> 
> On Mon, Jan 04, 2021 at 10:30:28AM -0800, Enji Cooper wrote:
>> ... 
>> Adding to this: it has no maintainer, it’s less featureful, and it lacks 
>> tests. Once I switched to etcupdate a few years back I never looked back at 
>> mergemaster.
>> 
>> I honestly think it should be deprecated in 13.x and removed in 14.x. It’s 
>> been several major releases since it’s been unofficially deprecated.
>> 
>> -Enji
>> 
> 
> All of which is fine, but at some point prior to that, perhaps
> src/UPDATING's instructions that cite its use might merit a change to
> reflect the use of a supported tool?

I’ll submit a patch soon on Phabricator to do this (might as well test out the 
new git workflow on my end…).
Cheers,
-Enji
___
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: boot loader blank screen

[Gary Jennejohn]

On Mon, 4 Jan 2021 08:22:56 -0800
John Kennedy  wrote:

> This is a little weird.
> 
> Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th),
> I've lost the screen in the boot loader.  This is really weird because I
> didn't update the boot loader (in quite a while, actually), but I suppose it
> might drag some stuff off of the disk and misbehave.
> 
> But the system boots, presumably after the countdown that I can't see, I just
> have to SSH in from a different machine to tweak things.  Just no screen at
> all past the GELI encrypted disk password prompt (and some usual noise as
> it complains about some padding that I've seen forever).
> 
> I used to just upgrade the boot loader around ZFS upgrades, and I haven't
> done that since OpenZFS got merged.  I just got overly conservative there
> and may have missed the "all clear" for all combinations of ZFS and the
> bootloader recognizing them.
> 

I had this problem also after I updated my sources this morning in
Germany and decided to make a new kernel and world.  I then booted the
new kernel and did installworld, after which I rebooted with the new
kernel and saw that the console disappeared after the BTX Loader
output appeared.

So I logged in using ssh and looked under /boot.  There were 52 files
which had been newly installed, all of them related to booting.

Luckily, I had a backup of /boot which I'd made on January 1. 
Restoring the backup got me back my console.

I have no idea which of the newly installed files caused the console
to disappear.  Note that my loader.conf was not modified.  And also
that I still use 4th rather than lua.

I tried using both sc and vt, but the console still failed to appear.

> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
> I'm going to repull all the sources and recompile, just in case.  I might
> have initiall pulled it during the git conversion and maybe it is confused.
> 

-- 
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: CURRENT, usr/src on git, howto "mergemaster"?

[Marek Zarychta]

W dniu 04.01.2021 o 19:30, Enji Cooper pisze:
> 
>> On Jan 4, 2021, at 10:19, Warner Losh  wrote:
>>
>> On Mon, Jan 4, 2021 at 9:36 AM Marek Zarychta 
>> 
>> wrote:
>>
>>> W dniu 04.01.2021 o 17:14, Warner Losh pisze:
>>>
 etcupdate does a full three merge, while mergemaster fakes it in a number
 of ways. etcupdate directly keeps track of the resolutions, which is why
 $FreeBSD$ doesn't matter so much to it.

 mergemaster is deprecated and will likely be removed from the system
 because it has no maintainer and is quite a bit harder to keep working
>>> than
 etcupdate.

>>>
>>> Please don't sacrifice mergemaster(8) for the successful transition to
>>> Git. The amount of feedback on the mailing list should give the core@
>>> some idea of how widely mergemasted is still deployed. Some people just
>>> like to merge files side by side with pressing keys. Why innocent
>>> mergemaster(8) has to be a victim of switching to Git? Sacrifice please
>>> svnlite(1) - it became completely useless for HEAD and upcoming stable
>>> branches.
>>>
>>
>> mergemaster has been on its way out since well before the switch to git.
>> It's been disfavored for at least a decade and basically unmaintained in
>> the base for maybe last 5 years. Apart from major breakage, only doc
>> changes have happened in that time.
> 
> Adding to this: it has no maintainer, it’s less featureful, and it lacks 
> tests. Once I switched to etcupdate a few years back I never looked back at 
> mergemaster.
> 
> I honestly think it should be deprecated in 13.x and removed in 14.x. It’s 
> been several major releases since it’s been unofficially deprecated.
> 


Terrible idea IMHO, but I am only the weak voice from the userbase.

It's like deprecating old, well-worn hammer in the favour of the nail
gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?

Kind regards,

-- 
Marek Zarychta



OpenPGP_signature
Description: OpenPGP digital signature

Re: git non-time-sequential logs

[Ryan Libby]

On Mon, Jan 4, 2021 at 10:08 AM Warner Losh  wrote:
...
> As for date order, we could also add a commit hook that requires the date
> to be properly set, but that creates friction for developers. Is that
> friction worth the benefits? I don't think so, but as you say we could also
> add notes... but since there's no checkout by date feature, I'm not sure
> what good it would do.

Not a vote one way or the other, but it would at least make
git log --since more meaningful.
___
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: git non-time-sequential logs

[Enji Cooper]

> On Jan 4, 2021, at 9:05 AM, Alan Somers  wrote:
> 
> On Mon, Jan 4, 2021 at 9:58 AM Poul-Henning Kamp  > wrote:
> 
>> 
>> John Kennedy writes:
>> 
>>> This might be perfectly natural and just new to me, but when I look at
>> the
>>> git logs this morning I see things like this (editing by me):
>>> 
>>>  Date:   Mon Jan 4 17:30:00 2021 +0100
>>>  Date:   Mon Dec 14 18:56:56 2020 +0100
>>>  Date:   Tue Dec 15 13:50:00 2020 +0100
>>>  Date:   Mon Jan 4 16:23:10 2021 +0100
>>> 
>>>  I've always assumed that the "Date:" there was when the commit
>> happened,
>> 
>> It is, but it is the time it was committed in the first git repos it was
>> committed to,
>> in this case the repos of the committer in question.
>> 
>> Without taking a position on the merits of this design-choice, I
>> just want to point out that it means that timestamps should be
>> viewed very sceptically, since they depend on the *local* clock on
>> somebodys computer, not on the central repos machine.
>> 
> 
> I'll be more frank than phk: it sucks.  Git's commit dates are basically
> useless.  But there are a few ways to improve the situation:
> 1) If we start using Gitlab or something similar, we can ban pushes
> directly to head.  Then we'll be able to trust the Dates on Gitlab's merge
> commits.
> 2) Perhaps we can use the Git Notes to add a field for the Date when a
> commit was pushed to the master server?
> 3) The internet is full of suggestions for how to change the way commits
> are displayed locally to mediate this problem.  But they all seem to
> involve changes to the working copy's configuration, not the master's.  And
> I haven't gotten any way to work.

I actually find the non-sequential dates a feature: if someone reorders commits 
in a stack, e.g., `git rebase -I` I find it curious wondering why things were 
committed in the order they were.

The point is to stop looking at git like svn: commits should be done as larger 
bodies of work (merge commits), as opposed to single atomic commits.

Cheers,
-Enji
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Enji Cooper]

> On Jan 4, 2021, at 10:49 AM, Marek Zarychta  
> wrote:

…

> Terrible idea IMHO, but I am only the weak voice from the userbase.
> 
> It's like deprecating old, well-worn hammer in the favour of the nail
> gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?

Marek,
I’m curious: have you used etcupdate before instead of mergemaster? If 
so when? If you ran into issues (UX as well as functional): could you please 
report them on bugs.freebsd.org  ?
etcupdate is a less fragile tool that’s broken my systems less when 
compared with mergemaster.
Cheers,
-Enji
___
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: boot loader blank screen

[John Kennedy]

On Mon, Jan 04, 2021 at 11:39:08AM -0700, Warner Losh wrote:
> Yea, this is a feature that needs to be fixed since black on black text is
> a show stopper :(

  Ah, this is part of the "Terminal colours in current" thread?  I saw that,
but didn't correlate it with default black-on-black text.  It looked like
more of a graphics-mode glitch (blank screen, backlit, signal) initially, I'd
just not seen something like that bite me at the bootloader stage before.
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Enji Cooper]

> On Jan 4, 2021, at 10:54 AM, Enji Cooper  wrote:
> 
> 
>> On Jan 4, 2021, at 10:49 AM, Marek Zarychta > > wrote:
> 
> …
> 
>> Terrible idea IMHO, but I am only the weak voice from the userbase.
>> 
>> It's like deprecating old, well-worn hammer in the favour of the nail
>> gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?
> 
> Marek,
>   I’m curious: have you used etcupdate before instead of mergemaster? If 
> so when? If you ran into issues (UX as well as functional): could you please 
> report them on bugs.freebsd.org  ?
>   etcupdate is a less fragile tool that’s broken my systems less when 
> compared with mergemaster.

That reminds me, there is a feature gap (in the last 5~10 years I’ve used 
etcupdate) that I forgot about between mergemaster and etcupdate: in 
particular, mergemaster works when adding/removing new users and groups from 
/etc/passwd* and /etc/group, respectively, dealing with mtree files, the last 
time I checked. Apart from that, I don’t see a use for mergemaster (and in 
which case, the feature gap can be trimmed down/migrated to etcupdate). 
mergemaster has broken the configuration of my machines/VMs more than etcupdate 
has ever and I’ve used both tools for about the same time.

Cheers,
-Enji
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Steve Kargl]

On Mon, Jan 04, 2021 at 10:30:28AM -0800, Enji Cooper wrote:
> 
>> On Jan 4, 2021, at 10:19, Warner Losh  wrote:
>> 
>> mergemaster has been on its way out since well before the switch to git.
>> It's been disfavored for at least a decade and basically unmaintained in
>> the base for maybe last 5 years. Apart from major breakage, only doc
>> changes have happened in that time.
> 
> Adding to this: it has no maintainer, it’s less featureful, and it lacks 
> tests. Once I switched to etcupdate a few years back I never looked back at 
> mergemaster.
> 
> I honestly think it should be deprecated in 13.x and removed in 14.x. It’s 
> been several major releases since it’s been unofficially deprecated.
> 
> -Enji
>

For something that has been disfavored for a decade, unmaintained
for at least 5 years, and now seemly unofficially deprecated, it
seems strange that /usr/src/UPDATING does not mention etcupdate
in the COMMON ITEMS section.

% svn info UPDATING | grep -i vision
Revision: 367909
% svn blame UPDATING
...
 64477   imp To rebuild everything and install it on the current system.
 64477   imp ---
...
262619   jmg mergemaster -Fp [5]
262619   jmg mergemaster -Fi [4]

% svn log -r 262619

r262619 | jmg | 2014-02-28 11:51:47 -0800 (Fri, 28 Feb 2014) | 3 lines

since -F is safe, and an update from 10-HEAD to 10-STABLE is sooo bloody
anoying w/o it..  recommend people use -F too...


etcupdate first appeared in the tree on 2012-07-13 (r238423)

-- 
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: git non-time-sequential logs

[Franco Fichtner]

> On 4. Jan 2021, at 7:52 PM, Enji Cooper  wrote:
> 
> The point is to stop looking at git like svn: commits should be done as 
> larger bodies of work (merge commits), as opposed to single atomic commits.

Er, uh, no.  ;)

The author date stays the same, the committer date is sequential except
that it indicates the local time of the committer doing the cherry-pick
instead of the central server as opposed to svn:

# git log --format=fuller


Cheers,
Franco

___
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: boot loader blank screen

[Warner Losh]

On Mon, Jan 4, 2021 at 11:53 AM John Kennedy  wrote:

> On Mon, Jan 04, 2021 at 11:39:08AM -0700, Warner Losh wrote:
> > Yea, this is a feature that needs to be fixed since black on black text
> is
> > a show stopper :(
>
>   Ah, this is part of the "Terminal colours in current" thread?  I saw
> that,
> but didn't correlate it with default black-on-black text.  It looked like
> more of a graphics-mode glitch (blank screen, backlit, signal) initially,
> I'd
> just not seen something like that bite me at the bootloader stage before.
>

To be fair, I'm unsure if this is a failure to draw the characters, or a
color attribute failure introduced. I've not looked deeply and am jumping a
bit to conclusions.

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: git non-time-sequential logs

[John Kennedy]

On Mon, Jan 04, 2021 at 07:59:12PM +0100, Franco Fichtner wrote:
> The author date stays the same, the committer date is sequential except
> that it indicates the local time of the committer doing the cherry-pick
> instead of the central server as opposed to svn:
> 
> # git log --format=fuller

  That format gets me the CommitDate:, which is what I would have been
looking for.  Seems like the data is there, just not necessarily used
(displayed) by default.

  Not sure what the original SVN timestamps were, but assuming GMT:

(export TZ=GMT && git log --format=fuller --date=local)

  Maybe there are some ways to make those default options.

___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Marek Zarychta]

W dniu 04.01.2021 o 19:54, Enji Cooper pisze:
> 
>> On Jan 4, 2021, at 10:49 AM, Marek Zarychta  
>> wrote:
> 
> …
> 
>> Terrible idea IMHO, but I am only the weak voice from the userbase.
>>
>> It's like deprecating old, well-worn hammer in the favour of the nail
>> gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?
> 
> Marek,
>   I’m curious: have you used etcupdate before instead of mergemaster? If 
> so when? If you ran into issues (UX as well as functional): could you please 
> report them on bugs.freebsd.org  ?
>   etcupdate is a less fragile tool that’s broken my systems less when 
> compared with mergemaster.

Dear Enji,

to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times
over years. It works fine, but I don't like the idea of editing
conflicted files.

I won't complain about etcupdate(8), but please leave mergemaster(8)
as is. I believe we need both: solid, fast black boxes driven it auto
mode and fragile tools in the base. mergemaser is rather not a potential
security hole in the system.

With kind regards,

-- 
Marek Zarychta



OpenPGP_signature
Description: OpenPGP digital signature

Re: CURRENT, usr/src on git, howto "mergemaster"?

[Jeffrey Bouquet]

On Mon, 4 Jan 2021 20:13:03 +0100, Marek Zarychta 
 wrote:

> W dniu 04.01.2021 o 19:54, Enji Cooper pisze:
> > 
> >> On Jan 4, 2021, at 10:49 AM, Marek Zarychta 
> >>  wrote:
> > 
> > …
> > 
> >> Terrible idea IMHO, but I am only the weak voice from the userbase.
> >>
> >> It's like deprecating old, well-worn hammer in the favour of the nail
> >> gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?
> > 
> > Marek,
> > I’m curious: have you used etcupdate before instead of mergemaster? If 
> > so when? If you ran into issues (UX as well as functional): could you 
> > please report them on bugs.freebsd.org  ?
> > etcupdate is a less fragile tool that’s broken my systems less when 
> > compared with mergemaster.
> 
> Dear Enji,
> 
> to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times
> over years. It works fine, but I don't like the idea of editing
> conflicted files.
> 
> I won't complain about etcupdate(8), but please leave mergemaster(8)
> as is. I believe we need both: solid, fast black boxes driven it auto
> mode and fragile tools in the base. mergemaser is rather not a potential
> security hole in the system.
> 
> With kind regards,
> 
> -- 
> Marek Zarychta


+1 
___
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: git non-time-sequential logs

[Ryan Libby]

On Mon, Jan 4, 2021 at 11:00 AM Franco Fichtner  wrote:
>
>
> > On 4. Jan 2021, at 7:52 PM, Enji Cooper  wrote:
> >
> > The point is to stop looking at git like svn: commits should be done as 
> > larger bodies of work (merge commits), as opposed to single atomic commits.
>
> Er, uh, no.  ;)
>
> The author date stays the same, the committer date is sequential except
> that it indicates the local time of the committer doing the cherry-pick
> instead of the central server as opposed to svn:
>
> # git log --format=fuller
>

It's normally sequential, but with the caveat that it's ultimately
arbitrary and can't be relied on unless we enforce that.

GIT_COMMITTER_DATE="1970-01-01T00:00:00Z" git commit
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Warner Losh]

On Mon, Jan 4, 2021 at 12:13 PM Marek Zarychta <
zarych...@plan-b.pwste.edu.pl> wrote:

> W dniu 04.01.2021 o 19:54, Enji Cooper pisze:
> >
> >> On Jan 4, 2021, at 10:49 AM, Marek Zarychta <
> zarych...@plan-b.pwste.edu.pl> wrote:
> >
> > …
> >
> >> Terrible idea IMHO, but I am only the weak voice from the userbase.
> >>
> >> It's like deprecating old, well-worn hammer in the favour of the nail
> >> gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?
> >
> > Marek,
> >   I’m curious: have you used etcupdate before instead of
> mergemaster? If so when? If you ran into issues (UX as well as functional):
> could you please report them on bugs.freebsd.org 
> ?
> >   etcupdate is a less fragile tool that’s broken my systems less
> when compared with mergemaster.
>
> Dear Enji,
>
> to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times
> over years. It works fine, but I don't like the idea of editing
> conflicted files.
>
> I won't complain about etcupdate(8), but please leave mergemaster(8)
> as is. I believe we need both: solid, fast black boxes driven it auto
> mode and fragile tools in the base. mergemaser is rather not a potential
> security hole in the system.
>

mergemaster is on its way out. Formalizing it by deprecating in 13 means
you'll be able to use it through the end of life of the 13 branch many
years from now. That's plenty of time to move to the new tools and/or
develop enhancements that make them easier for you to use. The knock on
communicating this well is a fair one, and we'll start taking measures to
fix that.

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: CURRENT, usr/src on git, howto "mergemaster"?

[Enji Cooper]

> On Jan 4, 2021, at 10:59 AM, Steve Kargl  
> wrote:
> 
> On Mon, Jan 04, 2021 at 10:30:28AM -0800, Enji Cooper wrote:
>> 
>>> On Jan 4, 2021, at 10:19, Warner Losh  wrote:
>>> 
>>> mergemaster has been on its way out since well before the switch to git.
>>> It's been disfavored for at least a decade and basically unmaintained in
>>> the base for maybe last 5 years. Apart from major breakage, only doc
>>> changes have happened in that time.
>> 
>> Adding to this: it has no maintainer, it’s less featureful, and it lacks 
>> tests. Once I switched to etcupdate a few years back I never looked back at 
>> mergemaster.
>> 
>> I honestly think it should be deprecated in 13.x and removed in 14.x. It’s 
>> been several major releases since it’s been unofficially deprecated.
> 
> For something that has been disfavored for a decade, unmaintained
> for at least 5 years, and now seemly unofficially deprecated, it
> seems strange that /usr/src/UPDATING does not mention etcupdate
> in the COMMON ITEMS section.
> 
> % svn info UPDATING | grep -i vision
> Revision: 367909
> % svn blame UPDATING
> ...
> 64477   imp To rebuild everything and install it on the current system.
> 64477   imp ---
> ...
> 262619   jmg mergemaster -Fp [5]
> 262619   jmg mergemaster -Fi [4]
> 
> % svn log -r 262619
> 
> r262619 | jmg | 2014-02-28 11:51:47 -0800 (Fri, 28 Feb 2014) | 3 lines
> 
> since -F is safe, and an update from 10-HEAD to 10-STABLE is sooo bloody
> anoying w/o it..  recommend people use -F too...
> 
> 
> etcupdate first appeared in the tree on 2012-07-13 (r238423)


As noted elsewhere in the thread: I’m working on it. Here’s an official 
bug for tracking the work (in base): 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252417 
 . I’ll fill it in 
some more throughout the day (need to context switch back to $dayjob).
Thanks :)!
-Enji

___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Enji Cooper]

> On Jan 4, 2021, at 11:15 AM, Jeffrey Bouquet  
> wrote:

…

>> Dear Enji,
>> 
>> to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times
>> over years. It works fine, but I don't like the idea of editing
>> conflicted files.
>> 
>> I won't complain about etcupdate(8), but please leave mergemaster(8)
>> as is. I believe we need both: solid, fast black boxes driven it auto
>> mode and fragile tools in the base. mergemaser is rather not a potential
>> security hole in the system.

Hi Jeffrey and Marek,
Could you please be more specific in your concerns? I don’t mind 
helping resolve them, but unfortunately the concerns noted above are a bit 
nebulous.
Thank you!
-Enji
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Chris]

On 2021-01-04 10:58, Enji Cooper wrote:

On Jan 4, 2021, at 10:54 AM, Enji Cooper  wrote:


On Jan 4, 2021, at 10:49 AM, Marek Zarychta > wrote:


…


Terrible idea IMHO, but I am only the weak voice from the userbase.

It's like deprecating old, well-worn hammer in the favour of the nail
gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?


Marek,
	I’m curious: have you used etcupdate before instead of mergemaster? If so 
when? If you ran into issues (UX as well as functional): could you please 
report them on bugs.freebsd.org  ?
	etcupdate is a less fragile tool that’s broken my systems less when 
compared with mergemaster.


That reminds me, there is a feature gap (in the last 5~10 years I’ve used
etcupdate) that I forgot about between mergemaster and etcupdate: in 
particular,
mergemaster works when adding/removing new users and groups from 
/etc/passwd* and
/etc/group, respectively, dealing with mtree files, the last time I checked. 
Apart
from that, I don’t see a use for mergemaster (and in which case, the feature 
gap

can be trimmed down/migrated to etcupdate). mergemaster has broken the
configuration of my machines/VMs more than etcupdate has ever and I’ve used 
both

tools for about the same time.

TBH I've continued to use mergemaster simply out of habit, because it was the
recommended/supported way of doing it from UPDATING.
It started acting odd awhile back. So I went to performing
mergemaster -viF
to simply burn through the $Id only changes. Then diff(1)ing the the 2 trees
to create a mega-patch which I could apply. I took that route with the 
intention
of coming back to it to discover what the problem was. But never got around 
to it.

I'm *really* glad this thread came about. Now I can move onto something that
actually works as intended -- assuming /etc/(group|passwd) bits get merged. 
:-)


--Chris


Cheers,
-Enji
___
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: HEADS UP: FreeBSD src repo transitioning to git this weekend

[John-Mark Gurney]

RW wrote this message on Fri, Jan 01, 2021 at 16:56 +:
> On Thu, 31 Dec 2020 21:25:08 -0500
> grarpamp wrote:
> 
> > > Is there any reason to think [bittorrent] insecure?  
> > 
> > Cost under $50k of compute to break sha-1, 
> 
> AFAIK you cannot break SHA-1 in the sense of creating data that
> matches a specific hash. What you can do is create a collision between
> two blocks of data, varying both blocks in the process. This makes
> SHA-1 unsuitable for digital signatures.

TL;DR: No, SHA-1 is broken.  PERIOD.

SHAttered[1] (2017) created two valid PDF documents which had the same
SHA-1 hash.  The issue was that they were able to choose the entire
document.

The paper released in 2019[2] and implemented in 2020 allows for
chosen-prefix attacks[3] which means that SHA-1 is broken.

It allows the creation of a different message prefix, but results in
the same hash.  Before this, git was "secure" in that objects were
prepended w/ length and size, but w/ this latest attack, those
can now be changed as well, allowing someone to wholesale replace
a file in git w/ a different length, and the SHA-1 hash being
the same.

> A *third-party* attacker cannot create a bogus torrent using a
> collision attack against SHA-1 because the attacker would need to match
> a specific hash value. 

Wrong, see above.

> What may be possible is that the creator of the legitimate torrent
> might create two torrents with the same hash, but this seems very
> contrived and not very useful. It has all sorts of problems as a way of
> delivering targeted malware.

Again, wrong.

[1] 
https://en.wikipedia.org/wiki/SHA-1#SHAttered_%E2%80%93_first_public_collision
[2] 
https://en.wikipedia.org/wiki/SHA-1#Birthday-Near-Collision_Attack_%E2%80%93_first_practical_chosen-prefix_attack
[3] 
https://en.wikipedia.org/wiki/Collision_attack#Chosen-prefix_collision_attack

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Chris]

On 2021-01-04 11:13, Marek Zarychta wrote:

W dniu 04.01.2021 o 19:54, Enji Cooper pisze:


On Jan 4, 2021, at 10:49 AM, Marek Zarychta 
 wrote:


…


Terrible idea IMHO, but I am only the weak voice from the userbase.

It's like deprecating old, well-worn hammer in the favour of the nail
gun. Why not deprecate biff(1), pom(6), nvi(1) etc.?


Marek,
	I’m curious: have you used etcupdate before instead of mergemaster? If so 
when? If you ran into issues (UX as well as functional): could you please 
report them on bugs.freebsd.org  ?
	etcupdate is a less fragile tool that’s broken my systems less when 
compared with mergemaster.


Dear Enji,

to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times
over years. It works fine, but I don't like the idea of editing
conflicted files.

I won't complain about etcupdate(8), but please leave mergemaster(8)
as is. I believe we need both: solid, fast black boxes driven it auto
mode and fragile tools in the base. mergemaser is rather not a potential
security hole in the system.

You might find it in your best interest to adopt (become a maintainer) for
mergemaster(8). This would allow you to fix whatever ailments have arrived
over the years, and better adapt it to work with the newly adopted git(1) SCM
that is now the source of truth for /usr/src. :-)

--Chris


With kind regards,

___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Marek Zarychta]

W dniu 04.01.2021 o 20:27, Enji Cooper pisze:
> 
>> On Jan 4, 2021, at 11:15 AM, Jeffrey Bouquet  
>> wrote:
> 
> …
> 
>>> Dear Enji,
>>>
>>> to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times
>>> over years. It works fine, but I don't like the idea of editing
>>> conflicted files.
>>>
>>> I won't complain about etcupdate(8), but please leave mergemaster(8)
>>> as is. I believe we need both: solid, fast black boxes driven it auto
>>> mode and fragile tools in the base. mergemaser is rather not a potential
>>> security hole in the system.
> 
> Hi Jeffrey and Marek,
>   Could you please be more specific in your concerns? I don’t mind 
> helping resolve them, but unfortunately the concerns noted above are a bit 
> nebulous.

Dear Enji,

it's probably high time to stop escalating this thread. Some people like
the way in which mergemaster copes with updates, some people like
etcupdate. With Git clean and smudge filters applied on local repo and
$FreeBSD$ IDs regenerated, mergemaster still works great and is more
ergonomic in use for at least two people.

Kind regards,

-- 
Marek Zarychta



OpenPGP_signature
Description: OpenPGP digital signature

Re: CURRENT, usr/src on git, howto "mergemaster"?

[Michal Meloun]

On 04.01.2021 19:59, Steve Kargl wrote:

On Mon, Jan 04, 2021 at 10:30:28AM -0800, Enji Cooper wrote:



On Jan 4, 2021, at 10:19, Warner Losh  wrote:

mergemaster has been on its way out since well before the switch to git.
It's been disfavored for at least a decade and basically unmaintained in
the base for maybe last 5 years. Apart from major breakage, only doc
changes have happened in that time.


Adding to this: it has no maintainer, it’s less featureful, and it lacks tests. 
Once I switched to etcupdate a few years back I never looked back at 
mergemaster.

I honestly think it should be deprecated in 13.x and removed in 14.x. It’s been 
several major releases since it’s been unofficially deprecated.

-Enji



For something that has been disfavored for a decade, unmaintained
for at least 5 years, and now seemly unofficially deprecated, it
seems strange that /usr/src/UPDATING does not mention etcupdate
in the COMMON ITEMS section.

% svn info UPDATING | grep -i vision
Revision: 367909
% svn blame UPDATING
...
  64477   imp To rebuild everything and install it on the current system.
  64477   imp ---
...
262619   jmg mergemaster -Fp [5]
262619   jmg mergemaster -Fi [4]

% svn log -r 262619

r262619 | jmg | 2014-02-28 11:51:47 -0800 (Fri, 28 Feb 2014) | 3 lines

since -F is safe, and an update from 10-HEAD to 10-STABLE is sooo bloody
anoying w/o it..  recommend people use -F too...


etcupdate first appeared in the tree on 2012-07-13 (r238423)



Moreover mergemaster is still officially documented and recommend as 
only right method in FreeBSD handbook. See 
https://www.freebsd.org/doc/handbook/makeworld.html.
World is moving, we may have new tools but each deprecation should be, 
in this order:

1) well announced
2) adjusted in the handbook
3) implemeted

Michal





___
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: CURRENT, usr/src on git, howto "mergemaster"?

[Enji Cooper]

> On Jan 4, 2021, at 11:42 AM, Marek Zarychta  
> wrote:

…

> it's probably high time to stop escalating this thread. Some people like
> the way in which mergemaster copes with updates, some people like
> etcupdate. With Git clean and smudge filters applied on local repo and
> $FreeBSD$ IDs regenerated, mergemaster still works great and is more
> ergonomic in use for at least two people.

Hi Marek,
I don’t take offense to your concerns. I’m just trying to be direct and 
understand gaps there possibly are that can be filled in in etcupdate(8). Your 
and others’ feedback is appreciated.
Thanks so much,
-Enji

PS While I admit that smudge filters are possible for managing diffs with 
mergemaster (and I think it’s a novel solution — I’ve never heard of that 
before), not everyone should have to set those up to use a core configuration 
tool. I find things like that unfortunate gaps in the tooling that drives away 
users instead of attracts them. I personally prefer focusing less on the nits 
and writing bespoke code for system administration, so I can focus on things 
which matter more to me in my life: people and nature.
___
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: CURRENT, usr/src on git, howto "mergemaster"?

[driesm.michiels]

> -Original Message-
> From: owner-freebsd-curr...@freebsd.org  curr...@freebsd.org> On Behalf Of Michal Meloun
> Sent: Monday, 4 January 2021 20:47
> To: freebsd-current@freebsd.org
> Subject: Re: CURRENT, usr/src on git, howto "mergemaster"?
> 
> 
> 
> On 04.01.2021 19:59, Steve Kargl wrote:
> > On Mon, Jan 04, 2021 at 10:30:28AM -0800, Enji Cooper wrote:
> >>
> >>> On Jan 4, 2021, at 10:19, Warner Losh  wrote:
> >>>
> >>> mergemaster has been on its way out since well before the switch to git.
> >>> It's been disfavored for at least a decade and basically
> >>> unmaintained in the base for maybe last 5 years. Apart from major
> >>> breakage, only doc changes have happened in that time.
> >>
> >> Adding to this: it has no maintainer, it’s less featureful, and it lacks 
> >> tests.
> Once I switched to etcupdate a few years back I never looked back at
> mergemaster.
> >>
> >> I honestly think it should be deprecated in 13.x and removed in 14.x. It’s
> been several major releases since it’s been unofficially deprecated.
> >>
> >> -Enji
> >>
> >
> > For something that has been disfavored for a decade, unmaintained for
> > at least 5 years, and now seemly unofficially deprecated, it seems
> > strange that /usr/src/UPDATING does not mention etcupdate in the
> > COMMON ITEMS section.
> >
> > % svn info UPDATING | grep -i vision
> > Revision: 367909
> > % svn blame UPDATING
> > ...
> >   64477   imp To rebuild everything and install it on the current 
> > system.
> >   64477   imp 
> > ---
> > ...
> > 262619   jmg mergemaster -Fp [5]
> > 262619   jmg mergemaster -Fi [4]
> >
> > % svn log -r 262619
> > --
> > --
> > r262619 | jmg | 2014-02-28 11:51:47 -0800 (Fri, 28 Feb 2014) | 3 lines
> >
> > since -F is safe, and an update from 10-HEAD to 10-STABLE is sooo
> > bloody anoying w/o it..  recommend people use -F too...
> > --
> > --
> >
> > etcupdate first appeared in the tree on 2012-07-13 (r238423)
> >
> 
> Moreover mergemaster is still officially documented and recommend as only
> right method in FreeBSD handbook. See
> https://www.freebsd.org/doc/handbook/makeworld.html.
> World is moving, we may have new tools but each deprecation should be, in
> this order:
> 1) well announced
> 2) adjusted in the handbook

https://reviews.freebsd.org/D27848

I'm happy to change the UPDATING entry in /usr/src/UPDATING aswell if Enji 
doesn't beat me to it.
Once I jumped ship to etcupdate I never looked back. Its the better tool and 
hasn't broken my /etc/master.passwd since.

Dries

> 3) implemeted
> 
> Michal
> 
> 
> 
> 
> 
> ___
> 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: CURRENT, usr/src on git, howto "mergemaster"?

[Mark Millard]

David Wolfskill david at catwhisker.org wrote on
Mon Jan 4 12:29:45 UTC 2021 :

> After trying to use mergemaster for a couple of weeks (after the switch
> to sources from git, vs. svn) of daily tracking of head & stable/12 on a
> pair of machines (and weekly tracking of stable/12 on another 4), I gave
> up and switched to etcupdate.
> 
> Note that each of mergemaster and etcupdate has a "-p" flag; it is
> functionally equivalent between the two, but called slightly
> differently:
> 
> * mergemaster: 'Pre-buildworld mode'
> 
> * etcupdate: '“pre-world” mode'
> 
> And note that per src/UPDATING, "mergemaster -Fp" is invoked after "make
> buildworld" but before "make installworld" (under "To rebuild everything
> and install it on the current system.", under "COMMON ITEMS:").

I'm still experimenting but man etcupdate reports:

QUOTE
Bootstrapping
 The etcupdate utility may need to be bootstrapped before it can be used.
 The diff command will fail with an error about a missing reference tree
 if bootstrapping is needed.

 Bootstrapping etcupdate requires a source tree that matches the currently
 installed world.  The easiest way to ensure this is to bootstrap
 etcupdate before updating the source tree to start the next world upgrade
 cycle.  First, generate a reference tree:

   etcupdate extract

 Second, use the diff command to compare the reference tree to your
 current files in /etc.  Undesired differences should be removed using an
 editor, patch(1), or by copying files from the reference tree (located at
 /var/db/etcupdate/current by default)

 If the tree at /usr/src is already newer than the currently installed
 world, a new tree matching the currently installed world can be checked
 out to a temporary location.  The reference tree for etcupdate can then
 be generated via:

   etcupdate extract -s /path/to/tree

 The diff command can be used as above to remove undesired differences.
 Afterwards, the changes in the tree at /usr/src can be merged via a
 regular merge.
END QUOTE

I do not remember mergemaster having a bootstrap stage in setting
it up, a stage that should be executed before /usr/src (or whatever)
is updated. So the procedures are different overall.

===
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: boot loader blank screen

[Toomas Soome]

> On 4. Jan 2021, at 18:22, John Kennedy  wrote:
> 
> This is a little weird.
> 
> Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 29th),
> I've lost the screen in the boot loader.  This is really weird because I
> didn't update the boot loader (in quite a while, actually), but I suppose it
> might drag some stuff off of the disk and misbehave.
> 
> But the system boots, presumably after the countdown that I can't see, I just
> have to SSH in from a different machine to tweak things.  Just no screen at
> all past the GELI encrypted disk password prompt (and some usual noise as
> it complains about some padding that I've seen forever).
> 
> I used to just upgrade the boot loader around ZFS upgrades, and I haven't
> done that since OpenZFS got merged.  I just got overly conservative there
> and may have missed the "all clear" for all combinations of ZFS and the
> bootloader recognizing them.
> 
> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
> I'm going to repull all the sources and recompile, just in case.  I might
> have initiall pulled it during the git conversion and maybe it is confused.
> 

hi!

Yes, it is known defect, and I’m searching for cause; the issue is with 
/boot/loader and BIOS text mode (unfortunately I have the usual ‘but it is 
working for me’ case). For workaround, you can try to either: 1 (blind) press 
esc to get out of boot menu, then enter: vbe on; another option is to add 
hw.vga.textmode=“0” to loader.conf.

Sorry for confusion,
toomas

___
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: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Poul-Henning Kamp]

John-Mark Gurney writes:

> SHAttered[1] (2017) created two valid PDF documents which had the same
> SHA-1 hash.  The issue was that they were able to choose the entire
> document.

Shattered is less impressive when you take into account that you
can stuff as much much garbage into a PDF file as you need, without
affecting the files normal function.

Compact data formats, formats which leave no wiggle-room and do not
offer extension-space for "attic-junk", are much harder to produce
*meaningful* collisions for.

(I take no opinion in where git is on that spectrum.)

This is why I am very sceptical of the recent fashion of "GREASING"
which the TLS WG have invented:  To me that sounds like somebody
is allocating wiggle-room for advanced cryptographic skullduggery.

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

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

[Ryan Stone]

On Mon, Jan 4, 2021 at 3:44 PM Poul-Henning Kamp  wrote:
> Shattered is less impressive when you take into account that you
> can stuff as much much garbage into a PDF file as you need, without
> affecting the files normal function.
>
> Compact data formats, formats which leave no wiggle-room and do not
> offer extension-space for "attic-junk", are much harder to produce
> *meaningful* collisions for.
>
> (I take no opinion in where git is on that spectrum.)

FWIW, a coworker of mine had a little hobby of introducing commits
into our internal repro that had hashes that all started with
deadc0de.  As I understand it, it was able to do this by adding an
bogus attribute with the right value to the commit object.  Now,
brute-forcing 8 digits in the hash is one thing and doing it for all
40 is quite another, but I suspect that this demonstrates that it's
*possible* to do it for a git hash, given enough computing resources.
___
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: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Conrad Meyer]

On Mon, Jan 4, 2021 at 1:44 PM Ryan Stone  wrote:
> FWIW, a coworker of mine had a little hobby of introducing commits
> into our internal repro that had hashes that all started with
> deadc0de.  As I understand it, it was able to do this by adding an
> bogus attribute with the right value to the commit object.

Yeah, the git commit object is essentially text with some headers, and
the git tools are all permissive of unrecognized headers.  You can
create a "visually identical" commit (same commit message, parent
commit(s), author/committer/dates, etc) by just adding an extra header
with an arbitrary value and brute force on that value to find a vanity
prefix.  This isn't anything related to the SHA1 attacks, it's just
brute-forcing the output of a truncated SHA1 to a 1-in-2^32 result.

E.g., https://github.com/cemeyer/gitbrutec does it by injecting a
header named "x-gitbrutec-nonce."

$ git cat-file -p 009
tree 4e778673b8af45ecd4c62e8b1d1438d06db7f440
parent 0080b4fc4c2066fa05641e73d5f0985c15ea
author Conrad Meyer  1590357489 -0700
committer Conrad Meyer  1590357489 -0700
x-gitbrutec-nonce YYZSKGIQCLLXGE

Use 'git update-ref' in post-commit example
...

> Now,
> brute-forcing 8 digits in the hash is one thing and doing it for all
> 40 is quite another, but I suspect that this demonstrates that it's
> *possible* to do it for a git hash, given enough computing resources.

SHA1 has always, by design, been vulnerable to a 2^80 resource attack :-).

Best,
Conrad
___
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: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Conrad Meyer]

Typo:

On Mon, Jan 4, 2021 at 5:25 PM Conrad Meyer  wrote:
> SHA1 has always, by design, been vulnerable to a 2^80 resource attack :-).

2^160 for a specific hash.  2^80 if you're just trying to find any collision.
___
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: boot loader blank screen

[Idwer Vollering]

Toomas,

I had more success with this patch, applied on top of 7beeacb27b27 (in
other words: call vbe_is_vga() from cons_update_mode() instead of
vidc_install_font() ):

diff --git a/stand/i386/libi386/vbe.c b/stand/i386/libi386/vbe.c
index 7681eb633b8..1fee4f040f4 100644
--- a/stand/i386/libi386/vbe.c
+++ b/stand/i386/libi386/vbe.c
@@ -1105,6 +1105,15 @@ vbe_default_mode(void)
return (modenum);
 }

+bool
+vbe_is_vga(void)
+{
+   if (vbe == NULL)
+   return (false);
+
+   return ((vbe->Capabilities & VBE_CAP_NONVGA) == 0);
+}
+
 COMMAND_SET(vbe, "vbe", "vesa framebuffer mode management", command_vesa);

 int
diff --git a/stand/i386/libi386/vbe.h b/stand/i386/libi386/vbe.h
index ff28b960df9..7d07d9ee518 100644
--- a/stand/i386/libi386/vbe.h
+++ b/stand/i386/libi386/vbe.h
@@ -161,3 +161,4 @@ int vbe_set_mode(int);
 int vbe_get_mode(void);
 int vbe_set_palette(const struct paletteentry *, size_t);
 void vbe_modelist(int);
+bool vbe_is_vga(void);
diff --git a/stand/i386/libi386/vidconsole.c b/stand/i386/libi386/vidconsole.c
index b4829db1ea4..22708032a49 100644
--- a/stand/i386/libi386/vidconsole.c
+++ b/stand/i386/libi386/vidconsole.c
@@ -907,7 +907,8 @@ cons_update_mode(bool use_gfx_mode)
unsetenv("screen.width");
unsetenv("screen.depth");
unsetenv("kern.vt.fb.default_mode");
-   vidc_install_font();
+   if (!vbe_is_vga())
+   vidc_install_font();
}

free(screen_buffer);

Op ma 4 jan. 2021 om 23:59 schreef Toomas Soome :
>
>
>
> > On 4. Jan 2021, at 18:30, Toomas Soome  wrote:
> >
> >
> >
> >> On 4. Jan 2021, at 18:22, John Kennedy  wrote:
> >>
> >> This is a little weird.
> >>
> >> Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 
> >> 29th),
> >> I've lost the screen in the boot loader.  This is really weird because I
> >> didn't update the boot loader (in quite a while, actually), but I suppose 
> >> it
> >> might drag some stuff off of the disk and misbehave.
> >>
> >> But the system boots, presumably after the countdown that I can't see, I 
> >> just
> >> have to SSH in from a different machine to tweak things.  Just no screen at
> >> all past the GELI encrypted disk password prompt (and some usual noise as
> >> it complains about some padding that I've seen forever).
> >>
> >> I used to just upgrade the boot loader around ZFS upgrades, and I haven't
> >> done that since OpenZFS got merged.  I just got overly conservative there
> >> and may have missed the "all clear" for all combinations of ZFS and the
> >> bootloader recognizing them.
> >>
> >> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
> >> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
> >> I'm going to repull all the sources and recompile, just in case.  I might
> >> have initiall pulled it during the git conversion and maybe it is confused.
> >>
> >
> > hi!
> >
> > Yes, it is known defect, and I’m searching for cause; the issue is with 
> > /boot/loader and BIOS text mode (unfortunately I have the usual ‘but it is 
> > working for me’ case). For workaround, you can try to either: 1 (blind) 
> > press esc to get out of boot menu, then enter: vbe on; another option is to 
> > add hw.vga.textmode=“0” to loader.conf.
> >
> > Sorry for confusion,
> > toomas
> >
>
> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be 
> cool if you can verify:)
>
> thanks,
> toomas
> ___
> 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: boot loader blank screen

[Toomas Soome]

> On 4. Jan 2021, at 18:30, Toomas Soome  wrote:
> 
> 
> 
>> On 4. Jan 2021, at 18:22, John Kennedy  wrote:
>> 
>> This is a little weird.
>> 
>> Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 
>> 29th),
>> I've lost the screen in the boot loader.  This is really weird because I
>> didn't update the boot loader (in quite a while, actually), but I suppose it
>> might drag some stuff off of the disk and misbehave.
>> 
>> But the system boots, presumably after the countdown that I can't see, I just
>> have to SSH in from a different machine to tweak things.  Just no screen at
>> all past the GELI encrypted disk password prompt (and some usual noise as
>> it complains about some padding that I've seen forever).
>> 
>> I used to just upgrade the boot loader around ZFS upgrades, and I haven't
>> done that since OpenZFS got merged.  I just got overly conservative there
>> and may have missed the "all clear" for all combinations of ZFS and the
>> bootloader recognizing them.
>> 
>> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
>> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
>> I'm going to repull all the sources and recompile, just in case.  I might
>> have initiall pulled it during the git conversion and maybe it is confused.
>> 
> 
> hi!
> 
> Yes, it is known defect, and I’m searching for cause; the issue is with 
> /boot/loader and BIOS text mode (unfortunately I have the usual ‘but it is 
> working for me’ case). For workaround, you can try to either: 1 (blind) press 
> esc to get out of boot menu, then enter: vbe on; another option is to add 
> hw.vga.textmode=“0” to loader.conf.
> 
> Sorry for confusion,
> toomas
> 

the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be 
cool if you can verify:)

thanks,
toomas
___
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: boot loader blank screen

[John Kennedy]

Op ma 4 jan. 2021 om 23:59 schreef Toomas Soome :
> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be 
> cool if you can verify:)

  No, sorry...

On Tue, Jan 05, 2021 at 02:58:02AM +0100, Idwer Vollering wrote:
> I had more success with this patch, applied on top of 7beeacb27b27 (in
> other words: call vbe_is_vga() from cons_update_mode() instead of
> vidc_install_font() ): ...

  ... and that patch didn't work for me either.  Although, in my case,
it is on top of main-c255599-g58661b3ba9eb.

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